Wearing the right hat for the right job

If I had one piece of advice to to be a more effective software engineer it would be this: know which hat you’re wearing at all times, and wear the right hat for the right job.

In other words, be intentional in what you are doing at any given moment, and aware of the trade offs being made at each step.

Are you tasked with maximizing business value?

Then why are you going down technical rabbit holes and refactor work that has no clear business value, and which is holding back your timeline?

Are you optimizing your work and projects for a promotion?

Then why are you upset if you’re not learning interesting technical subjects? Is learning interesting technical subjects a criteria or pre-requisite for promotion? Most promotions are designed around maximizing business impact. As a result, more technically interesting work that is less impactful might be a waste of effort in the pursuit of promotions. Optimizing for promotion in this regard has trade offs, whether consciously or unconsciously known.

Are you shipping an MVP and launching a new app?

Then why are you over engineering your app architecture, with 100% test coverage, enterprise-grade design patterns, etc when you have zero customers, haven’t reached out to any potential users, haven’t done any marketing, and have no market validation tests? Why are you using experimental, unfamiliar bleeding edge tech that isn’t proven and requires significant learning curves to understand and maintain? Why aren’t you choosing what you’re most productive with? Why are you even writing code before reaching out to potential customers or having done customer interviews?

I’m not saying that new technology or high engineering standards are bad- but when the goal of a startup is to iterate on product market fit and validate ideas, then flexing your engineering skills is likely a hinderance to your success, and if anything one of the biggest and most common sources of downfall

This in fact, is a very common engineering trap for solo engineers launching products- they are wearing their engineering hat more than they’re wearing their salesperson hat, their customer support hat, or their marketing hat. As a result, they fail after many months of product development without a single user to show for.

Wearing multiple hats at once can be less effective, less efficient, and lead to more personal pain.

Wearing a “fixer” hat who is doing sweet refactors and upgrading legacy tech debt with future scalability and best practices in mind while your startup assigned you a project that is asking for an “MVP builder” hat means that you might spread yourself too thin, miss deadlines, and overall feel a sense of frustration as you move against the tides of your organization which never asked for a “fixer” and only wanted a “builder”.

Wearing a “refactoring” hat while also wearing a “builder” hat might mean more bloated PRs, more potential for tasks to drag out, and going down rabbit holes that waste time. It could translate to wasted cycles refactoring code to adjust for a use case which ends up being irrelevant as requirements develop later in the project and render that use case you optimized for no longer relevant

Just like the old Software engineering adage goes, “use the right tool for the right job”, I urge any effective software engineer- “wear the right hat at the right time”

I'm Patrick El-Hage and I live and work in San Francisco. I'm also on Twitter.