Hacker News new | past | comments | ask | show | jobs | submit login

From 'Software Requirements & Specifications' [0], by Michael Jackson (not that Michael Jackson, and not the other one either), published in 1995, a parable [1]:

'What do you think?' he asked. He was asking me to tell him my impressions of his operation and his staff. 'Pretty good,' I said. 'You've got some good people there.' Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.

'What did you think of Fred?' he asked. 'We all think Fred is brilliant.' 'He's very clever,' I said. 'He's not very enthusiastic about methods, but he knows a lot about programming.' 'Yes,' said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. 'Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it.' His voice dropped to a reverent hush. 'Fred tells me that he's not sure he understands it himself.'

'Terrific,' I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. 'But what about Jane?' I said. 'I thought Jane was very good. She picked up the program design ideas very fast.'

'Yes,' said the DP Manager. 'Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet --- if you see what I mean?'

I saw what he meant.

[0] http://www.amazon.co.uk/Requirements-Specifications-Software... [1] http://www.win.tue.nl/~wstomv/quotes/software-requirements-s...

I've noticed over the course of my career a fairly severe corollary, which is that making the best technical choices for my employer can often be bad for me in the long run.

As an example, for about the last 10-15 years, I've tended to choose Python over C++, for projects where it seemed it would produce a better solution (e.g., cheaper/faster to implement, easier to maintain and alter, performance sufficient to the task at hand). Because Python is actually quite adequate these days for large swaths of the task space, this means that my Python chops are quite good, but that my C++ is a little rusty.

In itself, this isn't exactly a problem, but in an interview scenario, it can look quite bad. "How much template metaprogramming have you done lately?" "Not much." "So, you're more of a junior programmer then?" "No, I just haven't hit a problem lately that needed that, and I prefer not to introduce unneeded complexity and maintenance nightmares into my employer's codebase." "How much work with GDB automation?" "Very little, since the code I write pretty much just works." "Ah, so weakness with the debugger as well." Etc.

Not really sure what to do about this. I don't really want to write tens of thousands of lines of unnecessary C++ just to impress future employers. But I have to acknowledge that that's really how the rewards are set up.

This dynamic is part of why I feel like programmers should really just stop resisting the pull to move into management. You might think about programming as the most amazing thing ever, to be agonized over with a fine-toothed comb and the 'best tool for the job' elevated to a nigh-religious consideration, but to your employer, it's one line item on a budget.

It might be 'easier' in a certain sense, and possibly a way to optimize for your paycheck, but 'resisting the pull to move into management' for me is about wanting to do high quality engineering, having a sense of professionalism and pride in my work, and feeling good about what I'm doing at the end of the day, even if my management doesn't understand it fully. If I'm a "line item on a budget", I want to be the best damn line item I can be. I am an engineer.

You can do high-quality engineering in management. You're just doing it with other people's code, as well as your own if you choose to continue programming.

What activities would you expect to be doing in such as scenario? For me, if I was doing it "with other peoples code" rather than "with other people", I would expect to be doing things like large scale architecture, developing tools such as domain specific languages, and investigating new technologies for possible adoption, setting the stage for the rest of the engineering team to write good code and solve hard problems. I would consider this engineering, and "working with other people's code." I would feel some secondary 'ownership' of the rest of the teams code in this scenario.

On the other hand, if I was working "with other people" as in a managers potions, the most technical things I would expect to do would be making hiring decisions, considering the skill sets and training needs of a team, and helping a team make good technical decisions, as well as other less technical manager duties. I see this as a separate management role, that doesn't really involve engineering, and working "with other people" rather than the code they produce. Importantly, I would NOT feel much ownership in their code in this scenario. I would feel ownership in their success coding, but not in the product itself.

You could, possibly, do some of each although I find the two work styles severely interfere with each other, so focusing on one at once is far more effective. If you are an amazing person you might get away with sneaking in some engineering time while being an passable manager as well. If I was in a managerial role, I would focus on that to allow myself to be more effective, and get my engineering satisfaction elsewhere.

Note that some large tech companies recognize this difference, and have explicitly create two distinct promotion tracks, one through management, and one through engineering.

I feel it is a tragedy that many companies feel that "engineering is the thing you do first, they you get promoted out of it into management to continue your career," and structure their org chart with engineers at the bottom.

