56 ms·

The worst programmer I know

• pydry 3y ago
  I sometimes wonder if developers should do an end run around all this bullshit and come up with and start measuring management productivity metrics. I dont see a downside to doing this.
  • ruined 3y ago
    it's called a labor union
    • commonlisp94 3y ago
      unions don't measure productivity. They group people based on credentials + experience, and treat everyone as interchangeable within those buckets.
      • rexpop 3y ago
        That's one possible union architecture, sure, but you're missing the forest for the trees. A union offers job security to reduce the risk of "managing up."
        • commonlisp94 3y ago
          > one possible union architecture It's the one used by all the major ones: airlines, auto manufacturers, and teachers. What institution do you know of that has a greater emphasis on measuring performance?
          • rexpop 3y ago
            A union's priorities reflect those of its constituent members.
      • pydry 3y ago
        You're thinking of management. I'm sure most unions would love performance based pay where union reps decide what constitutes good performance. For some mysterious reason management is as keen on unions exercising their judgement as unions are on management deciding. Where unions agree policies that treat members as interchangeable (e.g. age based pay) it is usually as a result of a compromise brooked with management who would love to have the latitude to give pay raises to scabs, kiss asses and spies.
      • criddell 3y ago
        That's not generally how it works in professional sports with player unions. Nor does it work that way in the film and television industries where there are unions representing writers, directors, actors, etc... The shape of the union is whatever the membership wants it to have.
        • commonlisp94 3y ago
          Both of those examples have weaker unions that play less of a role. Also the poster above suggested that the union as opposed to the management could measure performance. That doesn't happen in sports or TV.
  • rgblambda 3y ago
    Managers don't stay in the same role long enough to have their productivity measured.
    • Cerium 3y ago
      Really? From my manager and up at least 4 levels has been unchanged for at least 8 years. Titles changed some, but the same people are in the same effective roles.
    • throwaway92837 3y ago
      They measured by the perceived output of the team. Give them credit for being self-serving, at a minimum.
  • h2odragon 3y ago
    How would coming up with good metrics for "management" be any easier than coming up with good metrics for "programming"? At least programming has some verifiable realities that can be witnessed objectively by multiple observers. Not that such things are often used on "metrics", but they could be. The quality of someone's management is hard to assess from outside, much less objectively verify. Has your manager increased or decreased your productivity today? Was it necessary that they do so for a larger goal you're not considering? Were they just power tripping?
    • pydry 3y ago
      That's exactly my point. Managers who protested the use of metrics on them would inadvertently undermine the argument for using them on developers. Measuring is an aggressive act intended to invoke control that has a veneer of innocence. That said I'm now wondering if there wouldn't be some metrics which might prove useful to workers either way.
  • TheDong 3y ago
    "Hey, boss who can fire me, I just thought you should know that we on the team have started keeping metrics. I want you to know that your 'times you made the only girl on the team uncomfortable with a sexist joke' metric is unusually high this month, and your 'unblocked the team by speeding up an external request' metric is 0 for this month, down from 3 times last month" Let me know if you find any downsides. Anyway, management will of course argue that developers under them are incapable of seeing everything management does. After all, management's job is to shield developers from other managers, so if the developers think all the managers at the company are worthless, that's actually a sign of how well management did their job of shielding each other's teams from each other.
    • tjpnz 3y ago
      The logical conclusion to that argument is that we should do away with the lot of them.
      • bee_rider 3y ago
        We all feel like management contributes nothing, right? But they seem to always be around successful companies. I dunno, correlation isn’t causation, but I think there must be something there.
        • TheDong 3y ago
          Weirdly enough, many unsuccessful companies I know of had management too. Correlation isn't causation, but maybe there's something there. There are also plenty of successful companies and projects without management too. Basically every 1-to-5ish-man consulting shop has zero managers and some of those do wildly well. Some of the best indie games, produced by teams of 3 or 4, had zero dedicated management. Most open source projects have effectively 0 management. Valve, famously, kept a flat organizational structure for a long time, and certainly was somewhat successful.
      • chaxor 3y ago
        AI is actually now shaping up to replace these jobs much more simply than blue collar work. So, yes absolutely, administrative work now can finally be replaced, and we can free up all the tormented souls in these managerial positions to do something more meaningful with their lives.
  • omoikane 3y ago
    Management also have their own metrics, measured by even higher management further up the chain. Even if there is a manager or director that I really liked and would like to keep, they have to answer to the metrics of their VPs and SVPs above. It's metrics all the way up. People at the top of the hierarchy probably do care about people at the bottom, but it's difficult to care about a large number of people as individuals, so they resort to metrics that probably models what's going on. Unfortunately, the metrics don't always work. Instead of measuring and gaming numerical metrics, enforcing a particular culture might be a better way to go: https://apenwarr.ca/log/20190926 https://apenwarr.ca/log/20190926
• jamestimmins 3y ago
  Reminds me of an anecdote about Bell Labs. Someone calculated who the most productive employees were (based on things like patents received), and found that many of them would eat lunch with the same person. That person wasn't individually very productive, but he would always ask thoughtful, compelling questions that in turn made his coworkers measurably more productive.
  • Erikun 3y ago
    It might be from the great book The Idea Factory by Jon Gertner (p 135). 'In the midst of Shannon’s career, some lawyers in the patent department at Bell Labs decided to study whether there was an organizing principle that could explain why certain individuals at the Labs were more productive than others. They discerned only one common thread: Workers with the most patents often shared lunch or breakfast with a Bell Labs electrical engineer named Harry Nyquist. It wasn’t the case that Nyquist gave them specific ideas. Rather, as one scientist recalled, “he drew people out, got them thinking.” More than anything, Nyquist asked good questions.'
    • avanai 3y ago
      The most impressive thing about this story is that they figured out the answer. They did the research, and nailed down that it was Nyquist who was was the productivity booster. It’s the exact opposite of the OP’s story, where management tried to fire the Nyquist-equivalent.
      • Tarq0n 3y ago
        They found an answer that felt right to them. The reseachers weren't blinded to the context they were working in, and their hypothesis is essentially unfalsifiable so I would take it with a grain of salt.
      • Strilanc 3y ago
        Honestly, I'm kind of skeptical of the answer. I'm not saying that talking with Nyquist wouldn't be useful, probably it was, but what's stopping a dozen other things at least that useful from being part of the answer?
