Why your programmers just want to code

This is so on point:

"Culture isn’t the slogan on your wall, or how you describe your mission during an interview. Culture is the way people actually act, and what they actually care about."

PMs and Dev Managers, your engineers are smart, dynamic individuals. If you engage them and include them in important conversations and actively solicit their feedback while providing context and customer feedback, you will get innovative and creative ideas, you will get an energized work force, and everybody will be happier for it. Don't treat engineers like an assembly line: software is a dynamic machine and it requires everyone's best work to evolve in the right way.

The programmer in this story has realised this fundamental truth:

The spoken word is ephemeral and easily forgot. The design of the product that pays the bills is not so easily undone.

What people say in meetings; all the posturing and preening; the petty one-upmanship and power-play — none of this has any relevance to what actually gets done in the real world.

When it comes to what actually gets implemented — all of the power is in the hands of the programmer who gets there first. After all — once the die has been cast and the direction set, who is going to undo the work and start again?

In this, the programmer is the decider.

Programmers have an immense amount of power, and there is no reason whatsoever why he shouldn’t simply ignore the pointless social preening and get on and make the product that he wants to.

After all, the consequences of his decisions will ripple far and wide thorough the product and beyond and have a heft; a level of consequence and a permanence that no ‘soft’ skills specialist can match.

How would you feel if:

- you were a chef. you went to culinary school and know about cooking and best practices.

- you are asked to forget everything you learned in school and flip burgers with overly reused oil and unwashed equipment.

- you are told that there's no time to clean the kitchen, or wash your hands. just flip as many burgers as possible to maximize profit.

- the ones that cook the most burgers are rewarded, treated well, promoted. as soon as cooks realize this, they start making half-cooked burgers that make people sick.

- the customers get sick all the time from the lack of hygiene. you talk about it, and you are told to keep doing what you are doing, or that you don't understand what being a chef is, or what the business is.

- in the end the only source of gratification is getting a paycheck, or doing something in your spare time. you are not cooking real food, just part of a machine that makes money for a self-serving company while ripping off the customer.

This is what it feels to be an engineer in many companies.

Except that the programmer rarely has an idea of the big picture and the business problems that need solving and often sees the world through narrow lenses of 'problems I've solved before' or 'how things are done' or 'knowing what's going on'. All those 'soft' skills are figuring out what needs doing (even if it's often difficult to translate that into a product that can be developed).

So there are two stages here... First is caring about the what, and getting no traction in determining that. It's left to the PMs. Second is caring about the how, trying to at least get ideas implemented on that front. But what's the stage after that? If you get no traction on making a better what, nor doing it with a better how?

Will a company with a strong why, a sense of purpose, that is felt and understood by all the employees help ward off the troubles of obsessing over what and how?