Why your programmers just want to code

Marcus Blankenship
The Startup
Published in
4 min readApr 19, 2017


When I interviewed Jamie for a position at ZenTech, he seemed like an enthusiastic engineer. With solid tech skills, ideas for process and product improvement, and a great team attitude, he was the obvious choice.

But, two years later, Jamie was “that guy”. You know, the one who wants to code without being bothered.

I should have noticed the signs. He didn’t speak up in retrospectives, he didn’t contribute process or product ideas like I expected, and his “team-friendly” interactions were usually sarcastic. He often talked about technical debt, our lack of innovation, and the “stupid” decisions holding us back. An irritating “I told you so” sentiment plagued his comments and feedback.

Jamie may have thought about leaving the company. If he did, I couldn’t tell. Although, I certainly wish he would have. But we were shorthanded, and I needed all the help I could get.

The result?

Another cliché programmer who just wanted to code and be left alone.

People are shaped by environment

Too many managers believe the problem lies with Jamie. If he was a better employee, dedicated worker, or at least cared more, then this wouldn’t happen. Right?

Unfortunately, no.

The transition from enthusiastic programmer to polarized programmer doesn’t happen overnight. But it starts sooner than you think.

The first suggestions matter a lot

How you handle ideas from new programmers sends an important signal. Good or bad, it sets the stage for what they expect. This determines if they share more ideas in the future… or keep their mouth shut.

Sure, some ideas might not be feasible in your environment. Some might get put on the back burner to be discussed “when we’re not busy”. Some ideas seem great, but they run against unspoken cultural norms.

No matter what the reason, dismissing or devaluing your programmer’s ideas — especially in the first few months — is a bad move.



Marcus Blankenship
The Startup

Hacker, Problem Solver, Calvinist, Geek. Author of Habits That Harm Your Technical Team. http://bit.ly/2HcjV8Z