• roenxi 3y ago
  I dislike the just-so aspect of these sort of stories. I'd expect exceptional programmers to do unusually well on most metrics. 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.
  • kstrauser 3y ago
    > I'd expect exceptional programmers to do unusually well on most metrics. ...when they're actually hands-on-keyboard writing software. The best programmers I know write as little code as possible. Product team: Hmm, we need to do a thing that looks very complex and difficult. Senior dev: I'll start making a project plan and story breakdown. Very senior dev: That sounds like a special case of a thing we already have. That should take about an hour. Of course that's a generalization, but I think the trend holds. The most illustrative metric for the best engineers wouldn't be "lines written" but "lines avoided".
    • OnlyMortal 3y ago
      In my experience, the best programmers write the least amount of code they can get away with. I don’t mean they use the latest fashion library, I mean the amount of code they type is less simply because they understand the problem and know how to write a minimal solution. This makes their code easy to read and therefore easier to debug. It’s worth noting that the less you type, the fewer bugs you’ll create. To be fair, this is often due to the coder having significant experience.
    • Fluorescence 3y ago
      > Very senior dev: ... that should take about an hour. Red flag!
• bighoki2885000 3y ago
  [dead]
• 3pt14159 3y ago
  Well, I like the story here, but it's kinda against a bit of a strawman. Don't get me wrong, I'm not losing the overall point of the piece, a point I agree with, but that said a metrics focussed manager could have simply added an "adjunct" label to the stories and had this "worst programmer" add themselves to stories as the non-lead developer. 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.
  • bee_rider 3y ago
    I believe that’s the conventional approach in Python, though? It is a duck-typing language, try-except is a legitimate way of seen if an operator works on an object, and objects should do sensible things with operators. The funny example is that the hasattr built-in just tries to getattr, and then catches the exception to tell if it has the attribute.
    • eesmith 3y ago
      I agree. In Python terms "Easier to Ask for Forgiveness than Permission" (EAFP) is preferred over "Look Before You Leap" (LBYL). https://docs.python.org/3/glossary.html#term-EAFP https://docs.python.org/3/glossary.html#term-EAFP comments: > Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C. and there are any number of essays on the topic, like (random DDG search) https://programmingduck.com/articles/lbyl-eafp https://programmingduck.com/articles/lbyl-eafp .
    • 3y ago
• awesomeMilou 3y ago
  > I explained all this to the manager and invited him to come by and observe us working from time to time. Whenever he popped by, he would see Tim sitting with someone different, working on “their” thing, and you could be sure that the quality of that thing would be significantly better, and the time to value significantly lower—yes, you can have better and faster and cheaper, it just takes discipline—than when Tim wasn’t pairing with people. BREAKING NEWS: Pair programming improves software quality, more at 5!
  • Trasmatta 3y ago
    Extensive pair programming can also be massively draining and burnout inducing for certain types of people. I hate it when companies mandate pairing. Some people's brains just don't work effectively in that type of environment.
    • awesomeMilou 3y ago
      Mandating it is stupid, it obviously depends on the team, task and person. But you can't deny that it's an amazing tool to open silos in terms of knowledge. I wish people would be more open to it, because I've never been able to get someone up to speed faster with a tool or codebase, than with pair programming. And vice versa too. If you're the person that knows less about the topic, pair programming with a senior is like a one on one tutoring session with a really skilled instructor. It's worth the time in gold imo.
• hi_dang 3y ago
  [flagged]
  • mynameisvlad 3y ago
    "Didn't happen to me anecdotally so must be fake news" is not a compelling argument. Also to say it couldn't happen at tech companies is pretty bold. There's nothing special about tech companies. They can hire incompetent managers just as well as other companies.
    • hi_dang 3y ago
      [flagged]
• jongjong 3y ago
  It sucks being that person today because everything is about optics and that person will get purged. I know from experience. 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.
  • 88913527 3y ago
    Because it's a bogus argument. The productive person doesn't need a paper weight at lunch to act as a shower thought generator. Management can get it wrong sometimes, but in broad strokes, they're right.
    • closewith 3y ago
      Maybe, or maybe human endeavour is more complex than individual efforts.
      • 88913527 3y ago
        It's tough, but what I've seen is low performers weigh the team down. They constantly ask for the high performer's time, and if we give them bug tickets, new feature work, they constantly stumble and always report status as blocked. They don't add value. They can't get to the finish line with anything. It's not a kind thing to point out, but trying to angle it as "oh there's this other benefit you're just not seeing" is trying to work around the fact they can't competently fulfill the job function after exhausting all of our options (training, pair programming, etc). They might be friendly people, but the social boosts don't counteract the losses incurred, it's still a net loss.
• peter_retief 3y ago
  I often wondered why s/w development is always a rush at the expense of quality. 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.
  • JKCalhoun 3y ago
    Having been in the industry since the around 1990, I can tell you that in the first half of my career we had no code reviews, no scrum, no story points, no unit tests. How on earth, you might wonder, did we ship software that worked? I then saw all these things come down the pike one after another during the last half of my career. Clearly to me every one of these benefit management who found themselves apparently unable to function without numbers, graphs, data of some sort. It has been a very obvious (to me) power struggle: management trying to get the upper hand and wrest any and all power (and autonomy, and decision making) from engineering. It has been sad to me to have heard some new engineers come on board who like these things. It's just as well I retired when I did: it's probably me that is the odd man out now.
    • throwaway92837 3y ago
      I would be interested to know your career history in more depth. To my understanding even IBM in the 70s had stupid ways of measuring productivity (KLOCs?).
      • whstl 3y ago
        I'm pretty sure there were companies doing stupid things in the old days but in my experience, back then managers were supposed to know what developers were doing, and if they were delivering value or not. They did all that by walking around, chatting with everyone, helping devs, assigning tasks depending on the expertise level, sometimes doing boring work (like manual testing) to help devs, etc. Of course, if a manager that has to handle Jira and Scrum meetings all day, then it gets difficult to do that.
      • JKCalhoun 3y ago
• tetha 3y ago
  The thing is: Different levels of experience need different measures of success, up to the point of leeway from the normal measurements of success. 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.
• ww520 3y ago
  Stories like this happened is because managers want to treat software development as a manufacturing process.
  • TuringNYC 3y ago
    I heard stories from past employers where they wanted bi-monthly increases in scrum velocity. "OK, last sprint the team did 150 points, so we should do 160 points this sprint." The funny thing is that point estimates just went up to compensate for productivity gain demands. "More productivity" yay!
    • ozim 3y ago
      Well I think that is the worst that can be. Maybe best as well because you quickly know to pack things up and look for a new job.
  • yabbs 3y ago
    Stories like this happened is because managers
    • convolvatron 3y ago
      ok. most managers suck. but ultimately you have to have at least one adult in the room.
      • olddustytrail 3y ago
        Indeed. To keep the manager in check, right?
      • solarmist 3y ago
        And usually it isn’t the manager, even if they want to be. They’re managers because they’re good at projecting to their boss’s wants and needs.
