Last week I read / reacted to 10 lessons learned from 15 years working as a Software Engineer. A lot of these lessons resonated with my own experience but I felt several could be distilled to more general advice that would work more universally across teams, companies, and experience levels.

In this post, I'll dive into the 3 tips I most often give to software engineers to improve their effectiveness.

Lessons from a Career in Software Engineering

If I could only share 3 lessons from my career, I think they would be the following:

• Focus on Impact
• Simple Scalable Systems
• Be Positive

Focus on Impact

My first piece of advice to anyone (whether a software engineer or otherwise) is to focus on impact. At the end of the day, we are doing something to produce value. What that value is depends on our goals, values, and the state of the world.

By focusing on Impact, we put the "why" of what we're doing first. Understanding "Why" - or as Simon Sinek says "Start with Why" - we better understand the value of what we're doing which then allows all following actions to be more aligned with that value stream and thus more effective.

There are infinite things we can do. But most of them are not very valuable. Focusing on Impact ensures that we better understand why we're doing something so we can better filter our actions to only those that are most valuable.

Example:

• You're never paid to run a website. Instead, you're paid to enable customers to find and purchase your company's product (for a marketing website) or paid to maintain / improve your company's value add to the customer so they keep paying for it (for a web app)

Simple Scalable Systems

My second piece of advice is to focus on Simple Scalable Systems (3S) for achieving your goals. The idea is that fast, quality iterations will allow us to achieve the Impact we seek much faster and more effectively over time than either working with no systems or working with heavy process.

Determining what the right balance is for your team / org is a constant process. There is no right answer and the answer will likely change over time. But typically it's going to be more systematic than no systems and less systematic than "do the same exact thing every time".

The best way I've found for finding this balance is experimentation. If you see the same problem several times, try to fix it with a Simple Scalable System - something lightweight but should solve it systematically. If it still isn't fixing it, try something more robust. If it feels like overkill, try something lighter.

Examples of things I've found to be useful 3S over my career as a Software Engineer:

• Provide a simple Hypothesis for every code change / project - Why are we doing this, why do we think it's important, and what is your plan
• Code Reviews with a bias for "Approving to Unblock" and non-blocking nits (always give feedback but don't block on it if it's not serious)
• Provide agendas for every meeting - Seriously, if you don't have an agenda it's unlikely to be a useful meeting
• Leave everything better than you found it - If you're looking at / changing code and something is confusing, consider taking an extra 10% of project time to clean it up while you're there.

Be Positive

I believe nothing really matters thus you might as well be happy (read: positive). You don't like working with your jerk coworker so do not be the jerk coworker to someone else.

IMO you should always strive to be not negative. You don't need to (and probably shouldn't) be a selfless altruist giving all your efforts away for free but you also shouldn't be doing bad things. Adam Grant dubs this balance being "Otherish" in his book Give and Take - you do your main thing (focusing on impact) and give positively where it makes sense.

You must focus on yourself first before helping others because if you are not doing your main thing - taking care of yourself and your duties - then you aren't in a good position to help others with theirs.

Commonly-used parallels to this include:

• Put on your mask before you help others with theirs
• You cannot fill another's cup if your cup is empty

But at the same time you can't only focus on your own duties as that will only get you so far. It may seem like spending time / effort / resources to help others will hamper your own interests (your career, projects, or team). But actually if you view every project, team, and company as an ecosystem this free giving (where its impact:cost is attractive) is extremely impactful for elevating your own station, often more than selfish actions would be. A rising tide lifts all ships.

A better metaphor for us software engineers is probably tech debt in a software system. If we always focus on the short-term wins, we intuitively know that tech debt will accumulate. The best way to accomplish x short-term is rarely the best way to do so long-term as we take more shortcuts that make future changes harder.

Counter-intuitively, the best way to get wins long-term is actually to find the balance between the business-focused wins short-term (selfish) and long-term infra that allows it to happen with less cost (selfless). The business-focused wins can't be the only thing we do as eventually the wins will grind to a halt as the system is hard to change (or perhaps just isn't cooperating with each other). The infra wins also can't be the only thing we do as we're here to run a business and if the business doesn't get wins, it doesn't get money, and now we're all out of a job.

So the optimal balance is actually the Otherish approach - being both pragmatic and positive. Build the business wins aggressively and when the impact:cost makes sense for improvements to the system / help given to others, do that.

Next

These three principles have gotten me pretty far in my own career / life.

What are your best pieces of advice for other software engineers?