I’m coming up on 15 years of professional software engineering. I’ve worked at companies from unknown startups to large FAANG-like silicon valley companies and everywhere in between. In no particular order, sharing some things I’ve learned that others may find helpful.
Great points especially about staging always being broken and the difficulties of maintaining a production-like environment. One other point I would add is “Code reviews are a great opportunity to learn a different way of doing something”. Reviewing someone else’s code is not about making sure the code looks the way you would have written it but more about understanding how your peers thought a particular problem should be solved. Try to put yourself in their shoes before passing judgement especially in the case of bad code smells. Lead with empathy in your reviews.
One I would add: Try to wear the PO's shoes. Devs often get frustrated when the scope changes mid-journey. If that happens too often is an obvious symptom of not enough planning, but if scope changes are not allowed, it means the project is not innovating enough or that the team is too afraid of change.
I guess that your "Take ownership of your systems" covers that in a way.
Having worked as a consultant for many years, I'll make an observation about taking actions. Anyone can identify a problem, identifying problems isn't hard. What makes you a valuable engineer is proposing solutions.
Great read, thank you Ryan. I love your perspective on taking ownership and taking action instead of complaining. Highly underrated skills!
Great article! Very much agree with all of these, especially aggressively managing scope.
Last part I can resonate with! ;)
Great points especially about staging always being broken and the difficulties of maintaining a production-like environment. One other point I would add is “Code reviews are a great opportunity to learn a different way of doing something”. Reviewing someone else’s code is not about making sure the code looks the way you would have written it but more about understanding how your peers thought a particular problem should be solved. Try to put yourself in their shoes before passing judgement especially in the case of bad code smells. Lead with empathy in your reviews.
Well put!
One I would add: Try to wear the PO's shoes. Devs often get frustrated when the scope changes mid-journey. If that happens too often is an obvious symptom of not enough planning, but if scope changes are not allowed, it means the project is not innovating enough or that the team is too afraid of change.
I guess that your "Take ownership of your systems" covers that in a way.
Beautifully written and useful.
Staging / test always wonky . That is why deployment strategy so critical. Your testing strategy must include post deployment .
Metrics/debug human readable so important. Getting real user session data and 'what the hell mad use case they doing'
Only warning 'feature flags' you got good quality deployment and regression testing . Then some idiot switches on new feature flag at 5pm Friday. ...
Love this style of article!
Nice read :) I'm looking forward to more and will gladly share it!
Well written and so true
Having worked as a consultant for many years, I'll make an observation about taking actions. Anyone can identify a problem, identifying problems isn't hard. What makes you a valuable engineer is proposing solutions.
Great article! Thank you!
Wonderful insights, all very pertinent especially because I'm 6 months into my first role.