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!
I know it's too late now, but you are the type of developer that makes our profession an actual craft. Sharing knowledge is the biggest benefit to provide other developers, and too few that decide to go that route are rewarded for it. If it weren't for developers like you, we wouldn't be anywhere close to where we currently are in the software world. I try to give back knowledge as much as possible, because it's not just about the one business you work for, it's also about building up somebody. Know that you're appreciated, even if you aren't getting direct thanks for it!
Wow, thank you. I am grateful that my comment attracted so much thoughtful discussion. But your comment is the one that really touched my heart.
I was reading it to a close friend just now, and I have to confess that I choked up a couple of times reading it.
So again, thank you, my friend.
p.s. You don't happen to be anywhere near the SF Bay Area? If you are (or even if you're not), please drop me a note at the email address in my HN profile.
Anyone else who is in the mid-Peninsula area, feel free to do the same. It would be nice to meet up with people who have an interest in this topic.
I did an internship during uni as an electronics technician repairing handheld, vehicle mount rugged terminals, and base stations (rf network controllers before 802.11 arrived).
Each repair job had the same priority but some were much simpler than others - one month I thought I’d take the base station jobs to learn and because no one else was repairing them. They took longer to fix but obviously were more crucial to operations.
At the end of the month PHB held a team meeting where pie charts of utilisation were shown and I had performed terribly against the rest of the (senior and experienced) team. That was the moment I learned that the senior staff were picking off quick and easy jobs for a reason, and that office politics was a thing.
PHB couldn’t understand my reasoning of selecting those jobs and the outcome was his dislike of my performance… glad I learned about poor bosses that early in my career.
I had a similar experience to yours. Back when I was the equivalent to what is now staff engineer, my team got a new boss. On paper, I didn't look amazing, but I was constantly helping people.
My new boss admitted at our first review that he had written up a performance plan, but threw it out not long before. What happened was we just transitioned to an open office, and he got to see the line of people who would come to me for help, and how I wouldn't turn anyone away.
I was a little salty about losing my cubicle, but that experience definitely made me appreciate being in an open office.
Of course, I haven't worked in an office of any kind for years and will never take a job that isnt WFH again, so take that last bit with a grain of salt ;)
It’s important to find/figure out what a company values and optimise for that. Once a reputation has been established, it’s then possible to go about changing things, but not before.
I’ve seen too many stories of people optimising for the “team”, but losing their job or being looked over for promotion due to negative perception from those higher up.
The opposite is also true, sometimes unfortunately. Once a good reputation has been established (whatever is currently valued in the company), any amount of misbehaviour will be tolerated for a long time.
It shouldn’t be this way, but that’s been my experience.
> It’s important to find/figure out what a company values and optimise for that.
One important ingredient for this is to know many companies will actively lie about their values. Typical case is, everyone tells you they value quality and feedback, while in reality everything is rushed and actual suggestions are at best thrown away in the "later" bin.
> Once a reputation has been established, it’s then possible to go about changing things, but not before.
I've noticed 2 patterns in my various gigs in the past: The virtuous cycle where I'm trusted to build something with significant autonomy from the start, I end up being happy, motivated, productive; and the vicious cycle when I'm just a new untrusted cog in their machine, my motivation & productivity plummet.
As far as I can tell I have no control over the initial condition, and the only way I could break the cycle was to start fresh in a new assignment. Some would suggest I suck it up and work my way up, but to be honest I no longer have the energy to pay my dues over and over again.
What happened after the mediocre performance review? Did leave for greener pastures asap? Did you start to optimize for their performance metrics, and stop being generous with your time? Or could you manage to convince somebody high enough above you in the org-chart that they actually hired you for what you thought they did?
Thanks for asking. It all worked out OK. I had a good relationship with my manager, and he actually seemed a bit embarrassed that he had to put those remarks in the review.
I also had a very good relationship with both the VP of engineering and the senior VP who oversaw the entire product and who I'd worked with before on other projects.
I did leave eventually, but it was for unrelated reasons.
What an odd practice. Not sure who conducted the review, but managers especially should be familiar with the concept of coaching, and recognize that you were doing a great deal of it. I am a technical manager myself and spend a lot of time on coaching team members too.
20 years ago when I started there wasn’t anything I experienced that could be called coaching, mentoring, or leveling up. Sure, I could get some time from a more experienced developer to get another set of eyes on a particularly hard problem if I wasn’t able to come up with a solution but for the most part I was just expected to work with minimal explanation or direction. Very little in the way of code reviews as well. I certainly hope this has changed and to whatever extent I’ve been able to I’ve always tried to make myself available to others because sink or swim really sucks.
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.
I’m impressed by Michael’s LinkedIn profile and extensive experience. If you ever take up blogging, I imagine you’d have a lot of lessons and experience to share.
I suppose this comment will not be liked very much, but let me offer one another perspective on this. In one team in our organization, someone was hired who offered themselves (by their own initiative) as a developer coach with the intent on pairing, reviewing and in general helping other devs. They were very confident, and as we employ team recruiting, the team decided it's worth a shot, as the candidate displayed knowledge of relevant skills and - as already mentioned - was very confident to educate his peers. It was an intra-organization lateral move, so not much risk involved. Everyone was on board with that decision, and the expectations were clear: they would not be expected to produce code and/or design documents and so on, they should just support the other devs. It should be mentioned that the team they wanted to join was a really high performing team - still (or because of this?) they were open to the idea of having a well-trained, experienced pairing partner and so on.
Well after a few weeks it turned out not so positive. They had quite a broad knowledge of things, but not in depth. They didn't think far enough (like for example, giving the tip to "use a FIFO SQS queue" despite not really understanding the fine-print, but still they persisted and it ended up in a prod rollback), they preferred educating about code style, didn't really listen to feedback (not in the sense of ignoring it, they didn't even realize that they weren't so senior compared to the rest of the team at all) and in general slowed everyone down without bringing much benefit to the table.
In the end they didn't get fired or something like this. They did another lateral move as the team explained why the team doesn't want to continue this. After their next team change, they talked about that this specific team didn't want to accept their help and that they had received bad feedback since they didn't produce code.
Obviously this is just an anecdotal counterexample, but still this can happen as well.
I was hired at a company to help scale their development because their app was growing fast but they needed a leap forward in architecture and approach or they couldn’t keep up with growth.
I documented everything I did from day 1, from what I was doing as well as why.
When it came review time, everything ended up reflecting really well, for I may have closed less tickets than my peers, my peers where closing more tickets than ever, and there was a direct line from my work with them to that productivity increase.
Once upper management wrapped their heads around this they completely understood why I was effective at helping shift features: the A -> B wasn’t possible without me spending lots of time with others and helping with their projects, and we would have needed more headcount to achieve what we did by having me work with the org the way I was vs trying to juggle feature work with it
It’s all about the metrics at the end of the day, in some ways. If you can demonstrate your impact across the board it’s hard to dismiss
I quit a job way long ago for very similar reasons. I cared about raising the level of the people around me. I wanted the junior folks to get credit and advance in their career. This meant my work was not readily visible.
A director said to me: "I can't remember the last thing you worked on." In that moment I knew it was time to leave. I was gone a few weeks later.
Just last February I was let go from the best gig of my career, under similar circumstances. I knew that I was not hired specifically to help other devs, but it appeared to be appreciated and encouraged. Well, I guess not.
I have made this mistake more the once as I actually like working with people and helping them level up. Something I do now is make sure that if I am being hired as a developer of some sort, the metrics of success outlined clearly in my offer letter also include giving mentorship. It’s measurability usually revolves around peer reviews and how much others value my help. I have been accused of gaming my performance metrics because I would literally be helping people until they are able to tackle the problem independently. Which, I don’t know, sounds like a job well done to me.
Then you have to wonder why they're there in the first place. Managers that do not manage and do not know what the people they are supposed to be managing are up to can be missed.
I think that is why it's important for development managers (team leads, tech leads and whatever else you would like to call them) to be either actively doing hands-on work or having been reasonably good developers in the past. Then they can appreciate this kind of work better.
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.
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.'
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.
Harry Nyquist isn't exactly an unknown engineer who doesn't have his own achievements, though - not sure why people are saying he would be fired in a modern company!
That kind of people was somehow mentioned in Peopleware. A group of people is a subtle structure, and good team spirit, good questions can improve things "invisibly".
I don't know about you, but I don't tend to have breakfast and lunch over Zoom.
While I did go out to lunch with coworkers more often while working in the office it was almost exclusively with direct teammates, and other groups I occasionally saw where also on the same team.
Now that I'm fully remote, I will typically do a few "hacking sessions" over Zoom every week. Its much easier and more comfortable than standing over their shoulder in tiny cubes we used to have.
That said, especially now that i am fully remote, I've been trying and mostly failing to get developers especially across teams to talk and collaborate more. But its not too suprising: I was recently in a call and I was introduced to another developer who I replied, "Yeah, I know you. I was in the cube next to you for 2 years and on your team for 6 months."
Remote creates some new challenges, but its a culture thing, not a technology thing.
My thoughts were that neither of them should have been surprised by the rating. When a rating comes in substantially different than expected, it's usually because A) They aren't talking during the week B) The manager is weak and doesn't want to issue corrections when they meet C) The employee isn't asking "How am I doing?" during their meetings D) It's being directed from upper management for obscure reasons.
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.
> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.
But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.
I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds like the devs who you think gamed the system, were mostly behaving the way scrum is meant to incentivize. Happy, stress-free development that delivers consistently improving software.
(Minimum point totals per week leading to inflated point values is terrible management, though.)
I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value.
The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential work and guide them towards work that is easier to estimate.
Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable.
But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate.
One thing that scrum does give is it provides management metrics they can use to measure performance.
OP here. You are right, but the minimum point totals eliminates any benefits that can be achieved from scrum, it forces engineers to incentivize survival over project momentum. If a story is really a 3 pointer but I know that if I close 2 3 point stories in a week then I am pipped, suddenly those 3 point stories are 5 point stories.
On the teams that played fair, it was a mix of sr. and jr. and the sr. measuring that story at a 3 meant the jr. was working the weekend. Over and over again.
Note: On the happy team, we had almost no supervision, not even a scrum master. We just looked out for each other. That 3 point story often suddenly became an 8 as the end of the week approached and no one blinked. That team incidentally was the only one that consistently got good reviews from management.
> But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.
Maybe as-written but not really ever as-practiced.
They were splitting tickets to avoid being let go, not because they necessarily warranted it or comprised logically separate things. I'm pretty sure that's not how scrum is supposed to work, but if it is it doesn't sound good to me.
> 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.
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.
"So in the short term, the company benefited, yeah"
In hind sight, they did not. The company is publicly traded and recently sold itself for parts to avoid bankruptcy. They are in a very niche industry and are notorious for their production environment going down, and massive data corruption in their clients data set. There are worse things as well but I am trying to be at least a little anonymous here.
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).
We called that Scrumflation at a past company. Didn't finish everything for the week? Claim the ticket was done and open a bug for the uncompleted work.
My anecdote about this is a case where I was an external consultant in a company.
The management decided to base bonuses on "number of open tickets assigned to a person measured on day X". Smaller being better.
(Un)surprisingly I got a bunch of tickets assigned to me on day X-1 and they were reassigned on day X+1. I didn't mind, since my bonuses were determined by customer satisfaction =)
The ironic thing is that may have generated exactly the outcomes management wanted.
I’ve worked at places where it was more important for management to know what to expect than to achieve raw productivity towards a goal.
The people who were estimating in good faith may have assumed that management was acting in good faith. Whereas a lot of projects are created aspirationally or have artificially short deadlines to “motivate” people. The stress they incurred may have just been for the emotional satisfaction of a manager and not have provided any more value than that.
Thats exactly what happened. People that tried to do it right, got punished as they ended up working weekends all the time. People that did as you suggest and went high, were stress free.
Measuring story points across the company is such a weird thing. The meaning of points depends on the team. Like you can decide to multiply all the feature costs by 10 from one sprint to another if you want to.
The only usage of points is to improve the predictability of the output of a team. It cannot be used to measure performance in an absolute way.
If performance metrics are built on points, it just ruins the meaning of points. There is no reason to be honest anymore.
>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.
I read this as the teams that attempted to measure in good faith did a poor job at estimating. If management tells you that you are required to deliver 10 points per week, then 10 points should take you 40 hours with rare exception. Whatever other idea you had in your head of what 10 points "should" mean is simply incorrect.
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.
Having some knowledge about how such contracts usually go there’s approximately zero chance of him getting it.
It’s not just about potential corruption but also about how risk averse large organizations are. The tender would definitely include revenue, employee count, and potentially other thresholds, as well as require that X such projects have successfully been carried out during the past Y years.
Serious question: isn’t this illegal? Technically the $job was paying $Tommy for his expertise in networking. If $Tommy withheld that expertise and instead entered into a conspiracy with $friend to launder his expertise for more profit from the company, it seems like double dipping.
The only way (I think) $Tommy could have done it cleanly would be to quit and instead start the enterprise with $friend before approaching $job.
In a system that doesn’t have any forms of rewards, this should be a logical path to follow. In fact, Tommy has considered this approach as the way to go from now on but only when he got hit hard by his first experience.
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.
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)
I'm one of these firefighter type, and it's causing some frictions with others developpers, because my code is not great and not future proof.
But I get the job done quickly, and lots of my quirky code have saved the day, either by solving an emergency or winning a tender.
It's difficult to communicate with "perfect minded" developpers, because for them if code is not thought-out, then it's not worth anything, even if they understand the need for speed. Of course they think the reverse about me^^
We're set up a weekly meeting to alleviate the issue and it's working OK. The hardest is finding out which "type" is the right one, when it's not an emergency but there's a tight schedule/unclear specifications... At least we make a common decision
>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
Yes it is. Putting out fires, quickly, is very important.
The problem comes later when the breathing sapce arrives to regularise the fix and replace the band-aid with good quality code.
At this point no fire is burning, the problems are not immediately visible, and it takes very good management, right up the stack, to fix that sort of problrm.
> Not exactly something to encourage
Yes. Exactly right. Because the band-aid with all its ugliness becomes the permanent fix because there is no revenue box to place the work in takes to fix it into
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.
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.
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.
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?
You are taking the wrong lesson from the article if you think they are saying every (or even most) senior developers should be doing this. You absolutely don't want every senior developer spending their time mentoring/working with junior developers, but having a couple of those people on the team is a force multiplier and benefits the team as a whole. They may not have realized it when they hired him, but he found a useful niche and once the company identified it they should have changed his role to make it official.
Agreed. Tim was not doing the job of a programmer if he never actually wrote code that delivered value. Tim was a coach. Which is fine if that's what you hired Tim for, but I suspect that if you wanted a coach, you would've hired one. Hard features simply can't be done by juniors even given infinite amounts of time: they just don't have the skills yet, and to gain those skills takes years. Sure, they need a senior to help now and then, but if that makes the senior developers produce nothing, then what's the point for the company?? Just give hard features to people who are senior enough to do them, and if you really want the juniors to learn, let the senior share easier parts of that work (and walk through what he's doing) with the junior.
It's very nice of Tim to help everybody else, but doesn't anybody find it odd that all the other programmers need lots of help in the first place, so much that Tim has zero time to deliver anything himself? Seems that the problem is not with Tim, but with management that thinks it's ok for a professional to need help all the time, and for a volunteer like Tim to be there for them any time regardless of what he's paid for (which in this case, was story points as made clear by the author).
> 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.
Or, it could be said, you need to refactor your codebase so no job is all that "hard and complex".
Should have had one of those seniors build it in the first place, eh, then juniors could be trusted to modify it. Or, what you say, he did? Then why is he "a senior" in the first place, if stuff is "hard and complex" because of how he built it...?
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.
Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor.
It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.
The TL role is a little restrictive IMHO. I’ve worked with very junior people who have a very effective ability to pair and improve others’ effectiveness. Perhaps as they learn they also teach.
The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
A lot of that is from Frederick Taylor, who invented “scientific management”.
He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1].
The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have.
Being superficial wasn't invented in the 19th century. People are very oriented to things they can see, measure and touch, when the most impactful and insightful people are often the silent care takers, the teachers, those keeping things running smoothly.
When you do things right, people won't be sure you've done anything at all.
Acting on the numbers you get is not intrinsically a problem: it's what the action is. Looking at how fast stories, function points or whatever get closed is important for planning what you can get done in a given time, and that can be crucial for project management and managing customer expectations. It's not acquiring the information which is a problem; it's not using the metrics which is the problem. The problem is not understanding what the metric can be used to represent (project velocity), and what it cannot (individual productivity);
The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.
Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first).
He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable.
That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
> where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion
This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s.
The right balance of staying current and not reinventing the wheel is not trivial.
I've written several 100ks LOC/year at points in my career- but exclusively when working on new projects. When maintaining projects I might go a week at a time without writing any code solo, or I might spend a week trying to _reduce_ LOC.
My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management.
It has become taboo to say things like "This code is too tightly coupled", "You don't need to add an external dependency for that", "The inputs to those methods are too complicated; your components are micromanaging each others' state", "You're violating separation of concerns", "The cyclomatic complexity of this code is too high; you could simplify all your if-else statements"... When it's not my company, it's impossible to dismiss code when it works right now, even though it is likely to break later.
I think my net contribution of lines of code at my current company is still negative. It was for a long time, but I haven't checked in awhile so I'm not sure if it still is.
If your leadership is tossing these incredibly valuable engineers aside, then it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. It's crazy to me tech workers aren't unionizing anyway.
(I am from Europe, so I have a fairly good idea of what Unions can do, also thanks to having lived and worked in two different countries).
I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this is rare, and anyway happens only when the company goes bankrupt or decides to shut down.
So I do not understand exactly what you mean here.
You’re largely correct but I think your comment might not nail the root cause (not saying you don’t know this, just that your comment doesn’t emphasize it).
When a market is competitive, the things that matter are roughly: hard work, candlepower, and optics/neurotypicality/maneuver in that order.
When a market is fairly sewn up that order becomes roughly: optics, candlepower, ethical flexibility, hard work in that order.
The hard-ass nerds who don’t give a shit about corporate culture du jour are treated like royalty when someone might fuck your business up.
While “purged” is a strong word, I take your meaning, and whatever we want to call it, it happens when competition is largely pro-forma.
Human beings will do anything to avoid selecting on merit except lose. That’s just human nature. Being mad about it is like yelling at the wind, but compared to even a decade ago, I’m not sure how high I’d be holding my head in today’s competitive landscape for high-prestige achievement.
On an individual level: So what? I stopped giving a f. I'd rather do what I believe is right than earn another $100k a year at a certain point. If it gets to the point of being laid off, hey, maybe it's the nudge you needed to find a better place anyway. Meanwhile, you could play the game all you want and still have your entire business unit shuffled away next year.
I'm not going to drive off a cliff just because the OKR tells me there's actually a road there but I wonder about some people...
> sucks being that person today because everything is about optics
Not everywhere. I’ve casually suggested five big changes to the startup I’m currently working for that others ran with. I’m proud that my ideas even make sense, and my reward is that others come to me for leadership. I would get more glory if I had also carried them out. But I’d rather do the things that others can’t, than what shines the most.
> 2000 lines of code per week terrifies me... That's over 100K lines of code a year
That would be incredible (and scary). But productive people I’ve seen the contributor metrics for who write vastly more than they read, still have a number of deleted lines growing with their added lines in some proportion.
There is a style of less re-use, more copy-pasting that just grows faster but also needs constant refactoring in trivial ways.
Yeah, you have to do it all. Churn out stories AND mentor AND knock down "desk-side" work (random infra bullshit). I have been at big companies where no one lasts very long. Thier mental health suffers to a point where they have to leave so that they can go work at some other sweatshop for a while. The lull between giving their notice and the honeymoon at the new company is their only break.
This is why software craftsmanship is rarely recognized. When you build with craftsmanship so features are easy and fast to add on top of what you built because you thoughtfully the most likely ramifications of the current requirements within reason, operational excellence is easy to accomplish because you sat down with front line operators and took the time to understand their incentives and daily operations pain points from a first-person perspective, and so on, you aren’t the one who is recognized with the commensurate credit, those who benefit from your work in the future are the ones who grab the limelight as if they did your work, unless the leadership are themselves highly technical (and many times, not even then). Incentives currently in most of my clients are mostly aligned to the fulfillment of keywords and not an outcome.
“Produce a procedure documentation” gets keyword fulfilled into “here is a document with some steps”, instead of “here is a procedure we wrote, used spelling and grammar checker upon [I’m still shocked so few take the few seconds to correct as they go], run through an automated editor, then iterated through random people from the user population until someone who never saw it before accomplishes the procedure without assistance”.
Some startups succeed because they’re forced into conscientiously thinking through these ramifications in just the right contexts because they’re so close to the coal face. It is also possible to overdo this in the wrong context and end up bikeshedding.
> It sucks being that person today because everything is about optics and that person will get purged. I know from experience.
This is my company. Engineer skills, tech-debt, teamwork, camaraderie don't matter. Do as the management says, in the time they've promised to others or else....
I worked at companies where de facto lines of code were a metric of performance. Then when I moved to first company where "how" was more important I had a heavy anxiety where I didn't write a line of code for a couple of weeks. I was worried I'll get fired. We were just having meetings and just talking about problem at hand and throwing ideas, without actually trying to implement anything. Then when the ideas how to tackle the problem matured, we would try to turn it into code, like a proof of concept thing (tested with people looking for solution) which could be thrown away. Eventually we would get the solution to the problem and most of the time it was flawless. In the code heavy approach, company would have ton of bugs, support requests, fixes on top of fixes, sometimes it turned out the feature was misunderstood, but it was already so embedded in the system, it was difficult to remove. So things were piling on.
The other approach? Boring. We had some bugs here and there, usually when something was not covered by the tests or some edge case we didn't think of. But I never forget the anxiety...
I don’t know. I’ve met several people who see themselves like this and who are seen by senior leadership as being like this, but nothing they say tracks, even a little bit, with what I know about the system and problem space from my time actually immersed in working on it.
> 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
A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it.
Documenting my code is a trick that helps. When I am writing why I did something, I sometimes reflect, and say to myself "Didn't I just do this a few lines back?"
My code tends to be complex, by necessity, but it should be no more complex than absolutely needed.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" smell, these days.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" signal, these days.
Is it? I’d agree that there’s increasing awareness of the limitations of OOP, and I’d agree that using inheritance excessively can be one of the limiting factors, but I don’t think I’ve ever personally seen anyone criticised or penalised for using inheritance appropriately.
Some of that is the fact industry never really evolved OOP approaches and they tended to trend to toward heavy and complex. Peers aren’t great with the power OOP can have.
I’ve also seen composition go sideways too.
Sometimes it feels like nobody takes software engineering seriously anymore, if I’m being honest
Yes and no, depends on the engineering culture and the management. I was successful in this sort of position as a full-time remote senior and then a team lead from 2016 til 2022. I changed employers and found myself in an environment that simply did not understand pairing, mentoring, etc. Management was oftentimes directly in the way, confused about loss of "velocity" and other trivial bullshit, despite the fact that the team was shipping in overdrive. I left at the start of this year and am now back in a position where these things are valued, encouraged, and happening remotely.
I am one of those people and work a fully remote job, but I had to earn that credibility with years of being a top contributor first. It would be difficult to just walk into the role.
That would depend on the culture of your team and larger workplace. Healthy teams should be checking in frequently to talk about ideas, reviewing big things, scoping upcoming work, etc. If there's time reserved for deeply technical but loosely structured discussion like that, then everybody takes turns being that person. In that env someone could "specialize" in it and help inspire others to do great work.
It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time.
The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!
I assume you mean the thoughtful person whose probing questions unlock and unblock everyone else.
Lunchtime conversation is only one enabler of this.
I suspect the person is Hamming, as he makes reference to this in his book The Art of Doing Science and Engineering.
This aspect of what it takes to be a Hamming is curiosity about what other people are doing; you can track this by reading shipped emails or lurking in slack channels, then reaching out individually to the people/teams involved when you wonder about something.
Hamming was intentional about doing this at lunch. The magic isn't lunch, it is in intentionally seeking the information and then acting on it.
Yeah the main thing I've found helps is if there's a regular Teams/Zoom meeting where everyone just pops in for like 30 min to ask questions. Then you can use that as the springpad to launch into one-on-one sessions.
You do need to cultivate a culture in the team of people being willing to lower their guard and ask questions though. And I think the key to this is just staying humble so people feel comfortable approaching you.
> I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.
This is a strong statement. There are both people who are writing throwaway code and people who are writing essential code that match the description.
And one will never get to be the latter part without going through a phase where they are doing the first.
Friends of mine worked at a place were they got a rock star programmer that churned out thousands of lines of code a week. And they eventually found themselves relegated to the role of cleaning up the mess. So they all quit.
Edit: Take rock stars 3000 lines of code a week and divide by one rock star + six experienced developers now doing nothing but bug fixes and it doesn't seem so super.
> That's over 100K lines of code a year. Think of the unnecessary complexity.
I've got a colleague like that. It's all good and management praises him, but this is a time ticking bomb. When he leaves, someone will have to maintain that code.
We detached this subthread from https://news.ycombinator.com/item?id=37362066. (There's nothing wrong with it but it's a bit generic and I'm trying to make the thread less top-heavy.)
I love writing code. I usually "score" on the higher end for LoC which managers like to praise me for while simultaneously saying LoC isn't everything but there aren't many good measures. Lol.
But! In my defense, I delete as much code as possible. Love deleting code. Not sure if that counts in the LoC. I see lots of others copy and pasting and leaving little bombs everywhere. I refactor, clean, delete. So.. hopefully my LoC is mostly that and not adding fluff.
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.
Because lins of code churned out is not and has never been a good measure of productivity.
That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem.
Which is basically the entire point of the article.
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.
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.
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.
> 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.
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?
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.
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.
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.
And similarly to sports, there are devs who understand this, and devs who actively refuse to do things like pair, mob, or collaborate and just want to be handed work pellets so they can pick up their headphones and go to la-la land.
I don’t expect predigested tasks, and I’m fine with participating in broad strokes planning. But I need peace and quiet when I’m trying to concentrate on writing the code.
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.
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.
(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)
In this case, Tim from the blog post is a football defender or a linebacker if you're an American. Measuring them based on the amount of goals they scored or a touchdowns they caught is stupid. Instead they're stopping costly errors and providing the foundation that allows others to go on and score. You're probably not going to win very much if you field 11 strikers or 11 wide receivers.
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.
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.
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.
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
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...
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.
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.
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.
> 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?
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.
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.
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.
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.
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.
> 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.
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.
>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.
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.
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.
> 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.
Enough commenters here on HN are disagreeing with the article's conclusion that I think we can infer this is not a point everyone here agrees on, and the article was needed after all...
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.
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.
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.
Don't spend all your "empowerment" energy at one company. Companies WILL undervalue "glue" developers (and also "glue" teams). Eventually being so focused internally can hurt you.
Instead, if you're good at helping others, do it publicly. Speak, blog, participate in open source. Turn your "helping others" energy into one of helping the broader development community. Pay it forward there and it will reap more dividends.
Senior engineers in my knowledge and experience are all delivering on something relatively high impact while contributing massively to the team by occasional/often "pairing".
I've seen rare examples who don't "pair" but just deliver by themselves.
I've never seen an example where they don't deliver on anything (planning, design, architectures included) but only "pair" as their job every day.
I agree that it seems like a weird distribution of time for someone senior. It's fine and good to mentor juniors or pair some of the time but I think that in general pairing is net less effective than two people working individually. Seniors certainly and usually team leads are expected to deliver some individual work product. You can definitely help make teammates more effective without spending all of your time on their shoulder.
Also: the business established a metric it wanted ICs to meet, the guy in the story refused to participate in it at all. At the very least, he's demonstrating resistance to following the expectations of leadership. He might be a good team player at the smallest scope, but great engineers can do that and simultaneously play along with management/biz interests.
(I'll also agree with the article that measuring "story points" or whatever is probably a bad metric, like most measures of software productivity.)
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
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.
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.
Seniors are usually expected to do these things and also produce tangible artifacts. At the principle / architect level maybe you aren't producing code artifacts but you should easily be demonstrating 7+ figure impacts to the business from your efforts.
Too lazy to track down the exact company, but the author does link to Tim's LinkedIn. He has many titles as "Agile coach" and his lede is
>Enabling technology teams to operate at their full potential
Sounds like he is a very particular type of developer focused precisely on enabling teams in this manner.
-----
also, I can just post the obvious here but: he may be doing work but not tracking it. I've never been perfect at creating stories for every task I get, especially retroactive ones that pop up in the middle of the week.
The team being described here was one where all work was done paired. Senior engineers were never delivering by themselves. It sounds like you have experience of teams which are not like that, which makes comparisons ineffective.
The real reason Tim showed up as having zero productivity was because he always let his pair put their name on the ticket, and so get the credit for it. This is really a story about how things go wrong when a ticket tracker designed for solo work is used by a team which pairs.
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.
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.
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?
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.
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.
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.
> 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!
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.
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.
"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.
>Anyway, management will of course argue that developers under them are incapable of seeing everything management does.
What a coincidence! Thats one of the first thoughts that crept into my head when code metrics started being used on me.
This "voyage of discovery" you've alluded to is exactly what I meant by no downsides.
If managers feels threatened by being measured by their employees after their employees start measuring them, well, that's also an interesting reflection is it not?
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:
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.
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?
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.
<Ultimately the best way of measuring programmer productivity is by the assessments of the programmers on the team. >
Maybe ... Productivity itself is difficult to define. Different people will value aspects of the work differently
At one Internet Advertising company I worked for, the founder had written most of the original code. Written in the late 1990s, it was Perl, JavaScript, HTML, and SQL jumbled together. Completely ignoring the notion of 'separation of concerns'. Huge amount of code duplication. Source code control? Phhht! Nary a test in sight. Ran programs as root to work around permission problems. Self modifying code ... you betcha. He worked right on the production servers. He could and would push out a feature the same day a customer asked for it. VERY quick to make the customers happy. The company was being bought out at the time I came on board. Pocketed his millions, headed down the road, yay for him.
My own take is that the company would never have 'made it', if a software team had been hired to 'do it properly'.
After his departure, as we rewrote our code base to 'professional' standards, much time was spent refactoring that produced few or no new features. How productive was that? A very complex question.
As a digression, I sometimes found his original code easier to maintain that the stuff done 'the right way' because there WAS no 'separation of concerns'. I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
In the end, 'productivity' is way more subjective that we'd like.
> I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
This is my take too as I have gained experience. The way I did code from the get go, was the overall best way. Long function that did the stuff one thing at a time. Like no functions called from different parts of the call tree. I breeze to debug and understand or modify.
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.
> 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.
Exceptions are for exceptional circumstances. An object being a certain type is not an exceptional circumstance, not even in a dynamic language. You should never be surprised by the type of an object unless your program has serious design flaws.
The fact that the language doesn't have your back means you need to be more careful about types, not less. The type of the arguments is a function precondition. It's the callee's responsibility to document preconditions and ideally recover cleanly from a violation, but the caller's responsibility to ensure preconditions are met. Illegal states should be caught early, not allowed to percolate until an exception is thrown.
I don't much care if what I just wrote is "Pythonic" or not. I don't think too much careful design up front is responsible for every Python codebase I've ever seen reading like Finnegan's Wake.
If you are calling something immediately, a try-except is ok. If you are calling with a try-except just to simulate hasattr or getattr then why do we have the built-ins in the first place?
So I used to kind of think like you, but I think that's just not a practical approach. Yes, you could alter the system in this 1 exact situation if you know exactly what to change, but there will be dozens of other failure modes too (engineer releases code that breaks in 2 months, engineer deliberately mis-estimates story points, engineer doesn't comment their code so that nobody else on team can do certain work, etc)
So if you have a manager who is a dialed-in coder who's going to keep updating the jira-point formula based on spending more than 1 hour a day reading code, and keep tuning it around the ever-more creative loopholes engineers employ, then yes, you may end up with a workable system. But never yet in my long career have I seen that.
No, no, you misunderstand. I agree with the point. I just think it was made against a strawman and could have been made even stronger. I'm not for metrics on stories to award productivity points. I'm for one-on-ones and success-as-a-team evaluations.
> 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.
The story includes a part where they dropped the crappy metric and changed to a better one.
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.
In almost all companies, even seeking help is frowned upon. One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Some actively don't want to help out others, due to PIP/bonus culture. At Amazon, some team members explicitly give bad advice when asked for help. That's why we have this culture of "lone rockstars", who spend a lot of time to learn without being mentored.
Seeking help isn’t the problem. It is priorities. Usually the best developers are tasked with the more impactful tasks whose deadlines must be met at all costs. As a manager, I would view my task is to shield said developer from distractions so he can save my butt because my job is also on the line.
If someone is intentionally giving bad advice, that sounds like they deserve some anytime feedback. (is that still a thing?) That is definitely not thinking like an owner.
this post is really strange because it actually describes a good environment
- code isn’t changing in code review except for really good reasons
- people who need help are reaching out
- projects that need help get additional help brought in
what else are you looking for? this example is about as pair programming as it gets at most places. they’re called silos when people don’t like them and layers of abstraction otherwise but they’re the same thing: no team will have 100% shared info on all parts and knowledge transfers on exits are a decent step to bridge this
if you want to teach the team more, teach them more. usually the best way to do this is in code review. it’s direct comments on code. write a good review you want more people to see? post it in the chat. set up additional time to share ideas with the team. all of these things you can do as an IC while producing code
sorry but this post comes off as “i’m smarter than everyone.” i’m guessing the reason management hasn’t gotten your message is the message isn’t clear. what exactly do you want to do? and what do you need their help for?
I don't think code reviews are the _best_ way to teach. Because for a start, you're usually working with a complete task. Someone can have a perfectly fine pull request that implements the feature or solves the bug, but it might not be the best way of going about it.
Now, as a reviewer your spidey sense tingles and you get the feeling there's a better way. But now it's significantly more effort to pull that change apart or start from scratch and experiment with a new approach, then write this all up on the pull request with the caveat "but what you've written works, so in the interest of time we can merge this".
Pair programming would get you on the right track from the start. You are able to assist an inexperienced dev and guide them through the process step by step. Imbuing your knowledge, raising questions, suggesting fixes. This is exactly what the blog post describes. The developer was seen as unproductive because their time was spend pair programming rather than directly doing the work themselves.
I don't see how my post comes across as "I'm smarter than everyone". I know things that less experienced developers don't know, and that's a fact I know from talking to them and reviewing their code. But the culture just isn't there to be able to spend significant portions of my day effectively being their teacher (which I would love to do!). Instead it's often "the blind leading the blind" while the more senior members of the team are off delivering important projects and not having the capacity to imbue their knowledge onto the less experienced members of the team.
It's a culture thing and I wouldn't say it's a good environment for nurturing new staff. Spending 2 hours in a Teams call or at someone's desk is uncomfortable for both parties in a company that doesn't encourage this sort of collaboration. And so there's a sense to not "waste someone's time". The person you're helping sees themselves as a burden rather than seeing themselves as a student. And as a teacher, you're conscious of the other work you're supposed to deliver because it's not expected for you to be spending significant parts of your day pair programming.
Pair programming sounds so stressful and unproductive to me. You can't read someone's mind. Any interjections while someone is in the middle of coding can't be more than distracting noise most of the time. And I would constantly feel self conscious that I'm taking too long to write something, googling or asking Copilot stupid questions, etc. Reviewing after the programmer believes it's ready to review makes much more sense to me. Though Copilot can be very helpful as an artificial pair programmer.
The point of pair programming isn't really to be talking to someone while they are coding a known solution. It's to work through and discover a solution together to an unknown. In this sense, you're kind of both in the same headspace together, and can have a conversation without necessarily breaking focus. And I would venture that almost any question that comes up in pair programming would either come up later in code review, or could be hand-waved with "yeah, I plan to fix that with X" and move on.
The important part of pair programming isn't really the programming per se, it's the discussion.
It also requires some amount of conversational art. As for being self conscious about things, you would have poor coworkers who make you think that or some unfounded worry. A good pair programmer can have a discussion without making you feel like an idiot - much the same as a good code review.
I agree with you for a case where you are taking a feature from start to end. The case where you are spending half an hour unblocking someone who is stuck or brainstorming a better solution for something tends to be beneficial though.
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.
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.
Apparently I am pretty lucky. My managers are explicitly asking me to help rescue a project AND get the dev who did most of the work upskilled and following some of our patterns from some other successful projects. It is hard to know whether they are actually taking my advice and changes to heart and integrating them into their knowledge base and mindset, or just accepting that they're being asked to make changes by me and doing them.
Mentorship is hard, regardless of management buy in :/
Pairing gets a lot of hate and is very misunderstood. It can be terrible, though, if the org doesn't encourage and teach it. There are also lots of things about pairing that are misunderstood, especially that things take more time.
I was on a team that paired all the time and it's sort of ruined me for anything else. We switched pairs daily and everyone would pair with everyone else (on the team). When a junior joined the team they would very quickly lose their junior status.
Have juniors plan out work first in design doc form and broken up into small deliverables. Helps to catch things early when they start down a rabbit hole.
Yes very similar. It makes me very happy when I'm called over by a junior proactively. Not mainly because I'm able to help them, the real reason is that they sensed something about the problem that needed a second pair of eyes, and they didn't waste time. That's them gaining intuition and experience and I get really happy for them.
I don't actually say it though because I don't know how to express it.
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.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
I agree that firing people based on delivered story points is probably wrong. I disagree that measuring the amount of story points someone delivers has no benefits. In this case, it surfaced a very interesting dynamic in a team that apparently the company wasn't aware of, and now that it is surfaced, it can align that team better to the goals of the company. I would really wonder, for instance, how Tim was evaluated on performance, if the expectations of him didn't align with the role he was doing.
I think the part in the article where a manager wanted to fire Tim because he delivered 0 story points, and the teamlead (?) refused, is made up for dramatic effect. I can't imagine any manager seeing those type of results and instead of asking the teamlead what's going on there, jumping to the conclusion that Tim should be fired.
At the end of the day, it's all emotional and biased human beings subjectively evaluating/judging other human beings. This guy that worked with Tim believed that he added great value to the team. A manager came to a different conclusion. It's impossible for them to determine who is "correct," let alone us. Of course we can come up with all sorts of potential scenarios but it seems pointless and unfounded without first-hand knowledge of the situation. The skill of being a manager is deeply understanding the specific and individual nature of their team rather than trying to apply a more generalized "playbook."
Edit: By that I mean that I am highly skeptical of metrics used to evaluate people. It's a lazy way to make the job easy and avoid doing the hard work of getting in the trenches, gaining unquantifiable insight into what's going on, and effectively communicating that up the chain.
Of course. My point is that this exact same situation, at a different company, may have surfaced a Tim that actually should be PIPed because he wasn't doing what he was asked to do, or his contributions weren't as valuable from an objective point of view (but of course all his peers love him taking some load off and them being able to get all the credit), or he was forcing a team dynamic that should be "fixed" because Tim is actually a Brent (from Phoenix Project) that had to have his hand in everything and the team couldn't survive without him, yet it may be difficult to discern these situations from the situation described in the article where Tim (sounds like) he was definitely bringing more value to the team than a replacement would.
Yeah it's a few hypotheticals onwards, and there's probably better ways to surface those problems, but companies are messy and no one is without flaw or 100% competent, no engineer and no manager.
(Note that I'm not saying evaluating a person based on delivering story points is optimal, or even useful)
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.
Definitely cultural. I have been watching engine teardown videos. The difference between the Japanese motors and American motors is stark if you know what to look for. Engineers were clearly in charge of designing every aspect of the Japanese motors. American engines have so many compromises and they flip-flop on internal parts and designs, that look whilly-nilly in comparison.
It's obviously cost cutting niggling and get-it-out-the-door histrionics causing this chaos. There is significant impact to longevity and durability, and required maintenance. Very wasteful from a global warming perspective.
Watch out for these late model ICE engines...do your research. If it's "newly redesigned!" step back and dig in.
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.
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.
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.
"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...
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.
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.
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.
> 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
> 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.
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
It's entirely possible that the subject of the article is a terrible programmer, if he were to sit down and write or maintain something as an individual contributor.
I've worked with people like that, who were pretty bad individually, but brilliant when part of the right team.
Writing code and directly enabling the productivity of others who are writing code are different skillsets.
Obviously there's some overlap, but you're most productive in Tim's role in you're complimenting the skillset of the person writing the code.
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.
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.
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?
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.
> 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".
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.
"Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. ... Bill Atkinson ... thought that lines of code was a silly measure of software productivity. ... [He] made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code. ... when it was time to fill out the management form ... he thought about it for a second, and then wrote in the number: -2000. ... after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied."
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.
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.
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.
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.
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
Or, the past isn't the present. It was very difficult to get a job in the US in 2008 and now it's easy because it's 2023. (slightly harder for some kinds of tech)
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.
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.
Unfortunately, I have seen many of these types of people pass by management. The worst ones are the ones who do play political games correctly because they’re the ones who either get away with it at the very least or worse, make the talented engineers want to leave. Basically, the latter can completely destroy good teams.
Yup, I’ve seen many people like this in engineering. They “put all their skill points” into Charisma. Then they go on to build long, prosperous careers by bullshitting and charming senior management, until they themselves are promoted to senior management. It is a reliable, proven career progression for the incompetent.
They need to fire his manager first and then assess this guys capabilities. Maybe he is not guided enough. Maybe he is plain stupid. Full responsibility of his manager.
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.
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.
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.
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.
> 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.
I've worked with several types of people. For me, the best mentors were the ones who would answer questions I had with the full answer, often with details. Then they got on with what they were doing while I went back to my desk and tried to understand/retain some of what they told me.
I'd personally find someone shadowing me and asking questions super annoying.
I don't think this would work with all teams, the takeaway I got from the article is about artificial metrics.
> 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.
"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.
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!
I know it's too late now, but you are the type of developer that makes our profession an actual craft. Sharing knowledge is the biggest benefit to provide other developers, and too few that decide to go that route are rewarded for it. If it weren't for developers like you, we wouldn't be anywhere close to where we currently are in the software world. I try to give back knowledge as much as possible, because it's not just about the one business you work for, it's also about building up somebody. Know that you're appreciated, even if you aren't getting direct thanks for it!
Wow, thank you. I am grateful that my comment attracted so much thoughtful discussion. But your comment is the one that really touched my heart.
I was reading it to a close friend just now, and I have to confess that I choked up a couple of times reading it.
So again, thank you, my friend.
p.s. You don't happen to be anywhere near the SF Bay Area? If you are (or even if you're not), please drop me a note at the email address in my HN profile.
Anyone else who is in the mid-Peninsula area, feel free to do the same. It would be nice to meet up with people who have an interest in this topic.
3 replies →
I did an internship during uni as an electronics technician repairing handheld, vehicle mount rugged terminals, and base stations (rf network controllers before 802.11 arrived).
Each repair job had the same priority but some were much simpler than others - one month I thought I’d take the base station jobs to learn and because no one else was repairing them. They took longer to fix but obviously were more crucial to operations.
At the end of the month PHB held a team meeting where pie charts of utilisation were shown and I had performed terribly against the rest of the (senior and experienced) team. That was the moment I learned that the senior staff were picking off quick and easy jobs for a reason, and that office politics was a thing.
PHB couldn’t understand my reasoning of selecting those jobs and the outcome was his dislike of my performance… glad I learned about poor bosses that early in my career.
So without someone like you they would literally not repair some units? I guess they chuck and replace them?
1 reply →
I had a similar experience to yours. Back when I was the equivalent to what is now staff engineer, my team got a new boss. On paper, I didn't look amazing, but I was constantly helping people.
My new boss admitted at our first review that he had written up a performance plan, but threw it out not long before. What happened was we just transitioned to an open office, and he got to see the line of people who would come to me for help, and how I wouldn't turn anyone away.
I was a little salty about losing my cubicle, but that experience definitely made me appreciate being in an open office.
Of course, I haven't worked in an office of any kind for years and will never take a job that isnt WFH again, so take that last bit with a grain of salt ;)
Have you found a way to keep up with the "question answering"-part while working remotely?
Did the culture around questions change compared with working from a shared office?
1 reply →
It’s important to find/figure out what a company values and optimise for that. Once a reputation has been established, it’s then possible to go about changing things, but not before.
I’ve seen too many stories of people optimising for the “team”, but losing their job or being looked over for promotion due to negative perception from those higher up.
The opposite is also true, sometimes unfortunately. Once a good reputation has been established (whatever is currently valued in the company), any amount of misbehaviour will be tolerated for a long time.
It shouldn’t be this way, but that’s been my experience.
> It’s important to find/figure out what a company values and optimise for that.
One important ingredient for this is to know many companies will actively lie about their values. Typical case is, everyone tells you they value quality and feedback, while in reality everything is rushed and actual suggestions are at best thrown away in the "later" bin.
> Once a reputation has been established, it’s then possible to go about changing things, but not before.
I've noticed 2 patterns in my various gigs in the past: The virtuous cycle where I'm trusted to build something with significant autonomy from the start, I end up being happy, motivated, productive; and the vicious cycle when I'm just a new untrusted cog in their machine, my motivation & productivity plummet.
As far as I can tell I have no control over the initial condition, and the only way I could break the cycle was to start fresh in a new assignment. Some would suggest I suck it up and work my way up, but to be honest I no longer have the energy to pay my dues over and over again.
2 replies →
What happened after the mediocre performance review? Did leave for greener pastures asap? Did you start to optimize for their performance metrics, and stop being generous with your time? Or could you manage to convince somebody high enough above you in the org-chart that they actually hired you for what you thought they did?
Thanks for asking. It all worked out OK. I had a good relationship with my manager, and he actually seemed a bit embarrassed that he had to put those remarks in the review.
I also had a very good relationship with both the VP of engineering and the senior VP who oversaw the entire product and who I'd worked with before on other projects.
I did leave eventually, but it was for unrelated reasons.
1 reply →
What an odd practice. Not sure who conducted the review, but managers especially should be familiar with the concept of coaching, and recognize that you were doing a great deal of it. I am a technical manager myself and spend a lot of time on coaching team members too.
20 years ago when I started there wasn’t anything I experienced that could be called coaching, mentoring, or leveling up. Sure, I could get some time from a more experienced developer to get another set of eyes on a particularly hard problem if I wasn’t able to come up with a solution but for the most part I was just expected to work with minimal explanation or direction. Very little in the way of code reviews as well. I certainly hope this has changed and to whatever extent I’ve been able to I’ve always tried to make myself available to others because sink or swim really sucks.
4 replies →
Just a quick note to thank everyone for your thoughtful and insightful comments here.
As it is a holiday weekend, I may not be able to get back to every reply right away.
I am grateful that zdw's submission and my comment led to such an interesting discussion! Thank you all.
I hope that feedback didn't discourage you from continuing with your approach to software development and teamwork.
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.
6 replies →
It's easy to say that until it affects your paycheck.
PSA... check out this guy's LinkedIn profile. It's a great read.
Thank you! You gave me an excuse to look at my own LinkedIn profile, which I've ignored for a few years.
I have a distinct memory from not that long ago when I was unemployed and asking people for advice on what to put on LinkedIn and on my resume.
One consistent piece of advice was "Don't list anything more than five years ago. People will think you're old!"
I thought, "Screw that, everyone already knows I'm old."
So I decided to just tell my story, all the way back to the beginning in the days of punch cards and Teletypes.
I am grateful that you appreciated that.
2 replies →
I’m impressed by Michael’s LinkedIn profile and extensive experience. If you ever take up blogging, I imagine you’d have a lot of lessons and experience to share.
I suppose this comment will not be liked very much, but let me offer one another perspective on this. In one team in our organization, someone was hired who offered themselves (by their own initiative) as a developer coach with the intent on pairing, reviewing and in general helping other devs. They were very confident, and as we employ team recruiting, the team decided it's worth a shot, as the candidate displayed knowledge of relevant skills and - as already mentioned - was very confident to educate his peers. It was an intra-organization lateral move, so not much risk involved. Everyone was on board with that decision, and the expectations were clear: they would not be expected to produce code and/or design documents and so on, they should just support the other devs. It should be mentioned that the team they wanted to join was a really high performing team - still (or because of this?) they were open to the idea of having a well-trained, experienced pairing partner and so on.
Well after a few weeks it turned out not so positive. They had quite a broad knowledge of things, but not in depth. They didn't think far enough (like for example, giving the tip to "use a FIFO SQS queue" despite not really understanding the fine-print, but still they persisted and it ended up in a prod rollback), they preferred educating about code style, didn't really listen to feedback (not in the sense of ignoring it, they didn't even realize that they weren't so senior compared to the rest of the team at all) and in general slowed everyone down without bringing much benefit to the table.
In the end they didn't get fired or something like this. They did another lateral move as the team explained why the team doesn't want to continue this. After their next team change, they talked about that this specific team didn't want to accept their help and that they had received bad feedback since they didn't produce code.
Obviously this is just an anecdotal counterexample, but still this can happen as well.
Much can be done with self advocacy
I was hired at a company to help scale their development because their app was growing fast but they needed a leap forward in architecture and approach or they couldn’t keep up with growth.
I documented everything I did from day 1, from what I was doing as well as why.
When it came review time, everything ended up reflecting really well, for I may have closed less tickets than my peers, my peers where closing more tickets than ever, and there was a direct line from my work with them to that productivity increase.
Once upper management wrapped their heads around this they completely understood why I was effective at helping shift features: the A -> B wasn’t possible without me spending lots of time with others and helping with their projects, and we would have needed more headcount to achieve what we did by having me work with the org the way I was vs trying to juggle feature work with it
It’s all about the metrics at the end of the day, in some ways. If you can demonstrate your impact across the board it’s hard to dismiss
yep, you have to be loud about your work, especially if it is not trackable via other direct metrics like ticket count
1 reply →
> Some 20 years ago... I called "house calls": visiting other developers' offices...
Ah, the good ol early 2000s, where devs had "offices" or "cubicles" to themselves.
Now I have a whole house with two offices, just for me!
1 reply →
That’s only a problem if you chose to work somewhere mandating RTO. I have a great personal office and kitchen where I work.
I quit a job way long ago for very similar reasons. I cared about raising the level of the people around me. I wanted the junior folks to get credit and advance in their career. This meant my work was not readily visible.
A director said to me: "I can't remember the last thing you worked on." In that moment I knew it was time to leave. I was gone a few weeks later.
Just last February I was let go from the best gig of my career, under similar circumstances. I knew that I was not hired specifically to help other devs, but it appeared to be appreciated and encouraged. Well, I guess not.
I have made this mistake more the once as I actually like working with people and helping them level up. Something I do now is make sure that if I am being hired as a developer of some sort, the metrics of success outlined clearly in my offer letter also include giving mentorship. It’s measurability usually revolves around peer reviews and how much others value my help. I have been accused of gaming my performance metrics because I would literally be helping people until they are able to tackle the problem independently. Which, I don’t know, sounds like a job well done to me.
> a few months later
> Which was exactly what I thought they had hired me for!
It's good to regularly update your manager with what you're doing and accomplishing, as they may not realize it at all.
Then you have to wonder why they're there in the first place. Managers that do not manage and do not know what the people they are supposed to be managing are up to can be missed.
1 reply →
I think that is why it's important for development managers (team leads, tech leads and whatever else you would like to call them) to be either actively doing hands-on work or having been reasonably good developers in the past. Then they can appreciate this kind of work better.
[dead]
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.
It might be from the great book The Idea Factory by Jon Gertner (p 135).
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.
9 replies →
Harry Nyquist isn't exactly an unknown engineer who doesn't have his own achievements, though - not sure why people are saying he would be fired in a modern company!
10 replies →
Reminds me of the adage of “solving the problem is the hard part, the hard part is figuring out the right problem to solve”.
I always remember as “questions are harder than answers”.
Wiki says it is this guy: https://en.wikipedia.org/wiki/Harry_Nyquist
Woah. He has a huge list of "Known for"!
Yeah that's the one! Thanks for finding the reference.
Rumour has it Nyquist was promised to be on 18 breakfasts a day to placate investors after a slow quarter.
You also need a fertile soil. In many many places, curiosity, exploration is passively frowned upon.
That kind of people was somehow mentioned in Peopleware. A group of people is a subtle structure, and good team spirit, good questions can improve things "invisibly".
This type of person needs to start a company, they never get paid a fair wage otherwise
True for most of the working class, whose surplus labor value is siphoned away by capital.
For all a lot of people dump on Scrum Masters and Agile Coaches . . . this is part of who the good ones are supposed to be.
Oh No!
Good people amplifiers are domain/technical experts; Scrum Masters/Agile Coaches are neither.
12 replies →
Do people honestly think this kind of thing replicates with formally scheduled Zoom 1:1s? I don’t.
I don't know about you, but I don't tend to have breakfast and lunch over Zoom.
While I did go out to lunch with coworkers more often while working in the office it was almost exclusively with direct teammates, and other groups I occasionally saw where also on the same team.
Now that I'm fully remote, I will typically do a few "hacking sessions" over Zoom every week. Its much easier and more comfortable than standing over their shoulder in tiny cubes we used to have.
That said, especially now that i am fully remote, I've been trying and mostly failing to get developers especially across teams to talk and collaborate more. But its not too suprising: I was recently in a call and I was introduced to another developer who I replied, "Yeah, I know you. I was in the cube next to you for 2 years and on your team for 6 months."
Remote creates some new challenges, but its a culture thing, not a technology thing.
2 replies →
My thoughts were that neither of them should have been surprised by the rating. When a rating comes in substantially different than expected, it's usually because A) They aren't talking during the week B) The manager is weak and doesn't want to issue corrections when they meet C) The employee isn't asking "How am I doing?" during their meetings D) It's being directed from upper management for obscure reasons.
That is a catalyst!
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.
> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.
But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.
I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds like the devs who you think gamed the system, were mostly behaving the way scrum is meant to incentivize. Happy, stress-free development that delivers consistently improving software.
(Minimum point totals per week leading to inflated point values is terrible management, though.)
I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value.
The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential work and guide them towards work that is easier to estimate.
Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable.
But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate.
One thing that scrum does give is it provides management metrics they can use to measure performance.
8 replies →
OP here. You are right, but the minimum point totals eliminates any benefits that can be achieved from scrum, it forces engineers to incentivize survival over project momentum. If a story is really a 3 pointer but I know that if I close 2 3 point stories in a week then I am pipped, suddenly those 3 point stories are 5 point stories.
On the teams that played fair, it was a mix of sr. and jr. and the sr. measuring that story at a 3 meant the jr. was working the weekend. Over and over again.
Note: On the happy team, we had almost no supervision, not even a scrum master. We just looked out for each other. That 3 point story often suddenly became an 8 as the end of the week approached and no one blinked. That team incidentally was the only one that consistently got good reviews from management.
2 replies →
The point of scrum is to provide employment for consultants and non-engineers.
I left engineering for an engineering job in finance. No scrums, no POs, just trader driven development and I haven’t looked back once. Glorious.
2 replies →
You’re missing the point, it’s not about scrum it’s about making the work look like it’s way more than it is to pad the metric.
What Scrum "intends" to do, and what it actually does, are radically different.
1 reply →
> But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.
Maybe as-written but not really ever as-practiced.
They were splitting tickets to avoid being let go, not because they necessarily warranted it or comprised logically separate things. I'm pretty sure that's not how scrum is supposed to work, but if it is it doesn't sound good to me.
Stress free and delivering at a predictable rate. Nailed it.
1 reply →
When there's a good, engaged PO then Scrum can work.
> 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)
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.
"So in the short term, the company benefited, yeah" In hind sight, they did not. The company is publicly traded and recently sold itself for parts to avoid bankruptcy. They are in a very niche industry and are notorious for their production environment going down, and massive data corruption in their clients data set. There are worse things as well but I am trying to be at least a little anonymous here.
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).
I don't think they did. If churning out low-quality code for 6 months was good project management, the Linux Foundation would be doing it.
We called that Scrumflation at a past company. Didn't finish everything for the week? Claim the ticket was done and open a bug for the uncompleted work.
Goodhart's Law - "When a measure becomes a target, it ceases to be a good measure"
My anecdote about this is a case where I was an external consultant in a company.
The management decided to base bonuses on "number of open tickets assigned to a person measured on day X". Smaller being better.
(Un)surprisingly I got a bunch of tickets assigned to me on day X-1 and they were reassigned on day X+1. I didn't mind, since my bonuses were determined by customer satisfaction =)
The ironic thing is that may have generated exactly the outcomes management wanted.
I’ve worked at places where it was more important for management to know what to expect than to achieve raw productivity towards a goal.
The people who were estimating in good faith may have assumed that management was acting in good faith. Whereas a lot of projects are created aspirationally or have artificially short deadlines to “motivate” people. The stress they incurred may have just been for the emotional satisfaction of a manager and not have provided any more value than that.
Seems like it would just incentivise every ticket being estimated as something like an 8.
Even in an environment where story points essentially mean nothing it already ends up with some people just wanting to put high numbers on everything.
Thats exactly what happened. People that tried to do it right, got punished as they ended up working weekends all the time. People that did as you suggest and went high, were stress free.
Points are a relative value.
If its 10 points a week then you estimate based on the assumption that 2 pts is a days worth of work.
That, coincidentaly, is what ours roughly shakes out to be.
Sounds like the stressed teams were lacking in common sense.
What happens if you underestimate one time? You get a pip. Better to overestimate.
1 reply →
Measuring story points across the company is such a weird thing. The meaning of points depends on the team. Like you can decide to multiply all the feature costs by 10 from one sprint to another if you want to.
The only usage of points is to improve the predictability of the output of a team. It cannot be used to measure performance in an absolute way.
If performance metrics are built on points, it just ruins the meaning of points. There is no reason to be honest anymore.
>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.
I read this as the teams that attempted to measure in good faith did a poor job at estimating. If management tells you that you are required to deliver 10 points per week, then 10 points should take you 40 hours with rare exception. Whatever other idea you had in your head of what 10 points "should" mean is simply incorrect.
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.
He should’ve had a friend make a company and bid for the job. Then, later on, Tommy could be brought on as a contractor for extra pay
Having some knowledge about how such contracts usually go there’s approximately zero chance of him getting it.
It’s not just about potential corruption but also about how risk averse large organizations are. The tender would definitely include revenue, employee count, and potentially other thresholds, as well as require that X such projects have successfully been carried out during the past Y years.
Serious question: isn’t this illegal? Technically the $job was paying $Tommy for his expertise in networking. If $Tommy withheld that expertise and instead entered into a conspiracy with $friend to launder his expertise for more profit from the company, it seems like double dipping.
The only way (I think) $Tommy could have done it cleanly would be to quit and instead start the enterprise with $friend before approaching $job.
Exactly, this one!
In a system that doesn’t have any forms of rewards, this should be a logical path to follow. In fact, Tommy has considered this approach as the way to go from now on but only when he got hit hard by his first experience.
Was Tommy upset?
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.
14 replies →
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)
I'm one of these firefighter type, and it's causing some frictions with others developpers, because my code is not great and not future proof. But I get the job done quickly, and lots of my quirky code have saved the day, either by solving an emergency or winning a tender. It's difficult to communicate with "perfect minded" developpers, because for them if code is not thought-out, then it's not worth anything, even if they understand the need for speed. Of course they think the reverse about me^^
We're set up a weekly meeting to alleviate the issue and it's working OK. The hardest is finding out which "type" is the right one, when it's not an emergency but there's a tight schedule/unclear specifications... At least we make a common decision
>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
> Not exactly something to encourage
Yes it is. Putting out fires, quickly, is very important.
The problem comes later when the breathing sapce arrives to regularise the fix and replace the band-aid with good quality code.
At this point no fire is burning, the problems are not immediately visible, and it takes very good management, right up the stack, to fix that sort of problrm.
> Not exactly something to encourage
Yes. Exactly right. Because the band-aid with all its ugliness becomes the permanent fix because there is no revenue box to place the work in takes to fix it into
2 replies →
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.
3 replies →
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.
Even when you do own the company, you are still measured on optics by your customers.
Really good point. Shouldn’t have included that conditional statement.
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.
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?
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.
11 replies →
You are taking the wrong lesson from the article if you think they are saying every (or even most) senior developers should be doing this. You absolutely don't want every senior developer spending their time mentoring/working with junior developers, but having a couple of those people on the team is a force multiplier and benefits the team as a whole. They may not have realized it when they hired him, but he found a useful niche and once the company identified it they should have changed his role to make it official.
Agreed. Tim was not doing the job of a programmer if he never actually wrote code that delivered value. Tim was a coach. Which is fine if that's what you hired Tim for, but I suspect that if you wanted a coach, you would've hired one. Hard features simply can't be done by juniors even given infinite amounts of time: they just don't have the skills yet, and to gain those skills takes years. Sure, they need a senior to help now and then, but if that makes the senior developers produce nothing, then what's the point for the company?? Just give hard features to people who are senior enough to do them, and if you really want the juniors to learn, let the senior share easier parts of that work (and walk through what he's doing) with the junior.
It's very nice of Tim to help everybody else, but doesn't anybody find it odd that all the other programmers need lots of help in the first place, so much that Tim has zero time to deliver anything himself? Seems that the problem is not with Tim, but with management that thinks it's ok for a professional to need help all the time, and for a volunteer like Tim to be there for them any time regardless of what he's paid for (which in this case, was story points as made clear by the author).
> 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.
Or, it could be said, you need to refactor your codebase so no job is all that "hard and complex".
Should have had one of those seniors build it in the first place, eh, then juniors could be trusted to modify it. Or, what you say, he did? Then why is he "a senior" in the first place, if stuff is "hard and complex" because of how he built it...?
One of the points of the post is that this person also helped the seniors do their job better.
But yeah, the job of every senior cannot be to only help the juniors.
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.
Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor.
It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.
Tech Lead is a very difficult role. :/
If you are immature or competitive, you cease being a force multiplier to be a morale destroyer.
If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way.
If you don't have enough time to code, you'll go obsolete.
4 replies →
It also doesn't get people promoted to that position just because that's what they're doing. Because politics.
4 replies →
The TL role is a little restrictive IMHO. I’ve worked with very junior people who have a very effective ability to pair and improve others’ effectiveness. Perhaps as they learn they also teach.
1 reply →
"Negative 2000 Lines of Code"
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
nice, thanks for the link
It sucked being that person back then too.
The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
A lot of that is from Frederick Taylor, who invented “scientific management”.
He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1].
The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have.
[1] https://www.mentalfloss.com/article/63341/frederick-winslow-...
1 reply →
Being superficial wasn't invented in the 19th century. People are very oriented to things they can see, measure and touch, when the most impactful and insightful people are often the silent care takers, the teachers, those keeping things running smoothly.
When you do things right, people won't be sure you've done anything at all.
Acting on the numbers you get is not intrinsically a problem: it's what the action is. Looking at how fast stories, function points or whatever get closed is important for planning what you can get done in a given time, and that can be crucial for project management and managing customer expectations. It's not acquiring the information which is a problem; it's not using the metrics which is the problem. The problem is not understanding what the metric can be used to represent (project velocity), and what it cannot (individual productivity);
2 replies →
The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.
Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first).
He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable.
That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
10 replies →
> where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion
This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s.
The right balance of staying current and not reinventing the wheel is not trivial.
6 replies →
It depends on “when” along the timeline of the project.
If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit.
Later, I care much more about avoiding accidental complexity and having a great technical foundation.
4 replies →
I've written several 100ks LOC/year at points in my career- but exclusively when working on new projects. When maintaining projects I might go a week at a time without writing any code solo, or I might spend a week trying to _reduce_ LOC.
My problem in my last role when I read large Pull Requests is that they tended to be way more complicated than they should have been but because they worked and I couldn't single out a small number of specific problems, I had no choice but to approve. Still, I knew it would slow us down in the medium and long term but this bloat is completely invisible to management.
It has become taboo to say things like "This code is too tightly coupled", "You don't need to add an external dependency for that", "The inputs to those methods are too complicated; your components are micromanaging each others' state", "You're violating separation of concerns", "The cyclomatic complexity of this code is too high; you could simplify all your if-else statements"... When it's not my company, it's impossible to dismiss code when it works right now, even though it is likely to break later.
25 replies →
I think my net contribution of lines of code at my current company is still negative. It was for a long time, but I haven't checked in awhile so I'm not sure if it still is.
4 replies →
If your leadership is tossing these incredibly valuable engineers aside, then it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. It's crazy to me tech workers aren't unionizing anyway.
(I am from Europe, so I have a fairly good idea of what Unions can do, also thanks to having lived and worked in two different countries).
I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this is rare, and anyway happens only when the company goes bankrupt or decides to shut down.
So I do not understand exactly what you mean here.
5 replies →
A union doesn’t have the power to change management, and is just as likely to advocate to retain low performing ICs in the name of “solidarity”
When you can get a bootcamp certificate, and then get two remote jobs and coast at both for 12 months, and then repeat, what could a union do for you?
2 replies →
I prescribe a viewing of "Carry On at your Convenience" to cure that sentiment:
https://en.m.wikipedia.org/wiki/Carry_On_at_Your_Convenience
[flagged]
6 replies →
You’re largely correct but I think your comment might not nail the root cause (not saying you don’t know this, just that your comment doesn’t emphasize it).
When a market is competitive, the things that matter are roughly: hard work, candlepower, and optics/neurotypicality/maneuver in that order.
When a market is fairly sewn up that order becomes roughly: optics, candlepower, ethical flexibility, hard work in that order.
The hard-ass nerds who don’t give a shit about corporate culture du jour are treated like royalty when someone might fuck your business up.
While “purged” is a strong word, I take your meaning, and whatever we want to call it, it happens when competition is largely pro-forma.
Human beings will do anything to avoid selecting on merit except lose. That’s just human nature. Being mad about it is like yelling at the wind, but compared to even a decade ago, I’m not sure how high I’d be holding my head in today’s competitive landscape for high-prestige achievement.
On an individual level: So what? I stopped giving a f. I'd rather do what I believe is right than earn another $100k a year at a certain point. If it gets to the point of being laid off, hey, maybe it's the nudge you needed to find a better place anyway. Meanwhile, you could play the game all you want and still have your entire business unit shuffled away next year.
I'm not going to drive off a cliff just because the OKR tells me there's actually a road there but I wonder about some people...
> sucks being that person today because everything is about optics
Not everywhere. I’ve casually suggested five big changes to the startup I’m currently working for that others ran with. I’m proud that my ideas even make sense, and my reward is that others come to me for leadership. I would get more glory if I had also carried them out. But I’d rather do the things that others can’t, than what shines the most.
> 2000 lines of code per week terrifies me... That's over 100K lines of code a year
That would be incredible (and scary). But productive people I’ve seen the contributor metrics for who write vastly more than they read, still have a number of deleted lines growing with their added lines in some proportion.
There is a style of less re-use, more copy-pasting that just grows faster but also needs constant refactoring in trivial ways.
Yeah, you have to do it all. Churn out stories AND mentor AND knock down "desk-side" work (random infra bullshit). I have been at big companies where no one lasts very long. Thier mental health suffers to a point where they have to leave so that they can go work at some other sweatshop for a while. The lull between giving their notice and the honeymoon at the new company is their only break.
I could be brief.
Or I could elaborate, expound, simplify, and expand my solution.
It depends what I’m getting paid for.
If I’m getting paid for lines of code, guess who’s going to re-implement functions that could have been a single line of code?
Why bother writing a loop function when I could just copy-paste the same code as many times as needed?
Turning one line of code into 3,000 - easy.
Turning 1,000 lines into 100 - that’s when you know you’re working with a professional.
This is why software craftsmanship is rarely recognized. When you build with craftsmanship so features are easy and fast to add on top of what you built because you thoughtfully the most likely ramifications of the current requirements within reason, operational excellence is easy to accomplish because you sat down with front line operators and took the time to understand their incentives and daily operations pain points from a first-person perspective, and so on, you aren’t the one who is recognized with the commensurate credit, those who benefit from your work in the future are the ones who grab the limelight as if they did your work, unless the leadership are themselves highly technical (and many times, not even then). Incentives currently in most of my clients are mostly aligned to the fulfillment of keywords and not an outcome.
“Produce a procedure documentation” gets keyword fulfilled into “here is a document with some steps”, instead of “here is a procedure we wrote, used spelling and grammar checker upon [I’m still shocked so few take the few seconds to correct as they go], run through an automated editor, then iterated through random people from the user population until someone who never saw it before accomplishes the procedure without assistance”.
Some startups succeed because they’re forced into conscientiously thinking through these ramifications in just the right contexts because they’re so close to the coal face. It is also possible to overdo this in the wrong context and end up bikeshedding.
> It sucks being that person today because everything is about optics and that person will get purged. I know from experience.
This is my company. Engineer skills, tech-debt, teamwork, camaraderie don't matter. Do as the management says, in the time they've promised to others or else....
I worked at companies where de facto lines of code were a metric of performance. Then when I moved to first company where "how" was more important I had a heavy anxiety where I didn't write a line of code for a couple of weeks. I was worried I'll get fired. We were just having meetings and just talking about problem at hand and throwing ideas, without actually trying to implement anything. Then when the ideas how to tackle the problem matured, we would try to turn it into code, like a proof of concept thing (tested with people looking for solution) which could be thrown away. Eventually we would get the solution to the problem and most of the time it was flawless. In the code heavy approach, company would have ton of bugs, support requests, fixes on top of fixes, sometimes it turned out the feature was misunderstood, but it was already so embedded in the system, it was difficult to remove. So things were piling on. The other approach? Boring. We had some bugs here and there, usually when something was not covered by the tests or some edge case we didn't think of. But I never forget the anxiety...
>Managers always love a developer who can consistently write 5000+ lines per code per week
What managers care about this at all?
The ones that work at companies that promote incompetence.
You know, most companies.
5000 lines is silly, but all managers love that coder who closes tickets faster than anyone.
1 reply →
The first project I was on that hit half a million lines of code, 2/3 of it was generated. It was a bit ridiculous.
> Managers always love a developer who can consistently write 5000+ lines per code per week
Managers love metrics. There's nothing wrong with metrics, of course. It's when metrics become targets that things fall apart.
https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
I don’t know. I’ve met several people who see themselves like this and who are seen by senior leadership as being like this, but nothing they say tracks, even a little bit, with what I know about the system and problem space from my time actually immersed in working on it.
> 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
A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it.
Documenting my code is a trick that helps. When I am writing why I did something, I sometimes reflect, and say to myself "Didn't I just do this a few lines back?"
My code tends to be complex, by necessity, but it should be no more complex than absolutely needed.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" smell, these days.
A big, big tool for that, is OOP inheritance, which is considered "bad coder" signal, these days.
Is it? I’d agree that there’s increasing awareness of the limitations of OOP, and I’d agree that using inheritance excessively can be one of the limiting factors, but I don’t think I’ve ever personally seen anyone criticised or penalised for using inheritance appropriately.
5 replies →
Some of that is the fact industry never really evolved OOP approaches and they tended to trend to toward heavy and complex. Peers aren’t great with the power OOP can have.
I’ve also seen composition go sideways too.
Sometimes it feels like nobody takes software engineering seriously anymore, if I’m being honest
1 reply →
In a remote world, can that person exist?
Yes and no, depends on the engineering culture and the management. I was successful in this sort of position as a full-time remote senior and then a team lead from 2016 til 2022. I changed employers and found myself in an environment that simply did not understand pairing, mentoring, etc. Management was oftentimes directly in the way, confused about loss of "velocity" and other trivial bullshit, despite the fact that the team was shipping in overdrive. I left at the start of this year and am now back in a position where these things are valued, encouraged, and happening remotely.
I am one of those people and work a fully remote job, but I had to earn that credibility with years of being a top contributor first. It would be difficult to just walk into the role.
1 reply →
That would depend on the culture of your team and larger workplace. Healthy teams should be checking in frequently to talk about ideas, reviewing big things, scoping upcoming work, etc. If there's time reserved for deeply technical but loosely structured discussion like that, then everybody takes turns being that person. In that env someone could "specialize" in it and help inspire others to do great work.
It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time.
The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!
Yes.
I assume you mean the thoughtful person whose probing questions unlock and unblock everyone else.
Lunchtime conversation is only one enabler of this.
I suspect the person is Hamming, as he makes reference to this in his book The Art of Doing Science and Engineering.
This aspect of what it takes to be a Hamming is curiosity about what other people are doing; you can track this by reading shipped emails or lurking in slack channels, then reaching out individually to the people/teams involved when you wonder about something.
Hamming was intentional about doing this at lunch. The magic isn't lunch, it is in intentionally seeking the information and then acting on it.
Yeah the main thing I've found helps is if there's a regular Teams/Zoom meeting where everyone just pops in for like 30 min to ask questions. Then you can use that as the springpad to launch into one-on-one sessions.
You do need to cultivate a culture in the team of people being willing to lower their guard and ask questions though. And I think the key to this is just staying humble so people feel comfortable approaching you.
> I tend to think that the dev who can churn out thousands of lines isn't thinking deeply enough about the long term direction of the project; all the code they're writing is essentially throwaway code.
This is a strong statement. There are both people who are writing throwaway code and people who are writing essential code that match the description.
And one will never get to be the latter part without going through a phase where they are doing the first.
> one will never get to be the latter part without going through a phase where they are doing the first.
The parent comment doesn't contest this. I think it's about the throwaway code author being valued more than the other.
Friends of mine worked at a place were they got a rock star programmer that churned out thousands of lines of code a week. And they eventually found themselves relegated to the role of cleaning up the mess. So they all quit.
Edit: Take rock stars 3000 lines of code a week and divide by one rock star + six experienced developers now doing nothing but bug fixes and it doesn't seem so super.
> That's over 100K lines of code a year. Think of the unnecessary complexity.
I've got a colleague like that. It's all good and management praises him, but this is a time ticking bomb. When he leaves, someone will have to maintain that code.
We detached this subthread from https://news.ycombinator.com/item?id=37362066. (There's nothing wrong with it but it's a bit generic and I'm trying to make the thread less top-heavy.)
Given that DRY is out of fashion, 2000 lines of code per week looks pretty modest.
This is the “sorting hat” the makes sure that person ends up at the right company.
Its not fun to lose your job, but that can be better than being stuck just getting by at a company where your work isnt appreciated.
I love writing code. I usually "score" on the higher end for LoC which managers like to praise me for while simultaneously saying LoC isn't everything but there aren't many good measures. Lol. But! In my defense, I delete as much code as possible. Love deleting code. Not sure if that counts in the LoC. I see lots of others copy and pasting and leaving little bombs everywhere. I refactor, clean, delete. So.. hopefully my LoC is mostly that and not adding fluff.
I'm working through this exact situation right now, I really appreciate this insight!
I want to frame this comment somewhere
[flagged]
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.
Define "productive".
Because lins of code churned out is not and has never been a good measure of productivity.
That "shower thought generator" might very well be more productive than the person they're sitting next to churning out tens of thousands of lines of unmaintainable code if their shower thoughts are causing people to find better ways to solve a problem.
Which is basically the entire point of the article.
12 replies →
Maybe, or maybe human endeavour is more complex than individual efforts.
2 replies →
Idea people really overestimate their contributions.
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.
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.
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.
> 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.
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?
> What is the unit of work for software development?
Dollars.
Duh!
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.
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.
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.
And similarly to sports, there are devs who understand this, and devs who actively refuse to do things like pair, mob, or collaborate and just want to be handed work pellets so they can pick up their headphones and go to la-la land.
I don’t expect predigested tasks, and I’m fine with participating in broad strokes planning. But I need peace and quiet when I’m trying to concentrate on writing the code.
1 reply →
That impact should show up in the plus/minus score?
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.
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.
1 reply →
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-...
[1]: 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)
Came here to say something similar.
In this case, Tim from the blog post is a football defender or a linebacker if you're an American. Measuring them based on the amount of goals they scored or a touchdowns they caught is stupid. Instead they're stopping costly errors and providing the foundation that allows others to go on and score. You're probably not going to win very much if you field 11 strikers or 11 wide receivers.
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.
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.
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.
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
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...
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.
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.
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.
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?
Fortune100 eng here, yes it is a thing.
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.
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.
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.
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.
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.
> 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.
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?
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?
3 replies →
FAANG type compensation doesn't come from "raises", it comes from good yearly performance bonuses.
(Although in my experience the raises you get from changing between smaller companies are still worse than just staying at one FAANG.)
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.
>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.
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.
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.
> 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.
Enough commenters here on HN are disagreeing with the article's conclusion that I think we can infer this is not a point everyone here agrees on, and the article was needed after all...
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.
Ive even seen good managers hold a few incompetents on purpose in preparation of layoff cycles in larger companies that do them consistently.
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.
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.
Stories like this happened is because managers want to treat software development as a manufacturing process.
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!
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.
Stories like this happened is because managers
ok. most managers suck. but ultimately you have to have at least one adult in the room.
2 replies →
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.
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.
I agree that it seems like a weird distribution of time for someone senior. It's fine and good to mentor juniors or pair some of the time but I think that in general pairing is net less effective than two people working individually. Seniors certainly and usually team leads are expected to deliver some individual work product. You can definitely help make teammates more effective without spending all of your time on their shoulder.
Also: the business established a metric it wanted ICs to meet, the guy in the story refused to participate in it at all. At the very least, he's demonstrating resistance to following the expectations of leadership. He might be a good team player at the smallest scope, but great engineers can do that and simultaneously play along with management/biz interests.
(I'll also agree with the article that measuring "story points" or whatever is probably a bad metric, like most measures of software productivity.)
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.
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
More cynically, perhaps they have experienced this but labelled the person as a non-performer.
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.
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.
Seniors are usually expected to do these things and also produce tangible artifacts. At the principle / architect level maybe you aren't producing code artifacts but you should easily be demonstrating 7+ figure impacts to the business from your efforts.
It's a great deal for Tim. He never has to work overtime to deliver something, and never has to fix bugs on stuff he built.
That said I believe the author that Tim was a huge net positive.
Too lazy to track down the exact company, but the author does link to Tim's LinkedIn. He has many titles as "Agile coach" and his lede is
>Enabling technology teams to operate at their full potential
Sounds like he is a very particular type of developer focused precisely on enabling teams in this manner.
-----
also, I can just post the obvious here but: he may be doing work but not tracking it. I've never been perfect at creating stories for every task I get, especially retroactive ones that pop up in the middle of the week.
This^^ The article depicts it like it's an either-or when in real world capable engineers can consistently do both
The team being described here was one where all work was done paired. Senior engineers were never delivering by themselves. It sounds like you have experience of teams which are not like that, which makes comparisons ineffective.
The real reason Tim showed up as having zero productivity was because he always let his pair put their name on the ticket, and so get the credit for it. This is really a story about how things go wrong when a ticket tracker designed for solo work is used by a team which pairs.
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.
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.
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?
pairing is taking stories, it’s two people working on one task together.
So then he hasn't been taking zero, "literally zero" stories like the article says.
1 reply →
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.
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.
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?
I ended up leaving, as did most of the other senior developers, so I wouldn't know the details.
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.
> 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!
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.
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.
> 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
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.
"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.
The logical conclusion to that argument is that we should do away with the lot of them.
5 replies →
>Anyway, management will of course argue that developers under them are incapable of seeing everything management does.
What a coincidence! Thats one of the first thoughts that crept into my head when code metrics started being used on me.
This "voyage of discovery" you've alluded to is exactly what I meant by no downsides.
If managers feels threatened by being measured by their employees after their employees start measuring them, well, that's also an interesting reflection is it not?
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
it's called a labor union
unions don't measure productivity. They group people based on credentials + experience, and treat everyone as interchangeable within those buckets.
6 replies →
Managers don't stay in the same role long enough to have their productivity measured.
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.
They measured by the perceived output of the team. Give them credit for being self-serving, at a minimum.
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?
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.
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.
<Ultimately the best way of measuring programmer productivity is by the assessments of the programmers on the team. >
Maybe ... Productivity itself is difficult to define. Different people will value aspects of the work differently
At one Internet Advertising company I worked for, the founder had written most of the original code. Written in the late 1990s, it was Perl, JavaScript, HTML, and SQL jumbled together. Completely ignoring the notion of 'separation of concerns'. Huge amount of code duplication. Source code control? Phhht! Nary a test in sight. Ran programs as root to work around permission problems. Self modifying code ... you betcha. He worked right on the production servers. He could and would push out a feature the same day a customer asked for it. VERY quick to make the customers happy. The company was being bought out at the time I came on board. Pocketed his millions, headed down the road, yay for him.
My own take is that the company would never have 'made it', if a software team had been hired to 'do it properly'.
After his departure, as we rewrote our code base to 'professional' standards, much time was spent refactoring that produced few or no new features. How productive was that? A very complex question.
As a digression, I sometimes found his original code easier to maintain that the stuff done 'the right way' because there WAS no 'separation of concerns'. I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
In the end, 'productivity' is way more subjective that we'd like.
> I didn't have to hunt in a different part of the source tree for where something was done. It was all 'right there'. YMMV.
This is my take too as I have gained experience. The way I did code from the get go, was the overall best way. Long function that did the stuff one thing at a time. Like no functions called from different parts of the call tree. I breeze to debug and understand or modify.
2 replies →
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.
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 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 .
Exceptions are for exceptional circumstances. An object being a certain type is not an exceptional circumstance, not even in a dynamic language. You should never be surprised by the type of an object unless your program has serious design flaws.
The fact that the language doesn't have your back means you need to be more careful about types, not less. The type of the arguments is a function precondition. It's the callee's responsibility to document preconditions and ideally recover cleanly from a violation, but the caller's responsibility to ensure preconditions are met. Illegal states should be caught early, not allowed to percolate until an exception is thrown.
I don't much care if what I just wrote is "Pythonic" or not. I don't think too much careful design up front is responsible for every Python codebase I've ever seen reading like Finnegan's Wake.
1 reply →
If you are calling something immediately, a try-except is ok. If you are calling with a try-except just to simulate hasattr or getattr then why do we have the built-ins in the first place?
1 reply →
Conventions are changing. Modern python is shifting to type checking with external type checkers.
5 replies →
So I used to kind of think like you, but I think that's just not a practical approach. Yes, you could alter the system in this 1 exact situation if you know exactly what to change, but there will be dozens of other failure modes too (engineer releases code that breaks in 2 months, engineer deliberately mis-estimates story points, engineer doesn't comment their code so that nobody else on team can do certain work, etc)
So if you have a manager who is a dialed-in coder who's going to keep updating the jira-point formula based on spending more than 1 hour a day reading code, and keep tuning it around the ever-more creative loopholes engineers employ, then yes, you may end up with a workable system. But never yet in my long career have I seen that.
No, no, you misunderstand. I agree with the point. I just think it was made against a strawman and could have been made even stronger. I'm not for metrics on stories to award productivity points. I'm for one-on-ones and success-as-a-team evaluations.
> 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.
The story includes a part where they dropped the crappy metric and changed to a better one.
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.
In almost all companies, even seeking help is frowned upon. One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Some actively don't want to help out others, due to PIP/bonus culture. At Amazon, some team members explicitly give bad advice when asked for help. That's why we have this culture of "lone rockstars", who spend a lot of time to learn without being mentored.
Seeking help isn’t the problem. It is priorities. Usually the best developers are tasked with the more impactful tasks whose deadlines must be met at all costs. As a manager, I would view my task is to shield said developer from distractions so he can save my butt because my job is also on the line.
If someone is intentionally giving bad advice, that sounds like they deserve some anytime feedback. (is that still a thing?) That is definitely not thinking like an owner.
> One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'.
Which senior manager is this, out of interest?
1 reply →
this post is really strange because it actually describes a good environment
- code isn’t changing in code review except for really good reasons
- people who need help are reaching out
- projects that need help get additional help brought in
what else are you looking for? this example is about as pair programming as it gets at most places. they’re called silos when people don’t like them and layers of abstraction otherwise but they’re the same thing: no team will have 100% shared info on all parts and knowledge transfers on exits are a decent step to bridge this
if you want to teach the team more, teach them more. usually the best way to do this is in code review. it’s direct comments on code. write a good review you want more people to see? post it in the chat. set up additional time to share ideas with the team. all of these things you can do as an IC while producing code
sorry but this post comes off as “i’m smarter than everyone.” i’m guessing the reason management hasn’t gotten your message is the message isn’t clear. what exactly do you want to do? and what do you need their help for?
I don't think code reviews are the _best_ way to teach. Because for a start, you're usually working with a complete task. Someone can have a perfectly fine pull request that implements the feature or solves the bug, but it might not be the best way of going about it.
Now, as a reviewer your spidey sense tingles and you get the feeling there's a better way. But now it's significantly more effort to pull that change apart or start from scratch and experiment with a new approach, then write this all up on the pull request with the caveat "but what you've written works, so in the interest of time we can merge this".
Pair programming would get you on the right track from the start. You are able to assist an inexperienced dev and guide them through the process step by step. Imbuing your knowledge, raising questions, suggesting fixes. This is exactly what the blog post describes. The developer was seen as unproductive because their time was spend pair programming rather than directly doing the work themselves.
I don't see how my post comes across as "I'm smarter than everyone". I know things that less experienced developers don't know, and that's a fact I know from talking to them and reviewing their code. But the culture just isn't there to be able to spend significant portions of my day effectively being their teacher (which I would love to do!). Instead it's often "the blind leading the blind" while the more senior members of the team are off delivering important projects and not having the capacity to imbue their knowledge onto the less experienced members of the team.
It's a culture thing and I wouldn't say it's a good environment for nurturing new staff. Spending 2 hours in a Teams call or at someone's desk is uncomfortable for both parties in a company that doesn't encourage this sort of collaboration. And so there's a sense to not "waste someone's time". The person you're helping sees themselves as a burden rather than seeing themselves as a student. And as a teacher, you're conscious of the other work you're supposed to deliver because it's not expected for you to be spending significant parts of your day pair programming.
2 replies →
Pair programming sounds so stressful and unproductive to me. You can't read someone's mind. Any interjections while someone is in the middle of coding can't be more than distracting noise most of the time. And I would constantly feel self conscious that I'm taking too long to write something, googling or asking Copilot stupid questions, etc. Reviewing after the programmer believes it's ready to review makes much more sense to me. Though Copilot can be very helpful as an artificial pair programmer.
The point of pair programming isn't really to be talking to someone while they are coding a known solution. It's to work through and discover a solution together to an unknown. In this sense, you're kind of both in the same headspace together, and can have a conversation without necessarily breaking focus. And I would venture that almost any question that comes up in pair programming would either come up later in code review, or could be hand-waved with "yeah, I plan to fix that with X" and move on.
The important part of pair programming isn't really the programming per se, it's the discussion.
It also requires some amount of conversational art. As for being self conscious about things, you would have poor coworkers who make you think that or some unfounded worry. A good pair programmer can have a discussion without making you feel like an idiot - much the same as a good code review.
I agree with you for a case where you are taking a feature from start to end. The case where you are spending half an hour unblocking someone who is stuck or brainstorming a better solution for something tends to be beneficial though.
I used to think the same until I was put in an environment where it was normal and where everyone was trained in pairing.
Copilot is as much a pair programmer as stack overflow is... So not at all
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.
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.
1 reply →
Apparently I am pretty lucky. My managers are explicitly asking me to help rescue a project AND get the dev who did most of the work upskilled and following some of our patterns from some other successful projects. It is hard to know whether they are actually taking my advice and changes to heart and integrating them into their knowledge base and mindset, or just accepting that they're being asked to make changes by me and doing them.
Mentorship is hard, regardless of management buy in :/
Pairing gets a lot of hate and is very misunderstood. It can be terrible, though, if the org doesn't encourage and teach it. There are also lots of things about pairing that are misunderstood, especially that things take more time.
I was on a team that paired all the time and it's sort of ruined me for anything else. We switched pairs daily and everyone would pair with everyone else (on the team). When a junior joined the team they would very quickly lose their junior status.
Have juniors plan out work first in design doc form and broken up into small deliverables. Helps to catch things early when they start down a rabbit hole.
Yes very similar. It makes me very happy when I'm called over by a junior proactively. Not mainly because I'm able to help them, the real reason is that they sensed something about the problem that needed a second pair of eyes, and they didn't waste time. That's them gaining intuition and experience and I get really happy for them.
I don't actually say it though because I don't know how to express it.
If I worked somewhere where a guy would shadow me, hover around and 'support' me that would make me quit very fast.
I feel that the article is talking about the same thing as what is described in this talk https://news.ycombinator.com/item?id=17386640
What's the metric for programmers who prevent the team from building the wrong product?
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.
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.
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.
Maybe Tim could have also added his name to the tickets as he was pairing and helping the others complete them...
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.
Certain tools (Ahem MS) don't allow more than one person to be added to a ticket
2 replies →
"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, =)
It seems like the easy solution here would be to give this guy partial credit for stories completed.
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.
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.
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.
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.
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.
I agree that firing people based on delivered story points is probably wrong. I disagree that measuring the amount of story points someone delivers has no benefits. In this case, it surfaced a very interesting dynamic in a team that apparently the company wasn't aware of, and now that it is surfaced, it can align that team better to the goals of the company. I would really wonder, for instance, how Tim was evaluated on performance, if the expectations of him didn't align with the role he was doing.
I think the part in the article where a manager wanted to fire Tim because he delivered 0 story points, and the teamlead (?) refused, is made up for dramatic effect. I can't imagine any manager seeing those type of results and instead of asking the teamlead what's going on there, jumping to the conclusion that Tim should be fired.
At the end of the day, it's all emotional and biased human beings subjectively evaluating/judging other human beings. This guy that worked with Tim believed that he added great value to the team. A manager came to a different conclusion. It's impossible for them to determine who is "correct," let alone us. Of course we can come up with all sorts of potential scenarios but it seems pointless and unfounded without first-hand knowledge of the situation. The skill of being a manager is deeply understanding the specific and individual nature of their team rather than trying to apply a more generalized "playbook."
Edit: By that I mean that I am highly skeptical of metrics used to evaluate people. It's a lazy way to make the job easy and avoid doing the hard work of getting in the trenches, gaining unquantifiable insight into what's going on, and effectively communicating that up the chain.
Of course. My point is that this exact same situation, at a different company, may have surfaced a Tim that actually should be PIPed because he wasn't doing what he was asked to do, or his contributions weren't as valuable from an objective point of view (but of course all his peers love him taking some load off and them being able to get all the credit), or he was forcing a team dynamic that should be "fixed" because Tim is actually a Brent (from Phoenix Project) that had to have his hand in everything and the team couldn't survive without him, yet it may be difficult to discern these situations from the situation described in the article where Tim (sounds like) he was definitely bringing more value to the team than a replacement would.
Yeah it's a few hypotheticals onwards, and there's probably better ways to surface those problems, but companies are messy and no one is without flaw or 100% competent, no engineer and no manager.
(Note that I'm not saying evaluating a person based on delivering story points is optimal, or even useful)
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.
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.
Definitely cultural. I have been watching engine teardown videos. The difference between the Japanese motors and American motors is stark if you know what to look for. Engineers were clearly in charge of designing every aspect of the Japanese motors. American engines have so many compromises and they flip-flop on internal parts and designs, that look whilly-nilly in comparison.
It's obviously cost cutting niggling and get-it-out-the-door histrionics causing this chaos. There is significant impact to longevity and durability, and required maintenance. Very wasteful from a global warming perspective.
Watch out for these late model ICE engines...do your research. If it's "newly redesigned!" step back and dig in.
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?).
2 replies →
Scrum and story points I agree with, but unit tests? You'll have to pry those out of my cold, dead hands!
1 reply →
Management doesn’t always know what they are building is correct.
They are going to manage risk of low quality with risk of wrong product.
If management doesn't understand what is being built, maybe they are not fit to be a manager?
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.
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.
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.
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.
"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...
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.
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.
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.
> 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
You say that but even in this thread you have tons of people claiming he was actually a bad programmer precisely because he wasn't also shipping code.
Yes it's a bad metric but so many engineers (not just managers) fail to understand that.
> 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.
Bad managers who want to control instead of empower are the bane of this industry.
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
> worse manager who followed it blindly
And apparently has zero idea of the team's internal working patterns.
It's entirely possible that the subject of the article is a terrible programmer, if he were to sit down and write or maintain something as an individual contributor.
I've worked with people like that, who were pretty bad individually, but brilliant when part of the right team.
Writing code and directly enabling the productivity of others who are writing code are different skillsets.
Obviously there's some overlap, but you're most productive in Tim's role in you're complimenting the skillset of the person writing the code.
> Pretty clickbaity title.
Good. I hope it made you read the article and learn from it.
[flagged]
2 replies →
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.
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.
Having this person help others 100% of the time likely is not the best use of his time.
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?
There’s a very good blog that explains Tim: Being glue. I highly recommend all leadership read it.
https://noidea.dog/glue
"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.
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.
> 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".
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.
> Very senior dev: ... that should take about an hour.
Red flag!
6 replies →
> I'd expect exceptional programmers to do unusually well on most metrics.
Not if they game the metrics, as a way to force change.
A classic example of an exceptional programmer doing worse on a (bad) metric is at https://www.folklore.org/StoryView.py?story=Negative_2000_Li... , titled "-2000 Lines Of Code".
"Some of the managers decided that it would be a good idea to track the progress of each individual engineer in terms of the amount of code that they wrote from week to week. ... Bill Atkinson ... thought that lines of code was a silly measure of software productivity. ... [He] made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code. ... when it was time to fill out the management form ... he thought about it for a second, and then wrote in the number: -2000. ... after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied."
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.
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.
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
As half of the pair programming team, why not just give him half of the story points?
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.
This worst programmer sounds eerily similar to the best one (from the Twitter thread).
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.
"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!
clearly, Tim is a coach/mentor in this team, try to measure his work a wrong way ?
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
I have struggled to find work my entire life, but people like this get jobs. I hate life
You live in a different country probably.
Or, the past isn't the present. It was very difficult to get a job in the US in 2008 and now it's easy because it's 2023. (slightly harder for some kinds of tech)
That person manages to stay because he plays political games correctly.
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.
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.
Unfortunately, I have seen many of these types of people pass by management. The worst ones are the ones who do play political games correctly because they’re the ones who either get away with it at the very least or worse, make the talented engineers want to leave. Basically, the latter can completely destroy good teams.
Yup, I’ve seen many people like this in engineering. They “put all their skill points” into Charisma. Then they go on to build long, prosperous careers by bullshitting and charming senior management, until they themselves are promoted to senior management. It is a reliable, proven career progression for the incompetent.
They need to fire his manager first and then assess this guys capabilities. Maybe he is not guided enough. Maybe he is plain stupid. Full responsibility of his manager.
Bad management
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.
> 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.
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.
6 replies →
And if there’s pairing on a sub-task…?
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.
Tim thinks it's awesome: https://twitter.com/iterex/status/1697927494479777844
Annoyed? I’d love it: it would be an incredible door opener anywhere you went.
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.
1 reply →
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.
10 replies →
Interesting way to prevent your awesome colleague from being poached by competitors.
My thoughts too. Sucks for him.
[dead]
[dead]
[dead]
[dead]
> 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.
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.
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.
I've worked with several types of people. For me, the best mentors were the ones who would answer questions I had with the full answer, often with details. Then they got on with what they were doing while I went back to my desk and tried to understand/retain some of what they told me.
I'd personally find someone shadowing me and asking questions super annoying.
I don't think this would work with all teams, the takeaway I got from the article is about artificial metrics.
> 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.
4 replies →
>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.
[dead]
[flagged]
[flagged]
[flagged]
We detached this subthread from https://news.ycombinator.com/item?id=37363109.
Yes, that is what was written. Would you like to say something about it?
[flagged]
10 replies →
[flagged]
"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.
[flagged]