• ncruces 3y ago
  This worst programmer sounds eerily similar to the best one (from the Twitter thread).
• Waterluvian 3y ago
  I’ve met a lot of project managers who are competent and see the bigger picture. They actually pay attention and understand why the numbers are what they are. They respect that the numbers are a very flawed tool and cannot be utilized without context or understanding. 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.
  • liquidpele 3y ago
    Ive even seen good managers hold a few incompetents on purpose in preparation of layoff cycles in larger companies that do them consistently.
• 38 3y ago
  > He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses. 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.
  • shigawire 3y ago
    You are thinking of something different than this is describing. Your situation is a waste of time where no one grows. The article is describing growing skills which is a net productivity benefit.
  • mynameisvlad 3y ago
    Quite simply, no. You're not going to learn from being handed an answer on a silver platter. You'll implement it, get on with your day, and not at all think about why the answer is what it is.
    • 38 3y ago
      > You'll implement it, get on with your day, and not at all think about why the answer is what it is. this is an incorrect assumption. some people (like me) have an analytical mind. if I am given an answer, I will usually reverse it back to the question, so that I understand how it came about. or I will ask follow up questions until I have that understanding. all this method is doing is forcing multiple people to go through the discovery process, when all that should be needed is for one person to do so. its a waste of business resources. person A can share with person B, then person B can go on to make their own discoveries. we dont need to force every employee to discover EVERYTHING on their own. thats just a huge waste of time. it would be like forcing everyone to discover Pythagorean theorem on their own, instead of giving them that tool and letting them use it to create other stuff.
• _gabe_ 3y ago
  Now when you Google “Tim Mackinnon programmer”, the 5th or 6th result for me is a link titled “The Worst Programmer” and the little descriptive blurb below that says “His name is Tim Mackinnon…”. I know the author was click baiting and flipping the story on its head, but I would be a bit annoyed if Googling my name + programmer surfaced something like that.
  • owenmarshall 3y ago
    Annoyed? I’d love it: it would be an incredible door opener anywhere you went.
    • softfalcon 3y ago
      Yeah, this is a great opener to break the ice with during an interview. You can even add some prestidigitation by having them take 30 seconds to Google it and your name comes up. Play it off as a joke and now everyone has a little smirk/chuckle over it. Now they know you have a good personality and can tell a funny joke about yourself. Goes a long way to putting you in that “I can work with this person” category. Also, if they can’t appreciate the joke, that’s an easy red flag for you that you probably don’t ever want to work for that team.
      • _gabe_ 3y ago
        You both make good points, on second thought it’s all about how you spin it :)
    • tchaffee 3y ago
      Get your resume. HR looks up your name. Throws out the resume. It could be fun if you can get an interview. It might hurt you though.
      • twic 3y ago
        This is just not something that actually happens.
• chasing 3y ago
  Alternate lesson: If your manager is telling you to complete tickets, don’t go months and months not doing that thing until you’re on the verge of being fired because — despite being a valuable member of the team — your manager is all confused. 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.
  • _boffin_ 3y ago
    Maybe Tim could have also added his name to the tickets as he was pairing and helping the others complete them...
    • chasing 3y ago
      Yup. This idea that a developer can work his or her genius in a dark corner is flawed. If you aren’t communicating what you’re working on, it’s hard to get credit or recognition. And it’s not an ego or bragging thing: It’s just fundamental team communication. For example, there may have been constraints that the manager knew about that sheer velocity was key for some reason. Or maybe the manager disagreed that Tim was adding enough value floating around all day. Who knows. But if Tim and his manager were in open communication, at a minimum there wouldn’t be confusion so great that a good engineer almost got shit-canned.
    • gardenhedge 3y ago
      Certain tools (Ahem MS) don't allow more than one person to be added to a ticket
      • _boffin_ 3y ago
        What tools are you talking about?
        • gardenhedge 3y ago
          Devops Boards
• brundolf 3y ago
  > You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates. 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
  • nine_zeros 3y ago
    > 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 The clickbait is made so that this document can be shared with a future shitty manager. If you send them a link titled "The Worst Manager" - I assure you their first reaction will be to figure out how to get rid of you. Managers are the bane of this industry and sadly, engineers have to spend an immense amount of time dancing around shit managers.
    • psunavy03 3y ago
      Bad managers who want to control instead of empower are the bane of this industry.
    • volkk 3y ago
      a manager that truly relies on story points as a direct metric of productivity wouldn't be reading blogs like this in the first place to make themselves better. the article is preaching to the choir of engineers and at a minimum half way decent managers nodding and upvoting. the ones that truly need to read this and embody it will never see it
  • thatwasunusual 3y ago
    > Pretty clickbaity title. Good. I hope it made you read the article and learn from it.
    • voxl 3y ago
      [flagged]