I think this comes from people who enjoy and are good at management not recognizing that there are people who are not like them, and building a hierarchy that reflects their world view. If more companies realized that there are people who want to be good engineers throughout their career and could relate to them better, more amazing engineering would happen, and it would be well managed too.

Rebrand yourself as a python developer.

I know you might not want to hear that, but you'll probably find much more enjoyable employment anyway.

Essentially, that's where I'm at, as a practical matter. But it feels wrong to be typecast that way, since I regard my C/C++ capabilities as being quite sharp as well. And it seems like knowing when to write 100 lines of Python instead of 1000 lines of C++ ought to be valued, rather than seen as more of a technical faux pas. (Hey, I can dream, can't I? :-)

Work for people who are more concerned with the business value you provide and how fast, and reliably you provide it, and who don't care about the details of what technology you use.

This often means being hired by the CEO and not the CTO.

Great story. Reminds me of

"Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." - Alan Perlis

Along similar lines:

"Make things as simple as possible, but not simpler." -Albert Einstein

If you liked that, you should definitely read The Parable of the Two Programmers:


The main thing I read in this parable is the intense focus on comparing individuals and putting them at odds, instead of working to find the best way they can work together in a good system.

What's the core problem there? Why do people think in this way, instead of more systematically? What's the intention and what are the assumptions? Many questions raised.

I'll try to address a few points here:

-What's the core problem?

Evaluation. In this case, evaluating intrinsic difficulty of a certain task or group of tasks. There's no way to do so systematically, without inside knowledge about the task. Foe example, suppose you want to rank two mathematicians without a clue about the subject matter. One presents short proofs to many problems, while the other presents enormous proofs with great effort. There's no way to tell if the problems are really difficult or not and chose the reward without having knowledgeable peers evaluate the a) hardness, and b) usefulness intrinsic to the problem. In fact, it could be argued that simplicity is a good sign, but it's impossible to tell whether the problem is unimportant/trivial to begin with.

- Why do people think in this way, instead of more systematically?

Without insider knowledge, which management sometimes lacks, you cannot confidently rank as stated above. But there's one trivial thing you can do, which works, but not necessarily efficiently: if the solution works/is found, reward the solver, otherwise punish/look for others (and reward them more). Hard problems skillfully solved will go unrewarded and good performers will gravitate towards fixing crisis instead of doing good ground up engineering as they should. That's the aspect of inefficient, but it is possible with enough money to manage this way.

The answer to both is to look one level up, at the meta question. Both of your answers are still about evaluating individuals. Instead, look to the system both individuals are in.

In this case, the system encompasses the evaluation itself, and the answer is to cease evaluation altogether. You can clearly see the problems it causes.

How do you choose who to pay and how much?

In an individual manner commensurate with their contribution and market value, as simply and clearly as possible. It is not complicated, and making it complicated is how we end up in cultural negative feedback loops. The standard performance assessment does more harm than good, and we absolutely should not use it.

Some external resources:





And finally, Deming's own brilliant opinions:


"The merit rating nourishes short-term performance, annihilates long-term planning, builds fear, demolishes teamwork, [and] nourishes rivalry and politics. It leaves people bitter, crushed, bruised, battered, desolate, despondent, dejected, feeling inferior, some even depressed, unfit for work for weeks after receipt of rating, unable to comprehend why they are inferior. It is unfair, as it ascribes to the people in a group differences that may be caused totally by the system that they work in.

The idea of a merit rating is alluring. The sound of the words captivates the imagination: pay for what you get; get what you pay for; motivate people to do their best, for their own good.

The effect is exactly the opposite of what the words promise. Everyone propels himself forward, or tries to, for his own good, on his own life preserver. The organization is the loser. The merit rating rewards people that conform to the system. It does not reward attempts to improve the system."

-- W. Edwards Deming

And even more in depth: http://blog.deming.org/2012/10/dr-deming-called-for-the-elim...

In short, the method by which you determine fair pay is very much irrelevant — so long as it does not involve the detrimental practice of performance appraisals. The main focus of both you as a manager and your employees should be on the system of work, not on the individual. Deal with the individual's fair compensation simply and clearly, and discard all by-products, as they are unproductive.

Is this book worth buying?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact