How to Keep Your Best Programmers (2012) | Hacker News Reader

How to Keep Your Best Programmers (2012)

daedtech.com

64 pointssigna1123 comments

"[...] and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. They tend to entrench themselves, becoming maintenance experts on critical systems, assuming responsibilities that no one else wants so that the organization can’t afford to let them go."

So basically, they are people willing to do work that is needed and doing it responsibly. The work you are not willing to do and doing it without throwing temper tantrum over being too good for the work. That is why they ended up having responsibility - leadership does not have to worry that boring but needed work wont be done. He does not even have to motivate them, they just work.

I mean, I get that it is possible to asleep and not to continue learning, becoming mediocre. But if you are too good for work on critical system that needs to be done, then you have less merit then them. Merit should not be about coolness points, but about how useful you are. I agree that all this probably means leaving is a good idea for you, but the resentment towards people responsibly doing important work you are not willing to do is absurd.

Also, once you have to maintain the code for longer (or worked on old codebase), you might find that your opinions about what is clean code and what is important change - some of the stupid things if you people used to small projects routinely do are actually things that allow you not to loose sanity and control on big projects.

The same author has other blog posts regarding organizations and teams that place too much value on "putting out fires" and not enough emphasis on avoiding situations that cause fires in the first place.

He also writes about teams that reward and entrench tribal knowledge but have no notion of designing systems (when possible) such that even new hires cannot misuse them. http://www.daedtech.com/tribal-knowledge/

I'm sure it is these notions that the author had in mind when writing this article, and not just people who want to skirt unpleasant/difficult tasks.

Sure, but "becoming maintenance experts on critical systems, assuming responsibilities that no one else wants" does not imply putting out fires nor bad design. Not by a long stretch. But then again, if the company has that badly written critical system, someone willing to work on it responsibly has more merit then someone who is not willing to work on it. Of course if you are able to do it better and make needed changes then it is even better, but prerequisity is you being willing to work and assume responsibility.

The part I quoted from defines merit as raw talent or something like that, not by how useful or responsible you are. He assumes that your motivation have to drop over time and if it does not, he assumes you are bad developer. That is wrong. The productivity/motivation drop itself is a fault, not a virtue. Yes, good leadership deals with it too, but if they don't need to babysit you that way they might value that alone.

It is not just skirting unpleasant tasks. Some positions are largely repetitive - if you can not deal with that you are not suitable, period. I am unsuitable for them too, but I am quite happy that I have colleagues who are suitable. It is not actually that easy to find people who will reliably do boring work. Some positions require you do deal with problems nobody managed to optimize or difficult customers or such. Again, if you can not deal with that you are not suitable and if you can, that such ability is pure merit. Quite a lot of "hackers" run away from difficult tasks that require you to understand abstractions and such - I am good at those. As much as those "hackers" can assume me to be less capable because I did not flocked to cool new language, I still have skill they don't have.

Knowing what you are suitable for is important, but as I said, all the resentment and condescension towards people who are valued for their actual contributions is absurd.

I don't believe the author is looking down on people who work on boring, critical systems.

Rather, his point is that people who go _out of their way_ to hoard knowledge on ancient systems and make themselves critical are people you want to avoid. As a single point of anecdata, the best engineers I know want to democratize information - they hate tribal knowledge because it creates a point of failure and bottleneck in the Keeper of the Tribal Knowledge.

There was not a single mention of refusal to share information nor refusal to document. Just that they assume responsibilities others don't want do and that they work on critical systems.

Going out your way to learn about systems that needs to be maintained is a good thing (if that is hoarding). I want team full of people who are like that.

The original post specifically calls out hoarding:

> On the other hand, the unskilled tend to have a slightly different curve: Value Convergence. They eventually settle into a position of mediocrity and stay there indefinitely. The only reason their value does not decrease is because the vast amount of institutional knowledge they hoard and create.

The quote you're addressing (from another article) is also qualified in the original source, under "Responses to comments" / "Not everyone ‘left behind’ is incompetent": http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-d...

> So basically, they are people willing to do work that is needed and doing it responsibly. The work you are not willing to do and doing it without throwing temper tantrum over being too good for the work.

Basically there are people who are willing to drag your organizations failure to build a reasonable system into the future to keep you business.

I suppose you probably do want a team like that if you're the owner.

