Software Engineering in Practice

Strong Engineers

Strong engineers can do things that weaker engineers just can’t, even with all the time in the world. Some examples of capabilities:

• Solving very difficult bugs, e.g., race conditions across multiple services.
• Delivering meaningful improvements to the thorniest parts of legacy codebases.
• Making changes that require a big architectural rework.

At the top end of strongest engineers, capabilities become something like “improving the SOTA for LLMs”.

Regular engineers make the bulk of most companies. They solve 95% of bugs (normal, non-cursed bugs), deliver most JIRA tickets, and unstick themselves from dev env issues most of the time. They help. They do the work. They’re just not burning with ambition to excel at the next promo cycle. Probably have other things going on in their lives.

Origins of Projects

• You’re invited to join. Organization already cares about this. That someone thinks you’re a good fit might mean it’s similar to work you’ve done before and not an opportunity for growth.
• You ask to join. Even if it’s obvious that you’re the best fit, don’t wait for someone else to notice.
• You have an idea. You need to convince others to care. Might get mired in politics, but once it’s underway, you have lots of control and can have huge impact.
• The fire alarm goes off. Goals are usually very clear and there’s a bias to action. However, there are fewer opportunities for growth.
• You’re invited to join a grassroots effort. Working groups can be effective if there’s organizational buy-in, a clear time commitment, exit criteria, and a process for making decisions.
• Someone needs to… Volunteering can build credibility and goodwill, but watch out for doing too much of it at the expense of other results people are expecting from you.
• You’re just meddling. Make sure you’re not getting involved long enough to cause chaos and then disengaging without sticking around to experience the consequences of your changes.

Macro-Economics: Interest Rates and You

In the 2010s, interest rates were near-zero; investors borrowed a lot of money and spent it on tech companies hoping for outsized returns. Companies desired to attract and retain talent; “literally anything” is worth spending money on to accumulate engineers.

In 2023, interest rates rose to ~5%. Tech companies now need to make money. If your work isn’t clearly connected to company profit, then your position is unstable and on the whims of an executive that personally values your work.

Usually, the reason a project is difficult isn’t that you’re pushing the boundaries of technology, it’s that you’re dealing with ambiguity: unclear direction; messy, complicated humans; or legacy systems with behavior you can’t predict.

On the Clean Code Movement

Good enough is good enough. The architectural choices and bugs in the implementation tend to be more impactful, so focus more on those.

Be conservative in what you consider technical debt. It should be something that slows down current/future changes, and not code that doesn’t “feel nice”. A code base that is free if technical debt is likely over-emphasizing polish over delivery.

Abstractions and indirections in the name of future-proofing tend to be wrong especially when treading new paths, where you can’t reliably predict the future. A lot of value is in knowing the design guidelines well enough, that you know when/if to deviate to better suit the current problem.

These maps already exist but are obscured to you. Be alert to facts that affect your projects or organization. Continually sift information out of the noise around you, e.g., a shift in corporate priorities could mean a platform you’d considered but backburnered has become an amazing investment.

The Locator Map: Getting Perspective

Time you spend absorbed in any domain increases your depth and understanding, but it comes with some risks, e.g.

Stuck in Traffic

Blocked By Another Team

Understand and explain. Why is the work is important? What do you want from them and by when? Give them another chance to indicate feasibility and/or alternatives.

Make the work easier. Can you ask for a smaller subset of features? Can you help unblock their dependencies. Note that supporting your foray into their code base might cost them more in support and they might decline your offer.

Measuring Productivity

Devs’ Diverging Perceptions of Productivity