• hardwaregeek 3y ago
  It’s like Draymond Green. Individually his statistics suck. He’s jokingly called Mr Triple Single (a triple double is a major achievement, a triple single not so much). But he’s such a fantastic defensive coordinator and playmaker that his impact metrics on the team are massive. Like practically comparable to Steph, his more lauded teammate, in some stretches. 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.
  • KSS42 3y ago
    That impact should show up in the plus/minus score? https://www.espn.com/nba/statistics/rpm https://www.espn.com/nba/statistics/rpm For 2022/23 Green ranks 38. His defensive impact is very high but it is offset by his negative offensive impact.
    • hardwaregeek 3y ago
      Yeah that's what I meant by impact metrics. In the 2015-2017 playoff runs Green's impact is almost on-par with Curry. But for most people who watch basketball, they just look at the box score and don't look at advanced stats.
      • Given_47 3y ago
        Not even just playoffs either, I think his rank in that three year RAPM range was fourth or something staggering, after Curry, Lebron, and I think Kawhi? My go-to RAPM site that did all the calculations was taken down so can’t currently cite the numbers
    • Given_47 3y ago
      Standard plus minus is pretty crude since it obviously doesn’t filter out any context, and the ones that do[0] tend to be a better reflection of a player’s impact in their given role, not their overall quality, which is something that drives me up a wall with the nba analytics crowd. It’s easy to fall victim to the McNamara fallacy (I’ve certainly been guilty of it), before you start understanding the innumerable intricacies in the domain. And basketball is the only domain I probably know better than 99% of HNers lol. That being said, GP’s general point about Draymond is very true. Yes he’s one of the best defensive players of all time and one of the smartest as well. I think the main point is his incredible self awareness (yes get the jokes off). On defense it’s more subtle, such as not over committing and leaving his man etc but on offense is where it’s obvious. As his own shooting has fallen off a cliff, more and more when he’s dribbling unguarded he frantically looks around for Steph or klay to flow into a dribble hand off to pry them free for a shot. He’s talked extensively about the criticism he’s faced for lack of shot attempts, with his rational being why would he ever shoot if he can instead try to get Steph a shot. He’s also mentioned if Klay hasn’t touched the ball in a few possessions, he makes sure to get Klay the ball with at least a decent look; otherwise the next time Klay gets the ball he’s shooting it regardless of how bad the shot is. He also frequently pushes the break[1] to catch the defense off guard and before they can set up. He is still a negative offensively, but why I appreciate draymond so much is for the above reasons and the myriad other subtleties he does to maximize his benefit to the team and diminish the detrimental elements of his. And lastly, standard plus minus is still a hell of a lot better than box score garbage, I don’t mean to crap on it. [0]: https://squared2020.com/2017/09/18/deep-dive-on-regularized-adjusted-plus-minus-i-introductory-example/ https://squared2020.com/2017/09/18/deep-dive-on-regularized-... [1]: http://stats.inpredictable.com/nba/onoff.php?season=2022&team=ALL&pos=ALL&po=0&frdt=2022-10-18&todt=2023-06-12&rate=tot&grp=1&mpos=2000&sort=son_opce&order=ASC http://stats.inpredictable.com/nba/onoff.php?season=2022&tea... (Steph actually ranked higher than Dray last year in pace (seconds per possession) on/off which is why separating Draymond himself is so difficult. Their relationship is certainly symbiotic, but Draymond is the one that optimizes for best interplay of their skills)
• hermannj314 3y ago
  It is also possible if they fired this guy, and replaced him with another developer that only did points that the organization would be more productive. 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.
  • nottorp 3y ago
    Your last paragraph just said that if you hire people and tell them their earnings depend on $METRIC they will optimize said metric. The argument here is which metric, or are metrics good for anything? [1] [1] Except ditch digging and children. It is well known that 9 people will dig a ditch in 1/9 the time one person will, and 9 women will make a baby in 1 month instead of 9.
  • AugustoCAS 3y ago
    The answer to your scenario is `yes` with a high probability (taken from my magician's hat), but only in the short term. People like the one described in the article prepare a pipeline of good engineers, who also have experience in the domain and in the organization. So if one cares about fast delivery, get a good number of sr engineers who work on their own thing, share little and are not encumbered by each other. If a company needs to deliver urgently this works, but is an (expensive, short term) option.
• Octokiddie 3y ago
  What's the metric for programmers who prevent the team from building the wrong product?
• gumby 3y ago
  One really good developer I worked with wrote excellent code and also terrible code that had to be replaced immediately — and both made him great to work with. 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)
  • johnnyanmac 3y ago
    >I was actually much more impressed by the latter skill — among other reasons it’s simply rare Not exactly something to encourage, but it sounds like he has experience in competitive competitions, where generating code to a problem on the fly is necessary. It's not something you can't learn yourself, but rote memorization of common problems and solutions (to the point where you can mechanically type down some algorithm from memory) is the bane of my existence
    • lolinder 3y ago
      Don't competitions usually have completely different kinds of problems than what you typically run into in production fires? When I think of competitive programming I think of algorithms and puzzles, not network errors and data corruption. In my experience production fires are rarely put out by rote algorithmic knowledge, the skill is more having a detailed knowledge of the inner workings of every layer of the system so that you can come to the right conclusion based on the very limited information available in the average production monitoring system.
      • zerbinxx 3y ago
        This is my understanding as well. Rare is the day I’ve solved a production firefight by editing some algorithm - it’s almost always arcane configuration, restarting services in the right order, some network thing flapping/dos-ing the rest of the system, some service aggressively restarting and dos-ing others, actual malevolent dos, noisy neighbors, resource starvation, etc.
• vikramkr 3y ago
  So basically he just had the wrong title? Sounds like a great engineering manager or lead (in a company where that involves less code writing) or something. But his title is an IC role. But if he's spending all day pairing and not writing code then yeah - that manager seems to be correct, that's not his job? Why isn't he taking on any stories?
  • orpheansodality 3y ago
    pairing is taking stories, it’s two people working on one task together.
    • vikramkr 3y ago
      So then he hasn't been taking zero, "literally zero" stories like the article says.
      • sodapopcan 3y ago
        The article said zero stories according to Jira. This is, of course, rectifiable in Jira by allowing a ticket to have multiple people assigned to it. ...unless they aren't using Jira and some tool that doesn't allow this.
• wonderwonder 3y ago
  I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers. 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.
  • fnimick 3y ago
    > 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. So in the short term, the company benefited, yeah? They got more work out of the same people than they would have if they didn't apply the pressure. Reminds me of an old boss I had who would flat-out say that to get a project done we would "hire someone and burn them out" - he planned to only get six months of useful work out of someone, and if they were stupid enough to stick around for high stress and low pay, that's just a benefit to the company. (I didn't last very long there either)
    • acdha 3y ago
      The question is whether you get more volume but lower quality: a team doing 60 hour weeks on a regular basis tends to be a team baking in lots of technical debt and skipping “slow” things like “do we really understand what our users really need?” or “did we correctly architect this?” Everywhere I’ve seen this there’s been a lot more rework and things like high infrastructure bills because people have [correctly] learned that the business doesn’t care about quality.
    • johnnyanmac 3y ago
      Sure, if they were going to do layoffs in 6 months anyway, I guess this anti-pattern was coporate's wet dream. them quitting means they don't even have to bother with severance packages. But it sure is a shame we're past the days where you actually want to retain and nurture tribal knowledge. imagine if other engineering disciplines simply hopped companies every 2 years, or if they cut half their civil engineers for a better earnings call (thankfully, he government doesn't have "shareholders". just taxpayers to disappoint).