Process is the enemy. Reward people for business impact, and fairly evaluate that impact, and all else will follow. When something goes wrong, don't react by adding process to prevent the thing that will go wrong.

The costs in slowed developer velocity and increased developer frustration are largely invisible, but cumulative, and they lead to unhappiness and organizational paralysis.

>Process is the enemy.

Nowhere in the article is process mentioned. So I'm not sure how you concluded that process was to blame.

Let's say that process is the cause. How would you evaluate and reward people for 'business impact', presuming we have a method of determining it? Wouldn't it be through a process?

Perhaps what you meant to say was that poorly designed processes or a process driven culture cause problems, one of which is employee boredom.

FWIW it doesn't need to be in the article for someone to provide their own viewpoint and experience

> Reward people for business impact

Very easy.

> and fairly evaluate that impact

Very hard.

I think the overall theme here is a distinction between cultivating an employee, rather than extracting value from one. Another comparison is between a long-term relationship and short-term.

A narrative is part of a long relationship, a story that evolves and grows over time, holding your interest through the climax. This works with an employee/employer relationship because it there's an evolution of learning about the different characters and environment, discovering problems and solving them.

Anytime an employer forgets that employees get something out of work aside from rewards/benefits/payment, they see only a scale with a cost center on one side and a resource to be mined on the other. And they want to mine more than they spend.

Compare that with a garden, remembering that you have to give the garden something. Yes, you provided soil, and the plants get nutrients. But do you care if they get watered, the weeds are taken care of, and the sun is shining?

Cultivate your employees. Help them grow, and you'll benefit from that growth. Eventually, harvest time will be over, and they will leave for greener fields, but you'll have enough stored up to get you through winter.

Surprised an outsourcing push isn't in there; nothing demotivates more then your employer seeing you as an expense they can get cheaper if they outsource.

IME outsourcing was thought of as a way to get things done faster. It didn't seem to be a net gain and it was just viewed as a minor extra annoyance the team lead had to deal with.

It's really dumb and patronizing to believe that people who won't leave your organization chasing a dream are automatically your dumpy leftovers. A lack of ambition doesn't imply a lack of skill.

> A lack of ambition doesn't imply a lack of skill.

This is a very astute observation. I've worked with many really great engineers who wouldn't switch jobs even if they could command a better compensation... because they are happy with their work and compensation. Doesn't stop them from being great engineers or constantly learning/adapting to new technologies.

A lack of ambition does not necessarily imply a lack of skill but it often does, often enough to result in the "Dead Sea Effect" the author refers to. I've seen it over and over at just about every company I've worked. The people who are really good and have the best career options tend to take those options, leaving behind SOME people who are also really good, but mostly people who don't have the option to leave.

To continue the metaphor, the actual Dead See does still have some water in it.

sea

I actually enjoy work more after being at the team a bit longer - after I proved myself and they trust me. When you change the team/company, there is that period when they do not trust you and you have to be proving yourself constantly + dealing with colleagues who try whether you are suitable for being micromanaged or try to socialize by picking on you etc.

I like the work much more once these factors are settled - e.g. once I established boundaries and once I am trusted.

That's a really weird trend. I am seeing this in my company right now and have seen it before as freelancer. A lot of managers distrust the people who have been working for them for a long time. It seems the longer they work for these managers the less respect they get.

I like the description of the "Value Apex". I admit I haven't heard of that one before but it makes sense, and thinking back it's usually the reason I jump ship, and indeed is probably the way things are headed in my current company.

When you start at a company (and early in your career), you can add value Z, and get rewarded Y in proportion to your work/output X. Where Y is whatever motivates you, money, advancement, interesting work, etc. As you remain in a company, Y and Z tend to reduce over time sometimes even to zero, to the point where additional marginal work does not result in commensurate additional marginal value/reward. At that point you've hit your ceiling. You're stuck. If you have any ambition at all, you're headed for the hills, to a place where you can start expecting more proportional reward once again.

Some people don't care--they're happy to hit their position's ceiling, and just hang out there until they get bored. For ladder-climbers it's pretty much unacceptable.

I don't see the point in being honest about why I left my last two positions.

If I was totally honest it would come across as an insult to the company and its management/HR teams I'm sure, and I've been advised never to burn bridges.

There is a slim chance my criticisms could have improved conditions for the colleagues I left behind, but I find it very unlikely.

Reply on news.ycombinator.com