I interview many people, and, as a result, I meet many young engineers. No one would consider me to be young (OK, in some contexts, yes, but I am not, for example, running for president of the USA), so there is a dialectic of experience that permeates the process.
When I interview someone, I always say, with sincerity, "It is customary for a candidate to send me a perfunctory thank you email. I don't need that. But what I do need is, if you have questions, if you want to tell me something, if you want to understand something, I am at your service."
Different people respond in different ways, but one remarkable young person (who finally convinced me to try Rust) asked what lessons I could share from my journey to Principal Engineer. That is unusual, fantastic, and moving. As such, I did what I could to answer in a way that would actually be helpful.
After some thought, I arrived at eight bullets that I could share:
- I never stop learning things, and the more different something (a language, a technology, a mental model) is, the more I try to learn
- In relation to that, I view EVERYONE as a potential teacher, and always try to learn from them.
- When an engineer is young, they often take risks, and try things. As they age, and reach say, Senior, they become much more conservative and start to box in their thinking. If they mature to the level of Principal, usually it is because they have rediscovered (tempered) risk taking, and are willing to abandon being boxed in. Fight the urge to become conservative. Think in the large, always, and take risks.
- Always take time to think about your craft. Even if you can't do anything to fix it, always do a retrospective, in your own mind, on projects you did, and reexamine how you did what you did, and how you could have done it differently.
- Type slower, think more. Step back from your work and think a size out about it.
- When you have requirements for something, always ask, "what are we REALLY trying to do". Always try to think about the context of your work in the large, and don't just solve the problem before you, try to solve for the more fundamental level. Even if you can't do more than you were asked, be aware of what the true purpose of your work is, and think larger.
- Be the person who helps, every time.
- Don't let anything stop you. It is very, very simple to say, "I can't do anything more here", or, "there is no way to do that". Never, ever be OK with that. I have been doing programming for money for about 40 years now. I have done many "impossible" things, not because I am some super being, but because I refuse to be stopped.
Some time later, I was speaking with my manager, and I mentioned this interaction. In response to this he said, "those bullets are the chapter headings of your book."
I'm not writing a book currently (about engineering, anyway), but I decided to start here and cast these thoughts into the ether (or perhaps the void, or even the
So, I share with you these eight punchy bullets. I plan to write an individual essay about each of them, and link them here (which means that the above list will gradually turn blue with links). But, as of this instant, these are the words I can share with you. Take them as you will. They are a snapshot of what I believe lead me to where I am.
When you have done software for an extended period, most of your work has been thrown away (think about that). But people persist, and what you do for and with them is your monument. I hereby dedicate this list to building that monument, and, if this, and what follows, is of help to you, then I have done the only real job that I have.