• johndhi 3y ago
  Nice story. It's unfortunately really hard for higher management to see something like this. I guess it's on the middle manager to convince upper management of this. Unfortunately in my current experience my manager is not at all like Tim.
• Aperocky 3y ago
  Smells fishy. 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.
  • siva7 3y ago
    You do realize that pairing is also delivering in everything you mentioned? Just because you hadn't the luck to experience this in your career so far doesn't invalidate this
    • asveikau 3y ago
      More cynically, perhaps they have experienced this but labelled the person as a non-performer.
    • Aperocky 3y ago
      Oh I had plenty of luck in my career, there are people who the entire team goes to when new/unknown/specific problems show up, and I happen to be one of them. But I don't sit over someone's shoulder at all times. I only try to help when I'm needed, otherwise I'm knee deep in my own deliverables.
  • pizzafeelsright 3y ago
    Hi. I barely deliver anything of value from my perspective. I asked to swap teams. Two levels up both said "no way you can't be replaced. " I have a reputation and didn't know.
  • oytis 3y ago
    In orthodox agile environment planning, design and architecture might not result in any "story points". Also these activities might not always result in a lot or any artifacts. E.g. being in a meeting, making sense of messy stream of requirements and using institutional knowledge to help set the right priorities on a project or prevent team from spending months on a dead end idea might not leave any paper trail at all.
• xena 3y ago
  I'm this kind of person most of the time and it really sucks come review time. I'm also a mentor type and that is also very hard to account for in most systems. It means I do an essential role that is seldom rewarded because there's no number associated with my meddling.
• nathias 3y ago
  If I worked somewhere where a guy would shadow me, hover around and 'support' me that would make me quit very fast.
• smallerfish 3y ago
  DORA seems ok as a big company framework, where different teams of similar sizes can be roughly compared using the scores, and the CIO or CFO can have some satisfaction about being able to avoid spending money on non-producers, without engineers feeling like they're being individually spied upon. Without this accountability, engineering managers may let non-performers coast for a variety of reasons. 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.
• Philip-J-Fry 3y ago
  I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good reason. 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.
  • segfaltnh 3y ago
    Frankly it sounds like you need to make this happen. I don't know your company culture but at places I've worked Staff+ engineers aren't meant to wait around for permission to be catalysts and mentor other engineers.
    • Philip-J-Fry 3y ago
      I'm usually the catalyst for change, but that's usually around tech and process. It's more effort for me to try and change my managers mind on what our development culture should be. The company I work for has a reputation for being a bit of a grinder and I've managed to help reduce that reputation in my team gradually at least. But at the moment I have work to do and deadlines to meet, so it's a hard sell to suggest stepping back from active development and focusing more on incubating our less experienced devs. Even though it's better in the long term, and my manager would even agree on that, important short term projects just take priority.
• psychphysic 3y ago
  [flagged]
  • yjftsjthsd-h 3y ago
    Yes, that is what was written. Would you like to say something about it?
    • psychphysic 3y ago
      [flagged]
      • Philip-J-Fry 3y ago
        I'm rarely paired because pair programming just isn't something we do in the company outside of just helping people with their little issues. It's not an encouraged practice. There's nothing deep about it. It sounds like you're trying to insinuate something negative about me.
        • sodapopcan 3y ago
          I assume they are insinuating that you are coming off as arrogant and only interested in teaching. They should definitely just say so, though. In a good pairing environment everyone is learning from everyone. You didn't explicitly say you were looking to learn for others though you also didn't explicitly say you weren't. As far as I'm concerned, in the best pairing environments everyone is always pairing with everyone else, not just seniors with juniors. There is the idea that seniors can actually learn from juniors too since juniors will question things seniors haven't thought about in a long time and are living with "I do it like this because it's the way I've always done it" syndrome. PS, love the username :)
          • Philip-J-Fry 3y ago
            >In a good pairing environment everyone is learning from everyone. You didn't explicitly say you were looking to learn for others though you also didn't explicitly say you weren't. Well that's the thing. The only reason I'm in a senior position at this company is because I never stopped asking questions and I still don't stop asking questions and learning from people more knowledgeable than me. I used to spend hours sitting at one guys desk just asking questions and listening to rants and just gathering knowledge. I learned that this was the fastest way to progress and get better at the job, but I'm not finding that juniors and other less experienced devs are doing the same thing because they're worried about wasting people's time. And people are less likely to encourage this behaviour because they have high priority work. I got away with it when I joined the company because the rate of change was so much lower and so things generally just took longer.
• mberning 3y ago
  I find it amusing and very telling that the organizations with the most burdensome and unnecessary overhead are always the first to take an interest in developer productivity. A metric which their own structural inefficiencies are in direct opposition to.
• just_dan 3y ago
  Tim was the worst programmer. I'd be so bold as to say he wasn't a programmer at all. He was a mentor and a leader and should have been promoted rather than sacked to replace whatever taskmaster your team had at the time.
• deleted 3y ago
  [deleted]
• mattlondon 3y ago
  Personally I want the seniors on my team actually delivering on the really hard stuff. 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.
  • spyhi 3y ago
    A senior engineer can work through a hard problem assigned to a junior engineer, resulting in a well-implemented hard feature and a less junior engineer. Just because a junior engineer is working on it doesn’t mean by default it’s an easy problem—how are you going to grow your engineers otherwise?
    • wizerdrobe 3y ago
      Some firms simply hire nothing but Seniors. You trained up a Junior-Mid-Senior? Cool, well offer him 20k more and call it a day.
      • jen20 3y ago
        > Some firms simply hire nothing but Seniors The firms that claim to do that almost invariably do not hire people with 20 years of experience, they hire people with 2 years of experience 10 times over. Sometimes that's fine. Usually it's not.
        • zerbinxx 3y ago
          Agreed, I will almost always take someone with 5 years of experience at a couple of good shops rather than 20 years of experience broken up across 10 different ones.
• jader201 3y ago
  The moral of this article seems to just point out what we all already know, and what has already been discussed on HN countless times: don't measure performance solely by things that should never be measured in a vacuum (like story points, lines of code, etc.). 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.
  • tomtheelder 3y ago
    I actually don’t think that’s what the author is arguing. They are arguing that certain metrics that are valuable to measure at a team level become less useful or even misleading if you zoom in too far to an individual level. Story points being a good example. Useful when talking about a team, not useful when talking about individuals. That’s a more nuanced point, and one that I definitely don’t think is obvious to everyone.
  • johnnyanmac 3y ago
    >E.g. would it be at the top if the title was "Don't measure performance by story points"? TBH it's a non-zero chance here on HN. "Don't measure by story points" is still preaching to the choir to a community like this after all. >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. 1. Lucky 10k. Especially if it involves some managers who may in fact be doing this stuff as we speak 2. Generally, I come to the comments because some anecdotes are more interesting than the article.
    • the_af 3y ago
      Agreed, but also: enough people are disagreeing with the moral of the story that I think we can no longer assume anything in the article is preaching to the choir.
