The worst programmer I know

At the time, I was known as a "Windows expert", so they hired me to help improve that version and help the team get more familiar with Windows programming.

I would often spend the first part of the day on what I called "house calls": visiting other developers' offices to either pair program or troubleshoot bugs or just talk about Windows API best practices and the like. (Yes, we all had private offices!)

After a while, one of my colleagues asked a question that stuck in my mind: "How can you afford to be so generous with your time?"

Sure enough, a few months later I got a review with a mediocre rating and a comment: "Your productivity hasn't been quite we hoped, especially considering that the rest of the team has gotten more productive lately."

Which was exactly what I thought they had hired me for!

Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.

Teams that gamed the system and understood the impossible task they were assigned always gave the highest points total to a ticket they could or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.

In an environment like that playing by the rules is a suckers game.

When I eventually quit, every sr engineer at the company; 7 total, followed me within 4 months.

Let me tell you a story about a friend of mine, codenamed tommy. Tommy was an IT guy with incredible skills in networking. He moved to an energy company, fully-owned and operated by the government. Just a few weeks from his arrival, they had to rebuild the entire network from scratch with new, modern, equipments as well as extending the network to all the buildings of the company’s headquarters. They started to look for external contractors to outsource this project but Tommy was shocked by the price the financial department was willing to pay to get this work done, obviously, some non-tech people made the estimates. Tommy interrupted the operation and told the appropriate department he can do the work and needs only the physical equipments (routers, switches, cables) and two guys who can do the cabling. They agreed, and he took the challenge and delivered the work as expected within just a few weeks within less than a tenth of the initial budget. All that he got was a ”Thank you, you did good work” oral endorsement by his boss.

What a time to be an IT techie when your boss(es) are just old-school, who will never understand your true value.

The value of writing good code is self explanatory. You probably use some of his code today.

But he was also great in a firefight: customer is dead in the water and it might be our fault. He’d show up cold and “jam his fingers in the holes in the dam”: quickly figure out what was wrong and then rapidly write and install the most hideous spaghetti code that cot the customer up and running. Code that could not be checked in, or be refactored. Eye-bleeding stuff. Someone would have to take the time to engineer a proper fix, but the immediate crisis was averted.

I was actually much more impressed by the latter skill — among other reasons it’s simply rare. Also he was just a nice guy and everybody loved him.

(Won’t name him since I described some of his code as hideous)

Just to be clear, I’m not talking about programming skill or value. I’m talking about employment and evaluations which I think most people are commenting on.

And also, it’s not mutually exclusive. I know many people who are very productive and also manage their optics well.

Helping juniors do their job is great and all, but you still need experienced people to work on the hard and complex stuff that juniors can't because they don't have the knowledge/experience/people-skills. No amount of pair programming can replace that.

You don't want to be in a situation where you have really really well implemented low-value features, but the high-impact and high-priority hard stuff was not done because some of your most experienced folks were helping the less-experienxed people write effective unit tests or whatever.

Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently write 5000+ lines per code per week, regardless of how many features they actually ship and how many bugs they introduce.

As a team lead and engineer who has managed some complex projects, the idea of someone writing over 2000 lines of code per week terrifies me... That's over 100K lines of code a year. Think of the unnecessary complexity. There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time though that would only amount to 380 lines of code per week! Management won't like that.

I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.

This is very, very analogous to software teams. It’s the mix and results that matter most.

It is never good to measure the "one" metric and manage to that, it results in people who game the metric "winning" and fosters the promotion of such behavior. I pointed this out to Google leadership and to quote Lazlo, "This is the system we have, it isn't perfect but we're going with it, either work within it or don't, it is up to you." :-). That meeting told me everything I needed to know about whether senior leadership was trying to have a better engineering environment or not.

To many new managers come into the job (especially if they were engineers individual contributors before) with the idea that if they keep the "best" members, and move out the "bad" members both team morale will be great and so will the teams output. But they miss that their understanding of "best" is not based on managing people, its based on getting their original job done. As a result they favor people who mirror their skills and habits and disfavor those who have different skills and habits. Getting them to see this and having their eyes go wide with realization is always interesting.

