Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
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.
Damaged by all the naysaying, heâll try a few more times to present his ideas differently, aiming for a successful outcome. If he continues to feel punished, though, heâll realize that the only way to win is not to play.
Which is exactly what you donât want your programmers learning.
He will stop presenting ideas, asking to meet customers, and genuinely trying to understand the business.
Ultimately, itâs a lose lose.
The bigger the idea, the bigger the risk
Remember that your programmer is taking a risk when they offer a new idea. The bigger the idea, the bigger the risk.
Why is it a risk? Because our ideas reflect ourselves, our views, and our passions. We donât advance ideas we donât care about, or that we think wonât work. We put forth our best ideas with the hope they will be received.
This requires vulnerability, which only happens if weâre fairly certain we wonât be humiliated. If we believe our ideas wonât be accepted, we stop offering them.
Feedback about ideas shapes behavior
Itâs only natural, then, that your programmer is reduced to doing only what brings him success:Â coding.
His enthusiasm for creation, innovation, and development, sadly, are lost.
Perhaps it transforms into an unrealistic ideas about code quality or code metrics.
His concern for market share and business health is replaced with a concern for titles and pay scales. He becomes more worried about how much he earns, what his title is, and how he looks on LinkedIn.
His enthusiasm for changing the world is replaced with nit-picking the development process.
Worse of all, though, his concern that âWe arenât building the right thingâ will be replaced with âWe arenât building the thing right.â
Heâs learned to not give input on what is built, so he becomes obsessed with how itâs built.
Your culture, for him, has become survival of the fittest.
Whatâs your onboarding teaching?
While you would never say this directly, your onboarding and culture may be teaching:
- âOur company doesnât like big ideas from little people.â
- âYou just focus on building stuff. Weâll figure out what the customer needs.â
- âYou are just a code monkey.â
- âHmm⊠why are you asking so many questions. Donât you have coding to do?â
What is your real culture?
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.
Texas A&M Professor Ifte Choudhury states,
âA culture is a way of life of a group of peopleâââthe behaviors, beliefs, values, and symbols that they accept, generally without thinking about them, and that are passed along by communication and imitation from one generation to the next.â
If you wonder what kind of culture you have, start watching how people behave.
If you donât like what you see, change it. Culture isnât dictated. Itâs learned, modeled, and imitated.
As a leader, itâs your job to be worthy of imitation.
Because the culture isnât Jamieâs fault. Itâs oursâââTeam Leads, Software Managers and CTOâs.
So, stop blaming Jamie and start making the changes that your culture demands. The sooner, the better.
P.S. Part 2 of this article is here
Why your programmers just want to code was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.