I stumbled upon an excellent post delineating lessons learned from 15 years working as a Software Engineer. A lot of these resonated with my own experience working as a software engineer so in this post I wanted to reflect on each of these lessons and what resonated with me / things I'd change.

Try not to think in absolutes - At the end of the day, everything has a tradeoff. Come up with reasonable solutions today with the understanding that it may not always be the best solution over time. In particular, do not die on any hills - this is a collaboration, not a competition.

Debuggability is highly underrated - Yes and I would say a more generalized version of this is that the human bottleneck is the most important / impactful bottleneck in software engineering so we should optimize for it. This is related to making your software more easily debuggable but also making it simpler so it's easier to understand, using static types making more bugs impossible / easier to find, and even improving the way your team does meetings / code reviews / etc for faster, higher quality systems.

Projects are late, a lot - Yes a lot of project estimations are wildly inaccurate because truly there's a lot of things we just don't know. The best way to deal with this is to Focus on Impact (and in the process understand the domain / why you're doing this), do experiments / understanding investigations before estimating, and cutting down on scope. You'll still get estimates wrong, but this will vastly reduce the amount of unnecessary work you do thus vastly reducing the amount of time required to ship impact.

Aggressively manage scope. - I like to say you can't do more work, you can only prioritize better. So to scale yourself you must get better at prioritization so you only fill your work queue with impactful things. The way to do this effectively is to focus on impact (why) and cut the things that aren't impactful. Usually you'll find that about 80% of the proposed work is not useful. So for this, I'd probably change it to "Focus on Impact".

Related: Escape the Build Trap (The simple way)

Staging is pretty much always broken. Yes and I'd go further and say that production is pretty much always broken. IME some system is always broken but what really matters is whether this impacts the end user / value your business brings. There is always infinite work to be done but only the most impactful is worthwhile.

Action is rewarded. I prefer the idea that Impact is rewarded and thus you should Focus on Impact. The reason is that Action = Work and Work doesn't really mean anything. A person could spend 80 hours a week doing nothing. They may have been working a lot but if that work didn't bring value then it didn't really matter. By focusing on impact instead of work, we can find way more impactful things that cost way less.

Take ownership of your systems - As you grow in your career as a Software Engineer it's going to be more and more important to start setting direction for your system and domain. This goes beyond just your System though as a software system by itself is largely meaningless - the value comes from what it does for the business / its users. So a better piece of advice would be to take ownership of your Domain - understand your users and their context / problems, the business and the value it provides, and the roles the systems you own are meant to play. Then evolve your technology to better serve.

You are part of a larger organization - Tech does not exist in a bubble. It exists to provide some value to the broader org. Thus the better understanding / relations you have with the broader org, the better you can build your systems, leading to a virtuous cycle of improvement.

"Ask the right questions at the right time"

This is one of the most important habits for scaling your impact across teams / orgs.

You can't be everywhere / do everything. The right question both directs and empowers a team w minimal cost.https://t.co/xDXgoSgkmx

— Hamilton Greene (@SIRHAMY) September 26, 2023

Ask dumb questions - Questions are an excellent way to gain better understanding, create alignment across teams, and to avoid costly mistakes.

You won't have time to go back and fix tech debt - This is true and mostly doesn't matter. As the Zen of Python says: "Now is better than never. Although never is often better than right now.". The truth is that most tech debt / bugs just don't matter. Yes it would be better if they didn't exist but if there are more important things to do / fix than focusing on them is a waste of time / resources.

Related: How I run my Project Backlogs with Trello

Enjoy it! At the end of the day none of this really matters. Enjoy the time you have and don't be the jerk at work.

Next

If you liked this post, you might also like:

• Effective Meetings for Software Engineers
• Instagram's tech stack will surprise you