A Hierarchy of Engineering Values

May 31, 2020

Polished

Software

It's important for software engineers to determine what their hierarchy of engineering values is when looking to change projects, teams or companies. Take a moment to think about how you rank or weight the importance of the following:

What you build: How much do you care about what the actual feature or product you build is?
Why you build it: How important is the purpose of the software to you?
How you build it: How much do you value the application of specific technologies, engineering practices or processes when building software?

There's a lot more to culture fit than just these questions (and they certainly don't exist in a vacuum) but I believe they strike at the heart of what it takes for an engineer to feel involved in and satisfied with the development of a project. From my own experience and the experiences of friends and coworkers, disillusionment with a project occurs when an engineer's values begin to diverge from those of the team or company. It starts gradually; a feeling of malaise creeps in and if left to fester too long, morphs into jadedness. It's easier to identify what you don't agree with in a project, but many people don't take the time to consider why they don't agree.

I believe it's worth coming back to these questions every so often to determine whether your or your team's hierarchy has changed, and if it does, reevaluate whether the project is still a good fit. There's a lot of opportunity out there, and it feels good to have value alignment. Treat yourself well, and seek it out.