If you work on a factory line, you can measure widgets per hour and quality. In construction, you can measure distance or area completed. But in programming, you are not making a repeatable product like the factory line. You can say that developers deliver story points; that is the product, not the work.

I invite you to come up with your own answer before you read mine.

----

----

----

I think the inner cycle of development is learning and trying. You learn about a system, make a theory, try that theory out, try to extend that theory, then you test. That test will let you learn some more - was I right or wrong, was there some side effect. Then you repeat.

I don't think this learning and trying is a good unit of measure for performance, but I do think it's a good basis for an engineering notebook, which may be reviewed with a manager.

Non-junior developers are essentially managing themselves when it comes to getting the work done. So how do you manage a manager, when that manager is not responsible for widgets?

It just takes one jealous colleague or one "efficiency minded" manager type to completely rug pull you. I know it's valuable because I have benefitted from that person many many times, but it takes empathy and a lot of balance.

I think this is what we can do to help: Remember sometimes we are also those co-workers who took help from Tim around us and conveniently forgot to Thank their contribution in success of our project. A simple thank you note in the right meeting, slack channel or in the project delivery mail goes a long way. Measuring the indirect impact of an employee is hard, even if you were the manager at any level. Taking help is not a sign of weakness or acknowledging the contribution of a co-worker doesn't make your effort any smaller.

A common refrain in basketball is that people forget it’s a team sport. Doesn’t matter how good you are individually if your team sucks (see Michael Jordan in 1988 or Lebron most of his career). Similarly programming is a team sport. Individual stats are not the same as team success.

Then then socialize with managers outside of the team, bragging about how much 'value' they're adding and they can talk as if they helped others. They move around a lot, getting promoted each, adding no value other than just talk with no clue on how to do things.

His English wasn't great. His Javascript wasn't "modern" - he kept using callbacks etc. He often poo-poohed ideas the younger wizz-bang devs had. And so I was warned - basically he's an old curmudgeon, set in his ways, he can't take any criticism but he'll dole it out, a pain to deal with.

I quickly learnt how untrue that all was. OK, his code isn't great. BUT he's 100% committed to delivering customer value. He understands the ins-and-outs like no one else. He thinks through every scenario from the customer's perspective, and absolutely NAILS it every time. The young devs didn't like him because he didn't give a shit about "GraphQL versus REST" or "Hapi.js vs Express vs Koa vs whatever".

Where the other teams would avoid involving him in design conversations, I'd pull him in straight away. And our team reaped the rewards of integration projects that delivered right out of the starting gate, rather than customers kicking them right back with complaints.

He was let go and the project became a lot less successful and enjoyable, once he was gone a large group left soon afterwards...

High performance teams at Thoughtworks really had almost full autonomy over how they worked. At a particular credit card bank in Delaware circa 2006, Jay Fields and I demanded (and got) flat screen monitors, our own conference room to use as a dedicated bullpen and most importantly, unfettered access to the open internet via custom holes in their firewall. Crazy times.

What the author describes is the effect on a solid senior engineer working in a terrible organizational system for a not very skilled or savvy manager.

Such managers (and directors and VPs) are common, even in the top tech companies. They may occur less frequently in those companies, but skilled, savvy managers are much rarer than excellent engineers, so the dysfunction described continues unabated in all companies.

> Instead we would measure stories delivered, or it may have been story points (it turns out it doesn’t matter), because these represented business value. We were using something like Jira, and people would put their name against stories, which made it super easy to generate these productivity metrics.

I have never worked anywhere where middle management measured individual engineers via issue-tracker metrics. That seems almost implausibility dysfunctional. It’s not just measuring a hilariously wrong thing at the wrong level of granularity, it’s also disempowering the line manager from evaluating their own people. Is this a real thing companies do?

Like, for someone in tier 1 / tier 2 helpdesk, or the regular developer pushing relatively normal tickets through, simple ticket or story throughput is one indicator of productivity. As long as you pair it with some success measurement, like re-reports from people within a short time, or work caused by the implementation. Or just feedback from the rest. Someone has to put down code to make the feature work in the end.