• nittanymount 3y ago
  clearly, Tim is a coach/mentor in this team, try to measure his work a wrong way ?
• watters 3y ago
  The title is a fairly harmless form of click-bait. 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.
• shultays 3y ago
  Tim’s productivity score was zero I also have a Tim in my team but he is a net negative. 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
  • andrewmcwatters 3y ago
    Bad management
  • xena 3y ago
    That person manages to stay because he plays political games correctly.
  • jokethrowaway 3y ago
    In Europe firing people is not always straightforward. There are so many people doing jackshit which make me go insane. I guess, good for them and I'm glad I'm not a shareholder. Management handle the most blatant cases in 6 months. There are so many people who are not completely clueless at pretending to do something and they go undetected for their entire career. From previous experiences, in a US startup they would be fired in 2 weeks.
    • jonhohle 3y ago
      What value to society does making companies carry dead weight provide? It raises the company’s costs, lowers productivity and morale, all to protect someone unfit for a particular role? The unpredictable layoffs and terminations of US companies are their own issue, but companies pay unemployment insurance to let people go with some safety net. I can’t imagine UI is more expensive than keeping an underperforming employee.
• charcircuit 3y ago
  Having this person help others 100% of the time likely is not the best use of his time.
• gloryless 3y ago
  I have been this person and I'm trying to move away from it. It really is a great skill to enjoy lifting others and to be the glue of a team. But there are multiple slippery slopes inherent to that role that make it difficult. You can begin to confound the knowledge of others as your own, and almost certainly your own IC skills will atrophy if not purposefully maintained. I think it also requires the explicit buy in of the team, or at least other seniors who understand the benefits and can help keep balance. 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.
• mgaunard 3y ago
  The worst programmer I knew never had any productivity problem; if anything he produced too much code, outpacing the others' ability to maintain certain levels of quality. He ended up promoted; in many organizations, people that hack the code rather than properly design and build sustainable solutions are highly valued.
  • astrange 3y ago
    Was he promoted to a job where he did more of that, or a job where they could make him stop writing code and do something else?
    • mgaunard 3y ago
      I ended up leaving, as did most of the other senior developers, so I wouldn't know the details.
  • alaxapta7 3y ago
    Yeah, that must have been my collegue. Usually he was in charge of implementing all the new stuff, because he was able to deliver fast. And then I had to refactor, or usually just rewrite and redesign the whole thing, because it was immediatelly unmaintenable. I didn't mind, since at the end of the day, he was really good and doing these prototypes and selling them to management. I was good at making the application last and stable, so it kinda worked out.
• MarioPython 3y ago
  I feel that the article is talking about the same thing as what is described in this talk https://www.youtube.com/watch?v=YyXRYgjQXX0 https://www.youtube.com/watch?v=YyXRYgjQXX0 - "disagreeable givers", which the host of the talk argues are one of the most valueable employees to have in a company while also being the least understood and often let go. 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 https://news.ycombinator.com/item?id=17386640
• idontunder 3y ago
  [flagged]
• ChuckMcM 3y ago
  When I've been asked to coach someone on "technical leadership" I always ask them to be on the lookout for "facilitator" employees, those whose help makes another employee more productive or effective. I am convinced there are "service oriented" personalities where people get more job satisfaction out of helping someone else do a great job than getting all of the credit for doing something amazing. As the author points out they often "score poorly" and yet losing them will create net decrease in team productivity. I always try to give folks the tools to help distinguish between people who aren't productive because they aren't, and people whose productivity is exhibited in the success of others. 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.
  • 88913527 3y ago
    Have you ever seen an organization filled with service-oriented employees and no doers? Zero-interest rate policy has lead to having more Senior Director of Jira Board Management and Lists of Tasks type roles and not enough people that can do the work. I'm not opposed to the idea that others can be a catalyst for the productivity of others, but you need the others for anything to get done, otherwise it's necrosis.
    • ChuckMcM 3y ago
      > Have you ever seen an organization filled with service-oriented employees and no doers? Yes, but to be fair it was an IT organization which had settled on a metric of "tickets processed" for their quality metric. As a result people who processed a bunch of tickets but never addressed root causes were seen as "good" vs people who wanted to fix fundamental problems that would reduce the number of tickets. It was, for me, a pretty classic case of picking the wrong metric. And to be fair the "best" IT/Service org is one that looks like it has nothing to do because it is always ahead of the curve of upcoming issues, and upper management has a hard time with that.
• ChrisMarshallNY 3y ago
  > Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team. 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.
  • tnel77 3y ago
    In my experience, the best raises are from getting a new job. What were raises like for your engineers that stuck around for 10-20 years?
    • ChrisMarshallNY 3y ago
      Not very good. These were highly skilled engineers that could easily have commanded better salaries, elsewhere. That meant they stayed for other reasons. I wonder what those reasons could be?
      • arrjayh 3y ago
        This is brilliant. I'm a mid-level engineer with decent C/C++/Rust background. Have yet to find a team like this. I'm inspired by your story to keep searching!
      • notyourwork 3y ago
        Will be five years with my current manager. Team has shifted some but money is not the only reason to stay somewhere.
• erickf1 3y ago
  All I had to do was read the title of this article and the first sentence to understand that this is an example of what's wrong with the software development industry. I would rather work with people that act like good people and are human, than to work for the idiots measuring your every breath looking for a reason to fire you.
• icambron 3y ago
  The horrifying part of this is > 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?
  • wetpaws 3y ago
    Fortune100 eng here, yes it is a thing.
• _mc 3y ago
  A very relatable story. Of course, we all feel sorry for those other Tims out there who were not lucky enough to have such a good manager. Partly, because we see the Tim in ourselves. 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.
• AtNightWeCode 3y ago
  Metrics. I used to work on a team with skills in agile development. The process was evaluated at every retro and everything was tweaked. One member of the team however continued to put tasks into states that was not even in our agile board. Meaning. You could not drag a task into that state. You had to set it. Turned out that the idiot CTO used an unknown report to evaluate staff. One metric was putting a task into a specific state no longer used by our team. The idiot CTO had told his favorite pet dev about this metric. 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.
