So ... where is your code

During my 1-on-1 with new hires, I often ask: “how are you learning KMS?” The answers go like: “I am reading the wiki documents.” “I am watching the tech talk videos.” “I am reading the runbooks.” ... But software engineering is not something one can learn through reading and watching. It has to be learned by doing. To me software engineering is not a science discipline, not even a traditional engineering discipline like mechanical engineering or civil engineering. It is a mixture of (trade, science, art), maybe 70% trade - getting things done by hand with craftsmanship, 20% science - knowing why things work in such a way, and 10% art - innovating through creativity, sometimes through divine inspiration. I get nervous when a project stays on “design phase” for weeks, I tend to ask: “Is there something you can start coding first, a proof of concept, or a Minimum Viable Product (MVP)?” Rather than an elaborate design document, I care more about a detailed project plan page, which should define the the milestones and dates. I pay attention specifically to the immediate milestone - what is to be demoed to stakeholders next, that is valuable and meaningful to them. I pay less attention to milestones and dates in the far future. They are just plans, and plans always change based on what reality tells us. I would rather see a well thought Operation Readiness Plan, like what the metric dashboard looks like, than a “perfect” design doc. I get worried when I don't see code reviews from a new hire in the first month. It doesn't matter the code reviews are small and trivial. Maybe they only fix some typos in the code comments, make an error message more understandable, or add an new metric. In fact we want small code reviews that can iterate quickly. These code reviews give new hires the most important thing of their learning experience - feedbacks. Team members will comment on the code reviews. The changes need to be tested merged, deployed through pipeline and ran in production. New hires get the hand on experience by watching how their change goes through the different stages of our deployment life cycle. Then all these documents, tech talks, runbooks start to make sense. Software engineering is about making a useful product - by doing something. We also start to develop hand on Labs, so new hires can try things safely, without worrying about breaking production. Software engineer role is closer to carpenter or painter, than scientists spending their life discovering “new knowledge”. Carpenters learn by working on wood. Painters paint. Software engineers code. So… where is your code?