But this changes when you get more specialized and overall more experienced. If we bring a new technology into the team, my productivity based on the first metric will drop to zero. I'll be busy supporting other people. Or, the incidents on my desk will be far more weird ones. Other people get clear click paths and an exception. I had to debug JVM crashes due to faulty hardware. That took a bit longer than an afternoon in a debugger and adding an if-statement, if I may embellish a bit.

But that's why soft skills become important. It's concerning how little that manager knows about his team. But it's also concerning how Tim didn't make sure his manager knows what's going on. For example if we're bringing in new tech, I'm informing superiors first that I'll prioritize support of team-members with the new tech just below business critical incidents and I most likely won't do any regular work for some time.

Without quantifying it or comparing to an alternative, this is just feel good commentary. If you deliver any value, that does not consequently make you a good business decision. You have to pit your value against your cost and the companies best alternative option.

Also, if a company measures my value in widgets, I have found my career does quite well assuming widgets is the right way to measure my value. Assuming you know better than everyone in management is prideful and not good teamwork.

I think the managers who don't understand this type of role are the ones who were largely mediocre engineers, but were able to get to that position regardless. They just don't understand the process of engineering and that's it's not just churning out tickets or doing the bare minimum if you're working on something non-trivial.

This was the money quote.

Teams do big stuff.

Good teams do good big stuff (very good).

Bad teams do bad big stuff (very, very bad).

It seems that the hyper-competitive nature of today's workplace means that engineers consider their own teammates to be "competition," and we never really get a good team. This is especially true, with the mayfly tenures of most engineers, these days.

I'm fairly happy with the fact that I was able to keep a stable team of experienced, high-performing, senior C++ image pipeline engineers together, for decades.

Other managers would bust my chops for being a "Santa Claus" manager, because I refused to burn them out, and often intervened, when other managers were being too hard on them.

It seemed to work. When my team was finally rolled up, in 2017, the engineer with the least tenure had a decade.

Not sure why this is the #1 article on HN right now, other than maybe the (what I would consider) click-baity headline. But I wish there was an acceptable way for HN to use more fitting titles for articles (especially since most articles always use a click-baity headline). E.g. would it be at the top if the title was "Don't measure performance by story points"?

I guess some interesting anecdotes have resulted in the post, but the message of the article itself doesn't seem to share anything particularly new or enlightening.

I’ve also met a lot of project managers who are there because they’re incompetent. They lean heavily on “agile” and “best practices” and say moronic stuff like, “can you show me how many lines of code each developer has added this month?” (this happened to me. I fought it hard, explaining that it’s not a meaningful metric. I showed him a month that I wrote -1500 lines of code).

I feel like I could say the same about managers, coders, executives. The incompetent exist everywhere and they lean heavily on bureaucracy to protect their existence.

Don't spend all your "empowerment" energy at one company. Companies WILL undervalue "glue" developers (and also "glue" teams). Eventually being so focused internally can hurt you.

Instead, if you're good at helping others, do it publicly. Speak, blog, participate in open source. Turn your "helping others" energy into one of helping the broader development community. Pay it forward there and it will reap more dividends.

Senior engineers in my knowledge and experience are all delivering on something relatively high impact while contributing massively to the team by occasional/often "pairing".

I've seen rare examples who don't "pair" but just deliver by themselves.

I've never seen an example where they don't deliver on anything (planning, design, architectures included) but only "pair" as their job every day.

I’ve already spent the last quarter either complaining about coworkers or praising them, now you write the damn report! And as for the self evaluation, again, you write the damn report… unless you have no clue as to how I’m doing, to which I say, your performance really sucks as a manager.

He ended up promoted; in many organizations, people that hack the code rather than properly design and build sustainable solutions are highly valued.

Anw when I was data engineer at a big corp data team, I was the one the 2 seniors there with 20 juniors, like fresh out of the colleges. So the juniors ended up ask me with everything since it was faster than googling them self. I still deliver things in my responsibilities since I can do it quick, also spend like one third of my times to mentoring them. Later, I found out that my manager thought I was slacking off, not working to my full potential.

Yes, the manager never payed attention to how the team worked. All the juniors thought that I was the reason the team was running smoothly and quickly. Ok, fine, I realized sometimes you cannot just work, you need to sell your work, even in your companies.