• protonbob 3y ago
  It seems like the easy solution here would be to give this guy partial credit for stories completed.
• refulgentis 3y ago
  I don't buy it and they sound like a very annoying coworker. If he's 100% devoted to pair-programming and makes such a massive difference, promote him to a lead. Programming is the only profession that acts like it's literally impossible to ever measure productivity at all without committing some obvious wrong. Drives me nuts, coming from a blue collar background. It's cargo cult thinking used to justify many negative outcomes.
• hibikir 3y ago
  This is also why the most hilarious anti-feature of Jira, supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. If you do sufficient pairing, the person assigned to a ticket is completely useless. Also why performance measurement from the outside of a team is always going to be dubious. 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.
  • voytec 3y ago
    > supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. It's whoever owns the issue. You can make it an epic and assign particular sub-tasks to team members if it's a teamwork.
    • desbo 3y ago
      And if there’s pairing on a sub-task…?
    • ChrisLTD 3y ago
      Not sure how that solves the pair programming issue. What you’d need is a way to split the points for a single task among 2+ people without the overhead of duplicating the ticket.
      • fragmede 3y ago
        It's, what, two clicks to duplicate a ticket, and another to assign one to other person? Sure a "this person paired" button would be easier, but sometimes you just gotta do jira chores.
        • ChrisLTD 3y ago
          Then the status has to be tracked in two places. It’s certainly not impossible, but as a programmer I’m allergic to unnecessary busywork.
• Stratoscope 3y ago
  Some 20 years ago, I worked at a moderately large software company that sold a desktop application for Mac and Windows. The team had mostly Mac experience and they were just getting their feet wet with Windows. So naturally the Windows version had some problems. 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!
  • kvirani 3y ago
    I hope that feedback didn't discourage you from continuing with your approach to software development and teamwork.
    • shortrounddev2 3y ago
      I am the same way with my coworkers. I spend a lot of time helping juniors with their code and doing code review. My boss talked to me and told me to stop helping out so much and focus on my own tickets.
      • elliotec 3y ago
        It’s a balance. Sometimes it is worth spending a ton of time leveling up your team (teaching them to fish), and sometimes it’s much more helpful to have you do the work yourself (we ran out of food and you’re our best fisherman).
        • deprecative 3y ago
• mlhpdx 3y ago
  Wonderful. In rowing there is a practice called “seat racing” where different combinations of people are rotated in and out of the eight positions to determine the combination that is the fastest. Individual strength is an indicator but it’s the team speed that determines who is in the boat for races. The inevitable result is that the fastest combination rarely includes the eight strongest rowers. There is very often one or two “magical” people who don’t look better “on paper” but make almost any boat faster when added to the mix. They have subtle ways of improving the set, rhythm and power of others. Not all coaches take this happily and resist it, with the obvious result of fewer wins. This is very, very analogous to software teams. It’s the mix and results that matter most.
• prerok 3y ago
  The only 10x coder I knew was the one that managed to deliver stuff (almost) on time but also took the time to explain things to other (junior, me at the time) programmers. Such Tims are sadly rare and I think I should start working towards becoming like one.
• sjtgraham 3y ago
  This is not an argument on the merits of story points or metrics but Tim could have just put his name on the stories alongside the folks he helped. Problem solved.
• ryeguy_24 3y ago
  If you don’t own your company, you are always measured on optics. If the person who employs you does not optically see your value, you don’t stand a chance working there. If employment is the measurement, optics will always be important. For those who disagree, I would argue they are arguing on what would be ideal. Sure, it would be ideal to have a fully meritocratic performance system but if someone else is in charge of your employment or performance evaluation, your success is 100% based on their opinion of you. How do they get that opinion? It’s the optics whether valuable for the company or not. 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.
  • randomdata 3y ago
    Even when you do own the company, you are still measured on optics by your customers.
    • ryeguy_24 3y ago
      Really good point. Shouldn’t have included that conditional statement.
• redbell 3y ago
  Evaluating someone’s performance, especially, software engineers by non-tech people might produce dramatic results. 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.
  • paulcole 3y ago
    Was Tommy upset?
    • redbell 3y ago
      Absolutely! But after a while he knew why there was no kind of reward whether in the form of a financial compensation, a promotion or even additional days of vacation. Simply because the law of work does not have a section for exceptional performance/achievement.
      • paulcole 3y ago
        must’ve been Tommy’s first rodeo lol
        • cellularmitosis 3y ago
          And how would an experienced cowboy handle this situation?
• bullen 3y ago
  "ideally as tangible business impact expressed in dollars saved, generated, or protected" 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!
• ironman1478 3y ago
  It's interesting reading this because this has been my role for a few years. I've also had similar problems with management wanting to pip me and things like that. Luckily, my company does peer review in addition to top down review and that has shown that I provide value even if it's not always coding. 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.
• tastysandwich 3y ago
  When I joined my company, I was introduced to this dev who'd been there since the start. 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.
  • m3kw9 3y ago
    Had this same issue, new young devs adding the latest programming tricks and saying yes to every fking thing as if a no will get hurt their “I can do anything” mentality. Others were not pushing back as it may make them look stupid or something, they treat the project like a social event. A lot of these little things came back to bite hard
• slowhadoken 3y ago
  The business mindset wants employees to be contestants in a reality tv show. The process of creating things doesn't look like a commercial though. Progress doesn't care how you feel, it's a functional process that produces a clear perspective. Greed always obscures that vision.
• igama 3y ago
  "Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team." - This happened years ago to me, with a manager pulling me aside and asking why my Tickets resolved were so low... They only cared about the number of tickets worked on...
• ajmurmann 3y ago
  We all know Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure". Quantitive measure done't work well and especially not for something as complex as software development. They might tell you were to look more closely at best. Qualitative assessments work much better, but those require trust. As soon as going gets tough for a company or department, trust weakens, doubt increases and higher management, especially if they don't understand software dev well, will require quantitive metrics. It's bad, but we'll never get rid of the mess because of organizational dynamics.
• earljwagner 3y ago
  As half of the pair programming team, why not just give him half of the story points?
  • GuB-42 3y ago
    Maybe the tool doesn't support that. Or maybe Tim didn't care about story points, he knew his worth, and he felt that if the company wanted to fire him on such an arbitrary metric, it wasn't a company worth working for anyways. In the end, he did well because he kept his job and the company dropped an inappropriate metric.