The nature of data engineer job is to ensure things run ok. So everything too well for a long time, then the higher ups might think it is easy. It might sound like bad thing, but when a bug happened, sometimes I let it be if it is not too serious, to let it rises to the higher ups. Of course being able to solve it quickly is a must.

BREAKING NEWS: Pair programming improves software quality, more at 5!

Given that the thread is no longer visible without an account. They might want to do that sooner than later if they want people to actually read it

I dont see a downside to doing this.

Ultimately the best way of measuring programmer productivity is by the assessments of the programmers on the team. This isn't as easy as it seems. For example, I once worked on a team where the best Heroku guy just had the absolute wrong idea about "easily understandable python code" since he would prefer to raise and catch an exception instead of rely on a built-in to test attribute existence or type compatibility. But nobody could get around large scale Heroku deployments like this guy. The juniors understand this nuance less well than seniors do, but even so, it does sorta come out in the wash. Your team does know its best people and they're usually happy to say it in a private one on one.

But it's usually contained to someone like a junior calling me up and saying "can you help me?". The answer is always "yes of course!" and I share as much as I possibly can. But it ends there.

I just want to sit down and show them things. Teach them in a way that makes things "click" the way I found they clicked with me. But I don't think management really values this approach. We get siloes of knowledge and then when someone leaves it's all hands on deck to transfer that knowledge.

I'm often brought onto projects as a firefighter because I'm seen as productive. But I think the more important thing for the team would be to have me upskill everyone else below me. But for whatever reason, it's hard to get that point across to management. I can see myself in a few people and that they have potential, they just need encouragement.

I am a disagreeable giver myself and I have experienced a lot of backlash by the higher ups inside companies for being one, while also being praised a lot by my colleagues that were working alongside me.

A previous discussions about it:

"The best employees are not the agreeable ones" - https://news.ycombinator.com/item?id=17386640

Unfortunately in my current experience my manager is not at all like Tim.

Communication skills. Week 1 Tim could’ve brought up the issue of overall developer productivity with his manager and his manager would’ve at least been aware that Tim wasn’t just playing Minecraft all day.

The author has obviously never tried to build anything non-derivative in a team. This metric only identifies the noisiest inexperienced programmers, that go through other peoples work... like a monkey on crack throws its poo. These folks are often successful in business, because anyone that actually grasps real workmanship is already busy. The main problem is meritocracy eventually fails, as someone biased must choose what constitutes "good" work. Thus, a pseudo-Technocrat just follows foolish idealism with extra steps... and becomes a Marketer in time.

The truth is "all software is terrible, but some of it is useful..." depending on the end use-case.

Happy computing, =)

The issue now is of course you are just incentivising taking overestimated stories. This cat and mouse never ends. Crucially you are punishing/removing the glue people that do the stuff not specified that needs to be done. So now you need every little thing on the board. And a lot of time on arguing about what should be on.

It is worse when the tasks allowed on the board have to be agreed by a committee that meets on a Wednesday. Not joking that has happened! But that is another story.

Too bad I quit before the CTO, CEO and most of the board members got fired. Would have enjoyed sitting there and going. Yes, yes, yes.

In this particular case, I can think of a few reasons why the original scenario that this team was in would still be considered "bad". For example, maybe Tim received tasks to do and he didn't do them, now the company is behind on things. Maybe the other people are not as good as their job as they should be, but because of Tim's interference that's being hidden. Maybe the expectation is that the other people are as good as Tim, so why are they not helping each other out as much as Tim is? Should Tim get a promotion, or are the other people performing badly compared to their position and salary? Maybe the tasks that Tim was supposed to do are more important than the ones he's helping others with. Maybe the company didn't budget this much investment (2 people) for a specific thing that needs doing, and as there's just so much engineering time going around, what other tasks are now receiving less time than budgetted?

There's so many ways where this story may fall apart in a real context. Obviously, something has to change (expectations, budgetting, salaries, job levels, etc...) to align reality with the direction that the company wants to go into, and that change is not necessarily (limited to) "keep Tim around and have him help everyone out and everyone will be OK and this is the optimal scenario and management bad".

The implication also being that "evaluating people on story points is bad", but that completely disregards the fact that doing this has surfaced an issue in the department that needs resolving (and before I get pitchforks thrown at me - that issue may very well be that Tim needs a change of job title and a promotion) - but obviously expectations and reality didn't align beforehand, and the story point metric surfaced it and allows for resolving it. In that sense, the story point thing yielded benefits that otherwise wouldn't have been had.

Well I do know why just don't agree with the principle of seeing how much the company can get out of a developer in x hours.

I was assigned to help team members on the lowest rungs of "performance" metrics. My stats went to shit.

Some teammates smashed it, others didn't. My influence and pay increased and nothing felt right.

Ended up leaving the best org of the company because I couldn't (at the time) understand what was happening.

IMO, looking back, as amazing and 'right' as this scenario feels (OP and myself), it needs the full support of the entire company to make it work.

Pretty clickbaity title. This isn't a story about a bad programmer, it's a story about a bad metric, and an even worse manager who followed it blindly

Suppose the bank Tim worked at decided to measure the number of pairing sessions each developer participated in—I suspect this too would destroy the team.

When you measure people doing X, you are really measuring people pretending to do X.

Well, last 2 years i played that without the coding part (as a CTO!).. but not sure if anyone up-there noticed.

So i slowly start to dispirit and go bitter.. Seems Consumerism (throw-away-buy-new culture) ate the software/knowledge profession too.

i don't know, either noone needs deep, experience-backed, 360' looking knowledge, or it started grow on trees?

https://noidea.dog/glue

Bingo.

If I ever hear anyone in my company attempt to deliver a sentence like that then I will go postal.

But that is balanced by the threat of people trying to use metrics to measure developer productivity. It doesn't seem to be possible, any metric falls apart. If people are focusing on a metric, the greats aren't going to be leading any more. It'll be some junior who has misunderstood the system and has accidentally trained themselves to game metrics.

Metrics do not drive good software. Repeatable processes love metrics. Repeatable software suggests bad development practices because that is a big hint of a library or bigger opportunity that nobody on the ground properly identified.

For small companies, engineering managers & direngs should be aware enough through working with the team members individually & through PR review who is performing and who isn't, and not need to deploy metrics.

- 10x productivity yourself - Adding 2x to five 1x engineers

Non-technical management will never appreciate the engineering multipliers like Tim

Then exclude non-export numbers and divide that by the number of KWh used to generate that revenue.

Edit: Please comment on down vote, otherwise we learn NOTHING!

  Tim’s productivity score was zero

Most of the time he would try to pair up. He just make noises that implies he is following your work. But you can see that is not the case when he tries to make a comment or a suggestion, he is clueless. Trying explaining things to him is a waste of time.

Rarely he decides to work on a task himself. No matter how trivial the task is, he needs someone to spell out what to do step by step. Even then when he sends a code review, you can find some surprises. He becomes a net negative because he can take a task that should take 2-3 hours top for a regular dev and then spends 1-2 week on it while also wasting more than 2-3 of someone else's time.

It is always fun to see him grab an easy looking task that is way beyond his capabilities and then struggle for weeks and tries to weasel himself out of it.

I never saw someone so immune to learning. He is in the team for over 2 years yet has a productivity of zero. I don't understand why companies keep such people

Every team knows their best performers, and their lowest performers. The number of points aren't going to line up with performance most of the time, precisely because time helping others is never going to show up. And if suddenly getting help lowers your review, you are going to ask for less help, not more: Trading accuracy in external performance tracking for lowered team performance sounds really dubious.

I do not like people who do this. just tell me the answer. this is such a gigantic waste of everyone's time. you figured something out months/years ago, great for you. give it to me NOW, so I can get on with my day. if we BOTH run into something unknown, we can tackle it together. but dont force me to go through the same painful learning process you went through. YOU suffered, because at the time no one knew how to do whatever it was. now that someone knows (you), your job should be to spread that knowledge across the business as quickly as possible, not hoard it to yourself until someone is deemed "worthy" of knowing it.

That's a disgusting way to think about productivity, the result of otherwise smart people growing up in a capitalist exploitative system.