• gerdesj 3y ago
  "This was cascaded through the organisation, and landed in our team in terms of story points delivered." Bingo. If I ever hear anyone in my company attempt to deliver a sentence like that then I will go postal.
• deleted 3y ago
  [deleted]
• obiefernandez 3y ago
  I was a colleague of these guys at Thoughtworks and my favorite most relatable tidbit was telling client managers “no”. 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.
• andy_ppp 3y ago
  I worked with a copywriter who did similar stuff and made the team tick. It was great to watch him effortlessly get everyone doing the right thing for the project and it worked both ways, he'd communicate effectively with the dev why we needed to hack things and with the business about getting us extra time for certain things. It lead to a better project with a manageable amount of technical debt. He was let go and the project became a lot less successful and enjoyable, once he was gone a large group left soon afterwards...
• csours 3y ago
  I've asked this question a number of times now: What is the unit of work for software development? 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?
  • worik 3y ago
    > What is the unit of work for software development? Dollars. Duh!
• deleted 3y ago
  [deleted]
• thelastgallon 3y ago
  I've never seen these kind of people (Tim). Almost always, it is someone who knows absolutely nothing, meanders from desk to desk, wasting productive people's time, picking their brains. They are usually never given any work, because someone else has to undo the damage and do the work! 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.
  • lmm 3y ago
    Yep. Even in the unlikely event that he's really that good, he's doing only the fun part of the job and shirking the other 90% where you turn your brilliant code into something that actually does something useful for an end user. A better manager would take action.
• paint 3y ago
  >Measure productivity by all means—I’m all for accountability—ideally as tangible business impact expressed in dollars saved, generated, or protected. That's a disgusting way to think about productivity, the result of otherwise smart people growing up in a capitalist exploitative system.
• deleted 3y ago
  [deleted]
• keeran 3y ago
  I had my highest appraisals and biggest bonuses when I didn't do the job I was hired to do. 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.
• SamuelAdams 3y ago
  There’s a very good blog that explains Tim: Being glue. I highly recommend all leadership read it. https://noidea.dog/glue https://noidea.dog/glue
• system2 3y ago
  These are the moments employees decide to quit. Managers are clueless and just creating evaluation metrics to impress upper management/ceo/owner. Upper management also is clueless and believe the manager. Eventually the IT company, the consultant, or the employee starts arguing with the company and they are replaced swiftly by the management. This costs a lot to the company but who gives a crap. They deserve it. Before this happens just drop the client or your employer and find a better life.
• ShamelessC 3y ago
  Ugh of course the worst programmer you know is actually the best one. While I agree with it, there is nothing new in this article and the obviousness of the bait and switch is depressing.
• justinlloyd 3y ago
  For Tim MacKinnon's sake I sure hope you got Tim's permission to post this, and that Tim is near retirement age and not needing to interview for any team in the future because unfortunately, searching for "Tim McKinnon programmer" tells me he is the worst programmer in existence. If I were hiring and found that as the first link on Google, and feeling particularly lazy that day, Tim's C.V. would be round filed. HR would reject him before I ever got to see his C.V. Poor Tim.
• quickthrower2 3y ago
  The problem with the story is there is a reasonable solution for the bean counters: you log time against tickets you work on or help with. Then maybe prorata the points to the hours. 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.
• 0x6461188A 3y ago
  There is something about metrics that messes the thing being measured. 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.
• sixstringtheory 3y ago
  Whenever I’m forced to do a periodic performance/peer review, I just think about how I’m doing my manager’s job for them. 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.
• lxe 3y ago
  I know a dozen programmers like this. It's true that it's not easy to get fired if you're a constant benefit to the team's productivity, but it's very hard to get promoted under most organizations' promo guidelines, which usually involve design documents and end-to-end projects.
• agumonkey 3y ago
  How timely, I hit similar issues, I often end up removing blockers from my team when pairing, which doesn't end up visible in Jira and now HR is bothering me.
• artichokeheart 3y ago
  > A few years ago I wrote a Twitter/X thread about the best programmer I know, which I should write up as a blog post 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
• Joel_Mckay 3y ago
  "measuring developer productivity is that you can quickly identify the bad programmers" 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, =)
• bighoki2885000 3y ago
  [dead]
• kissgyorgy 3y ago
  When I got promoted to a Senior Dev, my job became totally different. All I did the whole day was talking to other teams, pair program, organize big project nobody wanted to do, take part in plannings, but hardly any coding. These responsibilities were actually included in the job description.
• deleted 3y ago
  [deleted]
• softwaredoug 3y ago
  If you're Tim here, here's a career protip 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.
• relix 3y ago
  As a manager in technology I'm starting to really detest stories like this, because they are often bandied around by IC's with a very narrow view or opinion of why it's bad to do new change X or Y "because here is a story", which on the surface may be similar to what happened here but is in fact a good idea. In reality things are always so much more nuanced, or require much more context to judge, than what people naively think. 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.
  • Gerardo1 3y ago
    This seems a lot like trying to invent a problem to justify your metrics rather than acknowledging that your metrics don't align with the actual performance of the team. There's no indication in the article that the team was struggling or under-performing, and there's no reason to promote someone out of a position they're thriving in just because the way they deliver value doesn't neatly align with how you're measuring value, especially if you can plainly see the value. Here's what I've seen in the past: exactly the scenario you described, the "Tim" is promoted to team lead or architect or something similar, and now their calendar is booked up and they no longer have time to do the thing that brings value (and that they enjoy). No one on the team is happy, everyone is stressed, and in a year or so you'll start bleeding members. Tim either hangs around and is a mediocre whatever position he is, or he leaves to be a whatever position somewhere else where he can start with a new context and without loaded expectations.
• FlacoJones 3y ago
  Being a 10x engineer can come from either: - 10x productivity yourself - Adding 2x to five 1x engineers Non-technical management will never appreciate the engineering multipliers like Tim
• LucyAltaha17 3y ago
  [dead]
• svilen_dobrev 3y ago
  i have been looking for such a thing for long time.. always had to do that AND also coding and architecting and generaly moving the whatever project. Except just once for 4 months (from ~15 years). 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?
• Norabram 3y ago
  [dead]
• vietvu 3y ago
  By no mean I am the best dev I know, but I consider myself the best one with finding answer that I have met in person. e.g: fixing bugs, reading docs, even for things I have no exp about. 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.
• randyshirley23 3y ago
  [flagged]
• Marcoperezco 3y ago
  [dead]