[HN Gopher] The Worst Programmer I Know (2023)
___________________________________________________________________
The Worst Programmer I Know (2023)
Author : rbanffy
Score : 299 points
Date : 2025-03-23 13:08 UTC (9 hours ago)
(HTM) web link (dannorth.net)
(TXT) w3m dump (dannorth.net)
| franktankbank wrote:
| Sounds like Tim was the manager. What exactly was the paid for
| manager doing?
| bluGill wrote:
| There are different types of managers. I'd use the term
| technical lead for tim. Someone needs to maneage product
| delivery. Someone needs to manage the backlog. Someone needs to
| manage the training of everyone. Someone needs to ensure people
| are getting setup for their next job. Someone needs to ensure
| everyone is paid right. Someone needs to handle it when two
| people don't get along. The above is a small subset of the full
| list - I don't know everything on the full list.
| franktankbank wrote:
| Not to be a total fucking asshole... but:
|
| > Someone needs to manage product delivery:
|
| You mean the 2-week delivery cycle into an automated CI/CD?
| Good lord I hope they don't have a useless scrum master too.
|
| > Someone needs to manage the backlog:
|
| I'm curious what input the manager has into this besides
| reading through a list of engineer curated items.
|
| > Someone needs to manage the training of everyone:
|
| Tim seems to be handling that.
|
| > Someone needs to ensure people are getting setup for their
| next job:
|
| Tim seems to be handling that.
|
| > Someone needs to ensure everyone is paid right:
|
| HR has but one fuckin job as far as I can tell.
|
| > Someone needs to handle it when two people don't get along:
|
| Hey Tim can you id the asshole? How comfortable are you
| hiring/firing?
|
| Obviously IME non-technical management has done nothing but
| played politics and prevented firing of shitheads who were
| wrongly hired.
| throwanem wrote:
| > HR has but one fuckin job as far as I can tell.
|
| Yes. Protecting the company. As long as anyone's paycheck
| doesn't have a slur actually written on it, that's roughly
| where HR's interest ends in the matter.
|
| Don't feel too called out. If I thought you were wrong on
| anything else here, I would say so.
| dahart wrote:
| Do you have experience being a tech lead and/or a manager?
| Tech leads and people managers are two explicitly different
| roles in many organizations, for good reasons, including,
| but not limited to them being both full time jobs. It
| certainly depends on the company and the size of the team
| and other things, but many many tech leads are not at all
| comfortable hiring & firing, nor with interviewing and
| prioritizing work and product managing and meeting with
| management and approving time off requests and dealing with
| complaints and deciding raises and promotions and dealing
| with equipment and managing budgets... the degree to which
| you're downplaying these roles is what leads me to have to
| assume you might not know what's really involved.
| franktankbank wrote:
| Man that is a whole lot of fluff to differentiate between
| being able to hire and fire. I wonder what Tim would do.
| dahart wrote:
| So your mind is made up that someone fictional who is not
| described in a blog post does not contribute to an org
| you know nothing about? Is your point that all management
| is useless? Or something else? And why are you certain,
| what is your experience running a team or a company?
| Maybe the sarcasm isn't communicating your point
| effectively?
| simonw wrote:
| _Instead he would spend his day pairing with different
| teammates. With less experienced developers he would patiently
| let them drive whilst nudging them towards a solution._
|
| That's not a management activity - that's the kind of coaching
| you would expect from a senior IC ("Individual Contributor" - I
| still hate that term.)
|
| Generally I would expect a "manager" to have authority over
| other people in the company: run performance reviews, handle
| promotions and hiring and firing.
|
| I think it's important for companies to provide a career
| structure that allows for influence, decision making and
| leadership roles that don't also require taking on those
| management tasks. Management tasks are extremely time consuming
| and require a substantially different set of skills from being
| a great team coach or force multiplier like Tim in the story.
| jprosevear wrote:
| I would agree, but the manager probably should be in touch
| enough that they could see the teaming behaviour themselves.
| llamaboy wrote:
| They did... that's the whole premise of the article
| Izkata wrote:
| A lot of people seem to have zeroed in on "the manager's
| decision" and completely missed that it referred to the
| department manager, not the team manager, and the story
| is told from the perspective of the team manager.
| franktankbank wrote:
| I can't quite tell what the manager in this story should have
| been doing though. Where is their value add? If its just MBA
| fluff playing psycho games with metrics then I'd argue they
| can get fucked.
| bee_rider wrote:
| It could be a big company. There might be some layers of
| C-levels, the a layer of managers to listen to them and
| turn their commands into concrete things, and then a couple
| crumple-zone layers of management to make sure that the
| concrete bricks from the top don't damage actual
| productivity when they hit.
| spiderfarmer wrote:
| Clearly performing another under appreciated task: to act as a
| buffer for Tim, allowing the team to flourish even when they
| don't adhere to company policy. And all other managerial stuff
| apart from coaching.
| sehyun wrote:
| Discussion 2 years ago:
| https://news.ycombinator.com/item?id=37361947
| croes wrote:
| So the real metric is the manager who knows their team and what
| each member brings in.
| peterldowns wrote:
| Yes, absolutely -- and can effectively communicate that to
| _their_ manager.
| JohnMakin wrote:
| Used to be bitten by stuff like this until I figured out
| something Tim and this author apparently didn't - the problem is
| trivially fixed by management by attaching tim's name to any
| tickets he may have helped out on. he can ask his teammates to do
| this and they gladly will, or, nice teammates will usually throw
| a "figured this out with the help of @Tim" in the ticket. goes a
| long way to keep "tim" on your team against obtuse velocity
| metrics like this.
|
| productivity metrics aren't entirely worthless. if I come into a
| team, for instance, and I see they have 1 PR mapped to roughly
| every 1 jira ticket, and I see a guy on a 3 person team that's
| got 70% of the PR's in a year, that isn't a clueless piece of
| info. he's probably the lead. not always, and people game stuff
| like this, but it is a data point you can make note of.
| Clubber wrote:
| You're absolutely right, but some people just refuse to play
| silly games. It's odd that the manager isn't ever in the room
| with the team and doesn't understand his team's dynamics.
| Giving the benefit of the doubt, he must have been new, but any
| manager worth his salt will ask people on their team what the
| team dynamics are.
| BigGreenJorts wrote:
| My understanding is that metricizing like this is a tangible
| way for managers to defend "underperforming" team members to
| upper management. Your manager can always _say_ you 're a
| valuable member of the team and that will certainly go quite
| a way, but it's even more powerful if your manager can say,
| XYZ is an I valuable team member, if you need evidence of
| that, they provide a lot of value in supportive roles like on
| these tickets. [Listing tickets].
| throwaway7783 wrote:
| Agree on silly games, but this is simply acknowledging
| others' contributions. I think this should be encouraged in
| general, metrics or not
| Clubber wrote:
| I agree. I think it's pretty absurd that the manager was
| all set to fire him just based on metrics. There's a quote
| that I'm going to horribly paraphrase that goes like, "when
| you can measure something, that ends up being the only
| thing that matters."
|
| At least he asked the author his opinion first.
|
| Having said all that, if he took it upon himself to be a
| mentor to other developers and didn't do any tickets
| himself, that seems a bit odd, unless it was explicitly
| decided/communicated that would be his role. I would think
| roles like that are half time mentoring and half time doing
| tickets, but I don't know enough about the team to judge
| it. Like I said, I'm assuming the manager was new to the
| team.
| motorest wrote:
| > the problem is trivially fixed by management by attaching
| tim's name to any tickets he may have helped out on.
|
| I don't think this comes even close to solving the problem.
| This in fact makes the problem worse, because a) you admit the
| metric is shit and does not reflect work, b) you opt to keep
| the bullshit metric but instead try to manipulate it to bump
| the score under some scenario. That's not desirable outcome by
| any metric.
|
| In the end you're building up a system where everyone
| participating in it knows it's a fraude but just keep gaming it
| because they become too heavily invested in it.
| throwaway7783 wrote:
| While a number measuring productivity may not work, I read
| the GP as simply recording contributions.
|
| I like that approach. Now you can not only have peer
| recommendations, but also tangible records.
| bberenberg wrote:
| I don't think anyone is saying it's a good solution. It's one
| amongst many bad ones that are used because that's what we
| have. For example, I've been running a remote team for 8ish
| years now and I keep begging people to have conversations in
| public channels. One of the reasons is to see who's spending
| a lot of time lending a hand. Guess what, devs refuse to do
| that. So what am I supposed to do?
|
| I have a person who I highly suspect isn't doing much work,
| and is basically rotating through other team members to help
| him get unstuck. Not a bad guy, but probably not up to our
| standards. Just ask people you say? Many cultures don't allow
| for someone to say bad things about their coworker even if it
| would help to improve the team.
|
| I'm not arguing for any one solution because I don't know of
| any magical solution. If you have better metrics or
| management skills than what everyone in the world has figured
| out, myself and many others would gladly adopt these
| approaches.
| whatshisface wrote:
| It sounds like your employees believe that talking to you
| or amongst each other, where you can read it, will get
| their friends laid off or bad decisions made without
| advice. You might want to put a layer of management between
| you and them, if you can find someone with the skill of
| trust and relationship building.
| hansmayer wrote:
| I think a competent technical lead would do wonders in
| this case too ;)
| metric10 wrote:
| Sounds like both a lack of trust and communication between
| you and the team.
|
| > If you have better metrics or management skills than what
| everyone in the world has figured out, myself and many
| others would gladly adopt these approaches.
|
| Oh boy...
|
| edit: One issue might be they fear that bad news will lead
| to a knee jerk reaction that gets them or their teammates
| fired. They should feel comfortable to encounter problems
| and openly discuss them in the open with out fear of
| repercussions. In fact, I would argue this is one of the
| major advantages of a team; pooling collective knowledge
| and abilities. If people fear honest communication then the
| performance of the team is impacted. The manager has the
| greatest ability to fix this, IMHO...
| bonesss wrote:
| > "I keep begging people to have conversations in public
| channels... Guess what, devs refuse to do that."
|
| So, stop begging. Managerial directives come as orders, not
| pretty-please requests. Also, stop letting your
| subordinates refuse you. They are your reports, you are
| approving their money, that can change if they aren't doing
| their jobs. Fire one for ignoring policy, and their
| attitudes will change.
|
| On the tech side, clarify that you want all project comms
| logged and searchable for onboarding and auto-generating
| documentation as well as identifying technical hotspots
| where investments in refactoring can save the team time.
| Whatever. What gets measured gets done, if you are trying
| to spy on everyone, this is a bad way. Do it if it has
| value.
|
| > "Many cultures don't allow for someone to say bad things
| about their coworker"
|
| Managers in any culture, and especially across cultures,
| are tasked with learning those cultural sensitivities and
| then working around them pragmatically. You have identified
| a problem. That is the start of solutions, not the end of
| them.
|
| > "If you have better metrics or management skills than
| what everyone in the world has figured out"
|
| This kind of attitude isn't productive at finding genuine
| answers, and might be obfuscating the problem.
|
| Lots of people have figured out better metrics and
| management skills than the local application suggests. It's
| not the advanced esoteric stuff that is missing, it's the
| basics.
| riehwvfbk wrote:
| With this attitude you will grow a very specific kind of
| team. They will be very productive according to your
| metrics, fiercely loyal, and lethal to anyone who doesn't
| fit in. However, $diety help you if you ever need to
| innovate.
| ModernMech wrote:
| > Fire one for ignoring policy, and their attitudes will
| change.
|
| Yeah, the next day they'll start updating their resumes
| and sending out feelers to their network.
| rvba wrote:
| It's sad that you get downvoted for providing solutions.
| marcosdumay wrote:
| Formalizing a productivity metric won't help you with any
| of that. And I'm sure that one guy you mentioned will learn
| to game the metric faster than the other developers will
| learn to fit it.
| bornfreddy wrote:
| No offense, but it sounds like you have jumped to a
| conclusion (which you can't even prove) and are trying to
| change the process so that you could nail the poor guy.
|
| What is your purpose? Making the team perform great, I
| hope. Will you achieve that by picking on someone? Hell no.
| Others will protect him, because they know they will be
| next in line. Do you think the "underperformer" (if he
| really is that, even) is doing that because he is lazy? It
| is more difficult to ask for help all the time than just to
| do something.
|
| How about you try to find a way to help him achieve the
| level that others are at? THAT is what should be your goal.
| Instead of spying on them, award team members who help
| others, so that they won't feel the need to hide. And make
| weak members feel safe. Currently it sounds like the
| environment is pretty toxic with regards to admitting to
| any problems.
|
| If, after all the genuine effort, you still fail and need
| to let go of the guy, because he is really bringing
| productivity of the team down and you can't motivate him to
| change, then you should know that this is still primarily
| your own failure. Which is ok, everyone is allowed to fail
| from time to time. But it is a signal that you should try
| harder.
|
| (speaking as someone who had to let someone go because I
| wasn't good enough to make them better... on two separate
| occasions... so I'm not judging)
| hansmayer wrote:
| First off - please do not be offended by the following
| comment, there is zero bad intent in it and is only meant
| as a way of nudging you into a correct mindset about the
| problem you described. Based on your public profile, you
| seem to not have much in the way of hands-on technical
| background and I suspect you manage your team based on some
| set of scrum/agile techniques. It can work purely for
| project delivery I suppose. However for the deeper analysis
| of your team productivity, the problem is you don't have
| the necessary competence to validate your suspicion about
| one of them not getting work done, coasting off of others
| etc. There is only two ways to go about it. Either you hire
| (or promote) a technical lead in your team, who can then
| actually make that call, or you learn programming yourself,
| accrue at least a year of real technical experience and
| then try to evaluate. I am saying this because I have seen
| people with background similar to yours usually struggle,
| because they try to infer something about engineer
| productivity based on various proxy measures, such as who
| talks the most in the chat, who has most commits or even
| based on activity in Confluence. The way I would recommend
| any scrum master/PO/agile coach/MBA to think this dilemma
| is: you would not be able to judge the quality of work of a
| medical doctor, lawyer or a mechanical engineer, without
| having a similar background, experience and competence. So
| what makes you think you can evaluate software engineers
| without the same preconditions?
| bberenberg wrote:
| I think lots of the other comments are making wild
| assumptions leading to responses that don't align with
| reality. Yours is actually the absolutely correct one. I
| agree with the solution wholeheartedly. The only
| difference is I have been trying to promote the tech lead
| from within vs hiring externally. I want the team to know
| that we value their contributions and that we're going to
| do everything we can to promote internally. I have
| various challenges with this internally related to
| seniority, language skills, etc but I'm working to
| resolve that.
|
| But in the meantime, I still have a team to manage.
| rvba wrote:
| One of the members of the team is barely doing anything
| and survives by constantly asking others to help with
| doing the job. This reducea productivity of other
| employees.
|
| A known archetype in many jobs, not only programming.
|
| Yet we get comments like this:
|
| > you don't have the necessary competence to validate
| your suspicion about one of them not getting work done,
| coasting off of others
|
| Wow.
|
| In any other job, a manager ir HR will just read your
| chats, emails + demand to document calls - and guess
| what. It can be found. In a very not very subtle way.
|
| Also the problem above is like managememt 101? For all
| the talk about "no technical competence" you dont seem to
| have any managerial competence.
|
| Also the agile idea that developers keep each other to
| professional standars is a nice fairy tale (like whole
| agile in general).
| hnlmorg wrote:
| I have managed a team in an organisation that used Jira
| heavily to measure velocity and having all contributors
| record time on tickets, even if they were just supporting,
| did actually help lots:
|
| 1. It allows for more accurate estimations (ie this is not a
| multi-day task but it is a multi-person task)
|
| 2. It showed where knowledge transferring was happing
|
| 3. It showed that people were busy so that it meant we were
| making accurate estimates to begin with.
|
| I do think Agile can get overly prescriptive. But if you do
| happen to work in a company that operates that way, pushing
| back might be impossible. So having multiple participants
| record their effort against the same ticket then allows a
| more organic way for the team to operate despite the rigid
| structure of a stricter scrum dynamic.
|
| Or in other words: sometimes you cannot change the system
| entirely so you're next best option is to tweak it so it at
| least better works for you. And that's what the GPs suggest
| achieves.
| Izkata wrote:
| More like bug/case tracking is crap. All the ones I've ever
| used only support one assignee, so even in equal pair
| programming you have to choose who officially gets the case.
|
| They're suggesting working around the case tracker, not
| around the metric.
| cyberax wrote:
| > This in fact makes the problem worse, because a) you admit
| the metric is shit and does not reflect work
|
| It's just like in physics: "all models are wrong, some are
| useful". All metrics are wrong, but some are useful when they
| are correctly applied.
| TZubiri wrote:
| In a company or any business you need to deliver something,
| if you are being paid X amount of money, the payer needs to
| know they are getting something in return, and it's not a
| management problem that they ask what was done this week.
| JTbane wrote:
| That doesn't work with automated metrics, whomever is assigned
| the work item gets all the points.
| dedup wrote:
| That's how you get individuals who insist that you attach their
| name to your ticket (or better yet, do it themselves) after
| they helpfully inform you about an automated test failure in
| your commit. "Relentlessly mentoring team members on culture of
| quality" et cetera.
| compiler-guy wrote:
| Exactly. If you don't consider how people might game the
| system, you are in trouble. Little fixes like this open other
| possibilities for gamesmanship and now people fight over
| whether their contribution was good enough to be included in
| the ticket.
| ryandrake wrote:
| I'm actually shocked that Tim, himself, knowing the metric
| exists and was going to be used in firing decisions, did not
| attach himself to all these tickets in the first place. Talk
| about a lack of self-preservation. Everywhere I've seen that
| measures performance by some metric, everyone instinctively
| tries to pump that metric all by themselves. No other
| motivation required.
| neilv wrote:
| Not _everyone_ will play the metrics games.
|
| Some people will just find the metrics dumb and depressing,
| and avoid them. (As might've happened in the article.)
|
| Some assume it will go away in time, or that their manager
| will cover for them. (As eventually happened in the article.)
|
| Some have behind-the-scenes talks with managers+execs+HR, to
| end bad metrics.
|
| Some will melt the metrics with the intensity of their look
| of disapproval. (Management ProTip: this level of will is
| better harnessed to solve business and engineering problems.)
| ModernMech wrote:
| Yup, I didn't play the metrics game, and I got burned
| because my metrics don't look as good against the co-worker
| who plays the game. The cost is having to remind everyone
| how much work you actually get done and how much you
| actually support the team when those "your metrics tell us
| you're not doing enough" talks come up.
| ryandrake wrote:
| I've resigned myself to the reality that every employer
| is basically the same in this regard. You need to be
| spending 25-50% of your time doing your actual work and
| 50-75% of the time doing all that political and self-
| promotion and metrics-chasing work so that you can "show
| your impact" or whatever the hell your company calls it.
| This has been the case at literally every job I've ever
| had. If you just go in as an expert and do the technical
| work you were hired to do 100%, you're going to have a
| bad time career-wise.
| ninalanyon wrote:
| > every employer is basically the same in this regard.
|
| This really isn't true. At least it's not true of
| companies I have worked for in Europe.
| hyperhello wrote:
| Tim probably realizes that if he tries to get on tickets he's
| helped with, he'll probably end up on maybe 30-50%. If he
| never asks for credit, and yet is seen constantly working,
| people will inflate the zero to hallucinatory levels of
| productivity.
| jofer wrote:
| That's a very personality and culture related phenomenon. A
| lot of folks will, but also a lot of folks won't.
|
| Pointedly not playing the game when you have the political
| power to do so is often the most effective way to point out
| issues in the system that folks are being evaluated under. It
| can be a very wise move in some cases, as well.
| franktankbank wrote:
| Play the game and any number of management fuckends will prop
| themselves upon your shoulder. Unless youre into that sort of
| thing.. no judgment..
| mrweasel wrote:
| That's an intersting point. I don't recall ever seeing a
| ticketing system where you could assign a ticket to multiple
| people.
| dedup wrote:
| In one of the systems I worked with each ticket had an
| "assignee" (who did most of the work), a "tech lead" (who
| knew what's going on and could provide status and guidance),
| and an "executive owner" (the person you'd escalate to if
| needed). I suspect those were custom fields and schema could
| be extended further if desired.
| MarcusE1W wrote:
| In football you track not only the goal scorers but also the
| assist (the person who passed the ball to he goal scorer). That
| still does not cover all contributions, but maybe that's a way
| to create more transparency for Tims case ?
| TheRealPomax wrote:
| Both "trivially" and "fixed" are doing an incredible amount of
| heavy lifting here.
| eckesicle wrote:
| These sort of stories seem to be dime a dozen and weirdly
| celebrated around HN and the software engineering community.
|
| We're told of the hero, who goes against their managers and
| executives and doesn't deliver any stories as agreed in sprints.
|
| We're told of the engineer who isn't hired by Google because he
| can't invert a binary tree. Everyone else piles on and decree
| that, yes indeed, you cannot measure developer efficiency with a
| Leetcode or whiteboard problem. We're too good for that. Another
| engineer chimes in: "I don't test my candidates. The best people
| I worked with were hired over a beer and a chat at the local pub"
|
| We're told of the MBAs who destroy the organisation, by
| introducing evil metrics, and how that the work we do are
| immeasurable and that the PHBs don't understand how great we are.
| 10x engineers aren't a real thing, everyone is equally productive
| in our digital utopia.
|
| Meanwhile in the real world, hordes of awful engineers deliver no
| story points, because they in fact, do nothing and only waste
| time and lowers morale.
|
| Meanwhile in the real world, each job opportunity has thousands
| of applicants who can barely write a for loop. Leetcode and
| whiteboards filter these people out effectively every day.
|
| Meanwhile in the real world, metrics on delivery, features and
| bugs drive company growth and success for those companies that
| employ them.
|
| To me, all these heroes, and above process people, just strike me
| as difficult to work with narcissists who are poor at
| communication. We are not special, and we do not sit above every
| other department in our organisation.
| mjburgess wrote:
| People of a revolutionary (or "innovative") temperament are
| those who are going to say, "this system doesnt work, these
| processes are broken, the wrong outcomes arise" and ignore
| them. In doing so they just "do the right thing" in their
| judgement, and in so doing, develop the next iteration on the
| processes that others will follow.
|
| If these innovators are operating in a niche where innovation
| is required, they are solving different problems than most
| others and have different self-defined standards
| ("narcissism"), and so on.
|
| Probably many people who visit HN have this temperament, and a
| significant number are in niches which need to evolve this way
| (eg., this applies to _all_ startups). HN is a small sample of
| engineers: most don 't go to websites to conceptualise their
| own activity, reflect, etc. These are indications of people
| with a desire to innovate, or to solve novel problems in their
| profession.
|
| If you are in a highly stable environment, with effective
| processes, etc. then people of this temperament can be trouble
| if left entirely to their own devices: good managmenet would
| place them in projects/areas where there is some unknown
| unknowns to figure out.
|
| In many cases however, people without this temperament (say,
| "it works, dont break it, conservatives") find this behaviour
| unsettling, arrogant, disruptive, isolating -- because it is.
| There isn't any thing to "communicate" when you havent figured
| out what the solution is -- you can air your thought process
| every day, but that will just unsettle more people when they
| see how much it changes (in response to more thkning,
| information, etc.). And the values by which this change takes
| place are not conservative, they're radical and imposed by a
| person who sees a route out of a predicament and so on. It's
| quite arrogant to place yourself in that position, or think
| it's yours by some invisible duty that no one else has.
|
| In any case, if you operate in this niche, esp. eg., if you're
| in a start up environment -- then you arent going to care a jot
| about this "real world". They are acting against the real
| world, to improve it.
| eckesicle wrote:
| Thanks for responding. I see your point, but I think it is
| responding to something slightly different than the point I
| was making.
|
| If I may latch on to your first paragraph, my point is that
| we are saying this first bit "this system is broken" and are
| happy to throw out the baby with the bath water and tear it
| all apart, on flimsy evidence and generalisations.
|
| And yes, there's definitely something to be said about the HN
| crowd having a temperament toward innovation, but I don't
| think that's in any way orthogonal to my point. In fact, this
| community is far more rational than most others, so I would
| sort of expect us to rationally look at company processes
| too, but for some reason we seem to have a blind spot when it
| comes to our managers and executives and the 'horrors and
| hoops' they make us jump through every day.
| cratermoon wrote:
| https://www.folklore.org/Negative_2000_Lines_Of_Code.html
| Kamq wrote:
| So on one hand, you're kinda right. HN is filled with
| exaggeration (imo often justified) from people venting because
| they have to deal with the bad parts of this system all day.
| That seems natural in a dev filled space.
|
| But I don't think your comment is fair.
|
| > We're told of the engineer who isn't hired by Google because
| he can't invert a binary tree. Everyone else piles on and
| decree that, yes indeed, you cannot measure developer
| efficiency with a Leetcode or whiteboard problem.
|
| Because this _is_ a bad way to judge engineers. Or, rather, it
| 's a great way if they don't know how to invert a binary tree.
| Most of the job is to figure out something you don't know yet
| and do it. Giving an engineer a random wikipedia page on an
| obscure algorithm and having them implement it is a great
| interview tactic. Having them regurgitate something common is
| bad, there will be a function for it somewhere, and you just
| need to call it.
|
| > Meanwhile in the real world, hordes of awful engineers
| deliver no story points, because they in fact, do nothing and
| only waste time and lowers morale.
|
| I agree with you on this one. Those people need to be fired.
| That doesn't mean story points are a good metric, often 90% of
| long term value can come from the kind of people who are like
| Tim, and losing them _can_ destroy projects. Just because
| something bad is happening, it doesn 't justify killing 90% of
| value for a team.
|
| The only thing I've seen that works is to give team managers
| more discretion and rigorously fire managers who regularly
| create poor preforming teams (you often have to bump manager
| pay for this, that's fine, good managers are worth their weight
| in gold).
|
| > Meanwhile in the real world, each job opportunity has
| thousands of applicants who can barely write a for loop.
| Leetcode and whiteboards filter these people out effectively
| every day.
|
| You do need to filter for people that can code. That doesn't
| mean filtering for inverting binary trees is a good idea.
| Having people submit code samples that they're proud of is a
| much better approach for a first filter.
|
| > Meanwhile in the real world, metrics on delivery, features
| and bugs drive company growth and success for those companies
| that employ them.
|
| Bullshit. Basically all companies use metrics, and most
| companies are garbage at delivering useful software. A company
| being years behind and a million over budget on a software
| project, and eventually delivering something people don't want
| is so cliche that it's expected. And these companies regularly
| get out competed by small teams using 1% of the resources, as
| long as the small teams give half of a shit. In fact, if you
| want my metric for team success, what percentage of the team
| actually cares is a good one.
|
| You're proposing a solution with a <20% success rate. Don't act
| like it's a gold standard that drives business value to new
| heights. With the system as it is today, most companies would
| be better off getting out of software and having a third party
| do it for them.
| eckesicle wrote:
| My wider point is not that the way companies are run is
| perfect and that we should stop the "innovators" (to quote
| the sibling comment). Each of these examples speak of
| corporate dysfunction, but we never give any weight to the
| constraints that force them in place. Leetcode is bad, but
| it's bad in the sense that it errs too heavily on filtering
| out false negatives - the cheaper of the two errors. The
| alternative is worse.
|
| Giving Tim the benefit of the doubt in this story, it still
| holds true that for every extraordinary and invisible
| superstar like Tim there are 99 under-performers who are
| indistinguishable from him.
|
| We need to empathise with our managers and the processes in
| our organisations to understand their purpose and how they
| came to be.
|
| We, software engineers, keep picking out singular data points
| of evidence to point at a flawed and unfair world, that go
| against our self inflated egos.
|
| The brew guy inverting the binary tree and Tim being great,
| does not invalidate the practices of whiteboards and story
| points as a general practice.
|
| To your final point, the best organisations that I've worked
| with used metrics in a very effective way (mostly in start
| ups). The worst did too. Just because some do it poorly, does
| not mean that it's bad across the board.
|
| What is tiring, is the unfair, and low expectation of the
| quality of evidence demanded of the anti-establishment
| notions in software development, before they are taken as
| gospel by this community.
|
| And, in my experience, the people who are the strongest
| proponents of sidestepping or dismantling these processes
| overlap strongly with those who also do not deliver value to
| their teams.
| add-sub-mul-div wrote:
| > We're told of the hero, who goes against their managers and
| executives and doesn't deliver any stories
|
| > Meanwhile in the real world, hordes of awful engineers
| deliver no story points
|
| Do you think the point here is that not delivering on one
| specific metric is a good thing, or that not delivering one
| specific metric can't be assumed to be the whole picture?
| eckesicle wrote:
| It's the latter, but my point is that's a tired and weak
| argument to make.
|
| The blog poster could've asked, why does the manager want me
| to deliver the story points? It's because Jake is also
| delivering zero story points and he's a terrible engineer and
| it's a good canary metric.
| MichaelRo wrote:
| >> To me, all these heroes, and above process people, just
| strike me as difficult to work with narcissists who are poor at
| communication. We are not special, and we do not sit above
| every other department in our organisation.
|
| Exactly.
|
| Looks to me like Tim was really good at hiding his incompetence
| behind other people's backs. Also looks like a problem of the
| others, particularly senior others of not telling him "Fuck
| off, Timmy" when he sat uninvited beside them to "pair program"
| together.
| bsindcatr wrote:
| Some things that don't measure whether a developer is "good":
|
| - # LoC added, changed, removed
|
| - number of points earned in a sprint, when those points aren't
| quantitatively indicative of business value, and they never are
|
| - number of on or off-the-clock hours schmoozing with others to
| solidify relationships with the business and "play the game"
|
| - number of times they "sound like good developers / intelligent
| people" in meetings or presentations
|
| - number of weeks they spent on really complex problems they
| worked to solve when they could have provided more incremental
| value earlier much more quickly
|
| - number of solutions they provided the company quickly while
| leaving many times more LoC to maintain
|
| - number of hours they spent honing code, formatting, updating to
| the latest versions but doing so for their own edification and
| preferences rather than focusing on the team and the business and
| what would help them
|
| and so many more...
| mjburgess wrote:
| I've had some thoughts on programming practice somewhat related
| to Tim's role, and some on language design this morning.
|
| I write code for others to read a lot, to explicitly teach them
| how to do something. This code has always been overly verbose,
| "decompressed" and teaches people the thought process behind a
| solution above being a "neat" solution. I was dragged a little
| reluctantly into this style, by being forced to anticipate all
| the ways the code may be misunderstood ahead of time -- by all
| the ways it was misunderstood previously. Its much less work for
| me to be verbose up-front, than fix misunderstandings later.
|
| After watching and looking at some of the best systems
| programming code/coders -- I've come to think this is just the
| best way to program in general.
|
| The latest program I wrote this way, and the quality of code is
| vastly higher. No abbreviations, any unusual coding practice
| (eg., conditional imports, using classes as namespaces rather
| than object templates, etc.) I noted briefly in comments to
| highlight it's unexpected. Any functions which are domain/app-
| specific have execessively long names which fully describe that
| step/asepct of the solution. Extensive design comments where my
| thinking is noted. etc.
|
| Programs which teach their readers how to think about the
| solution, rather than how to understand the code -- and teach it
| to a "smart junior" rather than to an expert. I think this is
| different than literate programming, and of the maxim "code is
| read more than written" -- it's a specific "educational ethic":
| code isnt clean, or literate, or readable -- its educational.
|
| If this is the best way for "programming in the large", then a
| property of programming languages follows: languages which enable
| the programmer to "decompress" their thoughts over many lines are
| preferable to ones which hinder this. This I think then explains
| something about the uptake of functional languages -- which
| resist this decompression of thoughts over lines of code. They
| are often sold on their conciseness -- as if a 200 line C++ ought
| be reduced to a 10 line F# program. This trades the wrong sort of
| productivity: long-lived large programs require programmers to
| build mental models of them far more often than they require them
| to add to them at-scale. A programmer self-teaches the code base
| more often than they write it: this isnt about reading.
|
| This goes somewhat to the role of Tim in OP. Perhaps the right
| software engineering programming practice is to write code as-if
| you are pairing with a new programmer in the future. To verbalise
| everything Tim would say, already, in the code.
| failrate wrote:
| The worst programmer I know literally could not go a day without
| either checking in code that did not compile or saying something
| creepy and sexual in a large open plan office, and we all worked
| together to get them fired.
| SJC_Hacker wrote:
| The first problem can be fixed by CI/CD, and proper branching
| strategies. Each IC should have their own branch, then PR into
| appropriate branch
|
| Have no idea on the second, other than a visit from HR.
| decGetAc wrote:
| How did the manager not know Tim didn't have tickets slated for
| him ? How did Tim not even pick up some (at a lower capacity) and
| then still helped with the remaining time ?
|
| I guess as someone who does a lot of the same that Tim is
| doing,and I bet others can resonate, I still "have to" pick up
| tickets and I think that's always the expectation in any job I've
| had as an IC. Is Tim managing his time well ?
| gravy wrote:
| It never occurred to me that a rebuttal to "not using lines of
| code or bugs solved because it can be gamed" is just to point out
| productivity is literally always gamed
| readthenotes1 wrote:
| They even have a fancy title, "measurement dysfunction", and a
| smug "if you know you know" nickname, Goodhart's Law
| graemep wrote:
| and Campbells Law, and the CObra effect.
|
| I had not come across "measurement dysfunction" before.
| Useful phrase.
| dilyevsky wrote:
| A related phenomenon is McNamara Fallacy
| NalNezumi wrote:
| Glad to hear that Tim stayed and author managed to steer the
| entire process towards the right direction. Which requires a
| listening manager.
|
| I experienced the "bad ending" of this productivity metric
| trickle down: OKR. This startup wanted not just team-based
| 3-month review Objective Key Result but also individual one, and
| on top of it, tied stock option to OKR. It was a robotics startup
| so very cross-domain teams (Software, Hardware, Embedded, DevOps,
| HW design, HW testing, HW maintenance etc etc).
|
| The result? Developers became lonely islands. There were no "Tim"
| anymore. When I (Software Integrator) encountered an issue, that
| I just couldn't figure out but had a hunch it must be a deep-
| rooted issue, went to the expert (control/kinematics) for
| feedback. The answer I got was "I'm sorry I really want to help
| you but my OKR deadline is very close, and I simply don't have
| time". He could've probably fixed it in a day or less, but it
| ended up taking 2 weeks.
|
| The problem turned out to be quite deep: inside layer upon layer
| of C++ mega monorepo, I found that boost library and a custom
| kinematics library had implicit struct copy and the different
| libraries (more than two) used different order for representing
| translation & rotation (xyz, rpy, Euler, Quaternion) and all of
| the ordering of each components were different. Somehow over 2
| years of operation nobody got troubled by this until our new team
| had to use it.
|
| Afaik I reported it to the Software team, but again, because OKR,
| nothing was done about it.
| jrs235 wrote:
| 100% this. Want to sacrifice team output? Have team members be
| concerned about individual goals. Team alignment and
| synchronization will be off affecting the efficiency and
| effectiveness of that team's performance.
| bipson wrote:
| I think just because this startup botched OKRs they still make
| a lot of sense.
|
| Intel and Google apparently relied on them heavily in their
| formative years. But:
|
| - they should be cascading (so conflicting OKRs between
| departments should not happen)
|
| - you should never, _ever_ tie them to individual performance
| results /compensation/rewards
| YZF wrote:
| My sense was OKRs came later for both Intel and Google. Do
| you know around what year/size they started?
|
| I worked with some ex-Google person who tried to get us to
| use OKRs. That totally didn't work. Larger company.
|
| Like many things I don't think they're necessarily a bad idea
| it's just that good ideas always lose to culture. With the
| right culture/leadership it's not the process that matters.
| I.e. OKRs aren't going to fix an organization that isn't
| aligned and conversely there are infinite other ways to align
| an organization with the right culture and leadership. So in
| practice, like other things, it just ends up making things
| worse because it's never a real fix.
| lapcat wrote:
| Was Tim hired as a teacher or trainer? What I find strange is
| that it sounds like Tim was not doing _any_ individual work.
|
| As a very experienced programmer, I'm sure that I could increase
| the productivity of other programmers by pairing with them all
| day. However, is that actually the best and most productive use
| of my time? In my estimation, I think that overall team
| productivity would be maximized if I spent approximately 20% of
| my time pairing with others and 80% on individual contributions.
| (That's a rough estimate; it could be 25/75 or 30/70.) The
| article said that Tim was "patient", but perhaps he was too
| patient, wasting a lot of his time that could be spent
| accomplishing other things.
| motorest wrote:
| > Was Tim hired as a teacher or trainer?
|
| Do you think that's any relevant? Software development
| engineers in general are hired to work on projects as part of
| small teams, and their goal is to deliver projects. It's not
| story points, it's not burn down charts, it's not PRs, it's not
| LoCs touched. It's how many projects are delivered, and keep
| everything and everyone problem free. This means that if you
| are struggling, your team will struggle as well until you
| unblock yourself. If you can unblock yourself by having a team
| member sit besides you and walk through a problem, that team
| member will be helping the team.
| infinghxsg wrote:
| Yes, obviously it's relevant you have a fundamental
| misunderstanding about what software engineers do. We don't
| "build systems" we diffuse risk for the managers. If someone
| is "helping build something" they can spend their own money
| doing that. This is business, the less work you do the more
| money you make.
| lapcat wrote:
| > If you can unblock yourself by having a team member sit
| besides you and walk through a problem, that team member will
| be helping the team.
|
| I don't dispute that; hence the 20-30% pairing. But if it's
| the case that all day, every day there's at least one person
| on the team who is blocked, then you don't need a "Tim", what
| you really need is a new team, because that's an unacceptable
| level of blockage.
| kcoddington wrote:
| Why is it unacceptable? And wouldn't the time/productivity
| loss from on-boarding an entirely new team completely
| outweigh the time/productivity loss of the 100% pairing
| with a Tim?
| Vampiero wrote:
| It's cheaper to hire 5 juniors and to give Tim a mental
| breakdown than it is to hire 5 Tims.
|
| Realistically though, if you really did hire 5 Tims you
| would deliver in 1/5th of the time and the software would
| actually be decent on the first iteration.
|
| It seems to me that consultancy companies actually _want_
| inexperienced developers because they can bill their
| inexperience to the client as they train them to become
| useful. Awful and, as stated, a major source of mental
| breakdowns for the Tims who have to put up with their
| bullshit. And also for the juniors who are always running
| from fire to fire as they try to fix the clusterfucks they
| created.
|
| This is not how you should do stuff, but it's how everyone
| does it. At some point it's just the blind leading the
| blind, because Tim also has other shit to attend to and
| can't review every LOC on every PR by himself.
|
| I didn't become a senior by being mentored by other people,
| btw. I became one because I've always loved doing what I
| do, and nothing more. The internet and physical books
| mentored me _impersonally_. So I 'm sure that they can
| mentor other people just fine, and I don't see why I should
| waste my time just because my boss is stingy and can only
| hire a couple of people with my experience or drive to
| learn outside of work.
|
| And let's be clear -- _mentoring_ and _being taught
| something_ are two very different things. I 'm not anal
| about the latter. I'm anal because I want to write code, I
| don't want to tell people that they should learn to fucking
| read the error messages and google them every 5 seconds.
|
| Though right now I'm being very brutally honest. I'm
| actually nice and friendly to them in person, and I'm very
| patient. But that causes me to break every once in a while
| because I secretly loathe it!
| inetknght wrote:
| > _because that 's an unacceptable level of blockage._
|
| You shound like a manager. Let me know when you identify
| and quickly solve all the reasons that the team frequently
| gets blocked. Until then, we have Tim.
| throwanem wrote:
| > You sound like a manager.
|
| Yeah, I think that's a good read.
|
| Give management credit for being smart. They mostly do
| manage only to promote the most egregiously avid
| Taylorites from among us.
| bee_rider wrote:
| Is a Taylorite a known expression or are you riffing off
| the idea of a Taylor series? Haha.
| throwanem wrote:
| It's a reference to "scientific management" aka
| Taylorism, the pejorative name by which that now-
| universal practice was rightly known the last time labor
| had something resembling the power we deserve in this
| country.
| marcosdumay wrote:
| Taylor is a famous management researcher, that created an
| entirely new school of management, which by its turn
| evolved even before his death to become something
| completely different from the theories held by Taylor
| himself.
|
| Just to point out in reference to the sibling comment,
| Taylorism is not a pejorative term, it's the correct name
| of a school of management. Any pejorative implication on
| that name is a perfectly deserved result of the quality
| of the ideas in it.
| motorest wrote:
| > Give management credit for being smart.
|
| Respectfully, this is being the exact opposite of smart.
| Pay attention to the fact that by all accounts the Tim
| role is actually a force multiplier and output booster
| for the team. Pay also attention to the fact that you're
| arguing that Tim should be fired as should the whole team
| just because... Your Jira metrics are off? This is not
| what I would call being smart, by far.
| throwanem wrote:
| You assume management optimizes poorly for desiderata you
| share.
|
| You also assume by "smart" I intend no pejoration.
|
| Were you to hear me speak these words, rather than read
| them as here typed, the latter point at least would need
| no clarification. Unfortunately, text like this is salt
| without savor.
| motorest wrote:
| > But if it's the case that all day, every day there's at
| least one person on the team who is blocked, then you don't
| need a "Tim", what you really need is a new team, because
| that's an unacceptable level of blockage.
|
| I don't think your opinion is educated, or based on any
| experience working on a functioning team, let alone a high-
| functioning one. Any team working on non-trivial projects
| does stumble upon critical bugs that are hard to catch or
| features that are faster to roll out if a subject matter
| expert sits down with someone to show them the ropes. If
| you care about performance and time to market, this is your
| baseline already. You are not better off with a dozen
| cowboy developers who wouldn't even piss on a team member
| if they were on fire.
| lapcat wrote:
| > I don't think your opinion is educated, or based on any
| experience working on a functioning team, let alone a
| high-functioning one.
|
| That's an incredible assumption about me. What is your
| empirical justification for such an insulting claim?
|
| > Any team working on non-trivial projects does stumble
| upon critical bugs that are hard to catch or features
| that are faster to roll out if a subject matter expert
| sits down with someone to show them the ropes.
|
| Again you're arguing something that I never disagreed
| with. Indeed I explicitly advocated spending some % of
| time pairing.
| rsynnott wrote:
| Depends what they're doing, and how junior the team is. For
| something relatively involved, with a few new-ish grads, or
| people inexperienced with the problem domain, on the team,
| it wouldn't be surprising. Shows up particularly often in
| rapidly-growing companies, where by necessity teams are
| often mostly new-ish.
|
| Now, ideally you do not lean on a single Tim to make this
| work; that's kind of a failure mode (I've occasionally been
| a sort of a temporary Tim, but the goal would always be to
| move the team more towards self-sufficiency to avoid
| becoming a perma-Tim.) A part-time Tim, who consistently
| spends part of their time unblocking others, is IME a
| fairly common phenomenon, and probably necessary.
| grayhatter wrote:
| I've been the TL for a team of effectively 5 new grads before.
| Effectively all of my time was spent teaching them how to solve
| problems, fixing (preventing) bugs in their code from getting
| committed, and writing boilerplate, or infra code that would
| never be listed on whatever a story point is. But constrained
| their responsabilities into a format and structure that would
| play well with each other's so they would stop constantly
| rewriting each other's code every other week.
|
| I enjoy teaching so that was a much more enjoyable way for me
| to spend my day, than drinking caffeine and cranking code the
| rest of the team couldn't understand. I joined that team
| because they were constantly missing deadlines. When I left
| that team they were finally ahead of schedule, but much more
| importantly they had a code base they all understood. That
| wouldn't have been true if I'd just written all the code
| myself. I like to tell myself I could have gotten the team
| ahead of schedule as a solo endeavor writing 80% of the code
| myself. But true or not, when I left I would have no confidence
| the team could continue without me.
|
| Could I have spent more time writing code? Probably, but what
| delivered the most businesses value? I was hired as a glorified
| software engineer but instead of delivering code, I delivered a
| team that could produce code. Their manager was *never* gonna
| do that. So should I have prioritized doing what my job title
| said? Or doing what's in the best interests of the long term
| mission? Every situation is gonna be different, if teaching is
| soul crushing for you, or more importantly, the team refuses to
| be taught, I would suggest just deliver code. In this case,
| everyone wanted to learn, so that was the easiest path forward.
| lapcat wrote:
| > a team of effectively 5 new grads
|
| > they were constantly missing deadlines
|
| Gee, go figure.
|
| > I like to tell myself I could have gotten the team ahead of
| schedule as a solo endeavor writing 80% of the code myself.
|
| > what delivered the most businesses value?
|
| What the company should have done is hire you and _one_ new
| grad (rather than five), who you could mentor without
| spending all of your time mentoring, and get the same amount
| of work done with two people for less money.
| throwanem wrote:
| Advice from the world where things always go as well as
| they could is of limited value in this one.
| grayhatter wrote:
| yeah, what the company should have done, is only hire
| experts! Hiring new grads is definitely a mistake they're
| making!
|
| ...except then I never would have been willing to work
| there. I won't work for an MBA bean counter. I want to work
| for a company that's willing to invest in people. One that
| doesn't treat life as a zero sum game, where someone else
| has to lose so the company can make money.
|
| I get it; for most people the line on the graph _must_ go
| up! And it must keep going up, forever! But I reject that
| meme as the direct cause of the enshittification of
| reality, and refuse to play any negative sum game. "The
| only winning move...." and all that.
|
| BTW, that project would have died with just a team of two
| because I did eventually leave that company. So that
| suggestion would have killed that project. System
| resilience matters too.
|
| edit:
|
| > Gee, go figure.
|
| This isn't a given. If their manager was as good at
| teaching and understanding code as I was, they _shouldn 't_
| have been missing deadlines. Proven by the fact that I
| admit I didn't contribute a significant number of lines of
| code. So what is this trying to say? New grads are bad?
| lapcat wrote:
| > yeah, what the company should have done, is only hire
| experts!
|
| I did _not_ say that, and you know it: "What the company
| should have done is hire you and one new grad (rather
| than five)".
|
| > I won't work for an MBA bean counter. I want to work
| for a company that's willing to invest in people.
|
| Um, IMO someone who hired a team of 5 new grads sounds
| like an MBA bean counter and not someone that's willing
| to invest in people. It sounds like they brought in an
| experienced programmer (you) _only_ because the
| preexisting pathological team was (predictably) failing.
|
| > BTW, that project would have died with just a team of
| two because I did eventually leave that company. So that
| suggestion would have killed that project. System
| resilience matters too.
|
| And you could not be replaced because.. why? People
| leave, other people are hired. Life goes on. The new
| grads may leave too.
| grayhatter wrote:
| > Um, IMO someone who hired a team of 5 new grads sounds
| like an MBA bean counter and not someone that's willing
| to invest in people. It sounds like they brought in an
| experienced programmer (you) only because the preexisting
| pathological team was (predictably) failing.
|
| Nah, this was a pet project of my skip level, and I
| joined after he asked my boss for solutions to the delay.
| The manager who owned the project had all of his
| experienced eng working on direct contracts.
|
| This company had a lot of contracts in where the number
| of engineering hours allocated are specified. This was an
| internal project, without a hard cap on number of hours,
| and they were assigned because it would have been
| malpractice otherwise. This was very much a team built
| out of the resources available, rather than intentionally
| selecting only new grads.
|
| I couldn't be replaced because it being an internal
| project, it would have been killed once it had no active
| development. And I suspect internal politics would have
| prevented it getting restarted after the first
| delay/failure. Turns out stuff is way more complicated
| than the easy assumptions people like to make.
|
| > sounds like they brought in an experienced programmer
| (you) only because the preexisting pathological team was
| (predictably) failing.
|
| It's easier to predict failure than success. That's that
| same zero or negative sum game though. Usually a cheap
| way to feel superior instead of doing the harder things.
| My previous edit already addresses that though. Failure
| wasn't actually a given like you want to predict.
|
| edit:
|
| > I did not say that, and you know it: "What the company
| should have done is hire you and one new grad (rather
| than five)".
|
| Right, of course I know you didn't say that, nor do I
| think you'd actually advocate for it. But taking
| something to the extreme to see where it fails is a
| useful rhetorical tool. The point being, that only hiring
| experts is obviously bad, for the same reason that only
| hiring new grads is bad.
|
| I think we agree that there is a balance to be struck?
|
| I think 5 noobs to 1 expert is fine, just like 5 to zero
| is bad, just like 1 to 1 is bad. The point being, there's
| no magic line where one is right, the other wrong. This
| team had no problem once the missing puzzle piece was
| added. And it was able to be successful in ways that 1
| and 1 wouldn't have been. There is no reasonable way to
| say "what you should have done" when describing a puzzle
| where you can't see most of the pieces.
| lapcat wrote:
| > they were assigned because it would have been
| malpractice otherwise.
|
| I don't know understand this means.
|
| > This was very much a team built out of the resources
| available, rather than intentionally selecting only new
| grads.
|
| Yet your other comment says, "this particular company
| paid way below market rate with the promise of
| interesting work. It without a doubt incentivizes hiring
| new grads where you roll the dice and hope the good ones
| will stay because they enjoy the job. It's very hard for
| them to attract experts at the salary that they're
| offering." https://news.ycombinator.com/item?id=43453700
|
| > it being an internal project, it would have been killed
| once it had no active development.
|
| I'm having a hard time understanding why this project
| needed to exist at all.
|
| > But taking something to the extreme to see where it
| fails is a useful rhetorical tool.
|
| I disagree, and it only created unnecessary argument in
| this case. You ended up having to retract and clarify
| anyway:
|
| > I think 5 noobs to 1 expert is fine, just like 5 to
| zero is bad
|
| But the team _was_ 5 to zero.
|
| > just like 1 to 1 is bad.
|
| Why?
| grayhatter wrote:
| > I don't know understand this means.
|
| It means, this team was very much a team built out of the
| resources available, because the existing experts in the
| company who could have been mentoring new grads were
| already working full time doing something with a direct
| contractual obligation to the company. I would have been
| negligent to pull them from an existing inprogress
| contract to mentor newbies, and the contracts had a hard
| limit on number of hours, (not years of experience), so
| placing a new grad on one of these contracts, replacing
| an experienced engineer would have degraded the success
| of the contract.
|
| > Yet your other comment says, "this particular company
| paid way below market rate with the promise of
| interesting work. It without a doubt incentivizes hiring
| new grads where you roll the dice and hope the good ones
| will stay because they enjoy the job. It's very hard for
| them to attract experts at the salary that they're
| offering." https://news.ycombinator.com/item?id=43453700
|
| Right, they're not conflicting statements. The company
| would hire a pool of engineers that can do engineering,
| then a different part of the company would sign contracts
| to complete work, than a middle part would place the
| engineers in the company onto contracts.
|
| > I'm having a hard time understanding why this project
| needed to exist at all.
|
| Well, because it was a really cool project that the
| company did end up marketing and selling to it's various
| clients. It was also a perfect project to put a bunch of
| new grads who otherwise wouldn't have been doing any work
| at all given the projects had contracts that stated they
| couldn't accept more engineers.
|
| > I disagree, and it only created unnecessary argument in
| this case. You ended up having to retract and clarify
| anyway:
|
| I didn't retract anything? Are arguments bad? I actually
| enjoy being able to arguing interesting points and
| topics. If you're willing to be wrong, you can learn
| things. As an example I didn't think my previous examples
| were so controversial. Nor did I remember that contract
| based engineering work isn't a common thing the most
| people already have intuition for.
|
| > [just like 5 to zero is bad...] But the team was 5 to
| zero.
|
| The team you called pathological? Yeah, it was bad.
| Missing deadlines is bad. I don't understand where you're
| confused.
|
| > [just like 1 to 1 is bad...] Why?
|
| I already answered. Because of politics a project that
| small would have died with a team with just a single new
| grad. It also would have been boring as fuck. So if I
| left, I'm sure the new grad would have also left. Which
| means the company who hired us both, would then have to
| hire two new people. This was years ago, but I assume
| some of those original new grads are still there. In part
| because that team was actually fun to work with. They
| were good people, and the team was just fun to be around.
| A team of just 2 is boring... I know because I've also
| been on _that_ team with me doing all of the work, and it
| was soul crushing, and contributed to why I left.
| lapcat wrote:
| >> But the team was 5 to zero.
|
| > The team you called pathological? Yeah, it was bad.
| Missing deadlines is bad. I don't understand where you're
| confused.
|
| >> [just like 1 to 1 is bad...] Why?
|
| > I already answered. Because of politics a project
|
| I was confused because I thought you were trying to make
| general points, but apparently you're mired in the minute
| details of one company and its extremely specific
| projects and politics.
|
| I'm getting the impression that there were so many
| idiosyncratic constraints on the project that it simply
| couldn't have gone any other way, and thus there's no
| real way to critically evaluate whether things would have
| gone better with a different arrangement. Be that as it
| may, I'm not sure what kind of general conclusion we're
| supposed to draw from such a constrained example? Going
| back to the linked article, the case of Tim didn't appear
| to be so constrained:
|
| 1) They were thinking of getting rid of Tim, which
| presumably wouldn't have killed the project entirely.
|
| 2) They expected Tim to make more individual
| contributions, which presumably wouldn't have killed the
| project entirely either.
|
| 3) The team already had a mix of junior and senior
| engineers, not simply Tim and a bunch of new grads.
| bee_rider wrote:
| It seems hard for us to say, from the outside, how the deal
| ended up for them. They spent the experienced programmer's
| time setting up a team of five. If they'd had GP train one
| person and work on code as well, they'd have one good new
| engineer and some code. Now they have five good new
| engineers.
|
| I mean, it depends on how long it took, how much code GP
| could have produced in the meantime, and how sticky the
| lessons were. There's certainly room to believe GP is right
| and it was a good trade for the company.
| grayhatter wrote:
| this particular company paid way below market rate with
| the promise of interesting work. It without a doubt
| incentivizes hiring new grads where you roll the dice and
| hope the good ones will stay because they enjoy the job.
| It's very hard for them to attract experts at the salary
| that they're offering.
| bee_rider wrote:
| Yah. I also just wanted to make the meta point or
| whatever--this is your anecdote, technically there's room
| for you to be wrong or right, but we don't have any
| connection to the underlying reality to argue against
| your interpretation... so why not just go along with your
| story?
| sally_glance wrote:
| Very interesting topic and as you say the ratio should very
| much depend on what his designated role in the team was.
|
| For tech leads, I think the ratio should be heavily skewed
| towards enabling other team members (by pairing or working on
| cross-cutting concerns, usually devops/infra). Something like
| 20/80, where the 20% individual contributions are only the
| toughest nuts which can't be done in a reasonable timeframe by
| anyone else.
|
| For senior developers, I'd say it depends on team composition.
| If there is one senior and 3 juniors, training them should be
| his primary concern. If there are 5 heavily specialized
| seniors, I'd say the ratio should lean towards individual
| contributions.
| UK-AL wrote:
| In a lot of companies the definition of senior engineer helping
| others develop technical skills.
| throwanem wrote:
| In a few of those companies, so also is the job.
| rsynnott wrote:
| I think that's overly cynical. It should always be part of
| the job (except in places where title inflation has hit the
| level that it really doesn't mean anything at all) and
| usually is.
| readthenotes1 wrote:
| Kinda concerned the author thinks story points correlates with
| biz value....
| RKFADU_UOFCCLEL wrote:
| Very good article, managers just want short summaries of what's
| going on and sometimes these summaries come in the form of bad
| metrics.
| _fat_santa wrote:
| Honest Question: Are there any metrics around developer
| productivity that actually work? Reading stories like this and
| others over the years I've come to the conclusion that you simply
| can't measure developers productivity on a granular level, it's
| just about the final product. However, I would love to be proven
| wrong.
| tpmoney wrote:
| I don't think there are realistically any good "individual"
| productivity measures that work across a broad spectrum of
| employees, even when all of those employees are in the same
| role. Every team I've ever been a part of, even before being a
| developer has been made up of people that all contributed to
| the overall project in different ways. Imagine trying to
| measure all workers on a car assembly line by the number of
| screws they insert per day, or the number of welds they make
| per day. Anyone who's primary job on the line isn't inserting
| screws or making spot welds is instantly a low performer by
| this metric, and yet you can't assemble a complete car with
| only screws and welds. And it's worse I think in something like
| software development, where the specific way a team member
| contributes might be more nebulous. Very rarely do you hire
| someone just for their code review skills or the design
| capabilities. The team member that somehow always manages to
| recall the tiniest of details about the system that no-one else
| recalls from the feature work done 5 years ago is not exactly a
| skill you can find on a resume or even one you could build a
| good metric for even if you had hand tailored metrics for all
| employees.
|
| And it's a hard problem to solve. I don't envy the job of
| anyone in management trying to figure out how to determine who
| (if any) of your employees is a drag on the team. Sometimes
| it's obvious and there are concrete problems, but other times
| it's just someone "everyone knows" is a drag, but without hard
| metrics, you're left with awful things like having employees
| stack rank each other.
| rsynnott wrote:
| See https://en.wikipedia.org/wiki/Goodhart's_law - _in general_
| once you start using metrics to reward and punish people, that
| will break down. It's by no means limited to software
| engineering.
| dosinga wrote:
| Tim would do well in these times of LLMs. They can write code
| faster than anybody but also need more guiding and coaching than
| anybody. They don't learn anything no matter how much we call it
| machine learning. These days what we most need is a Tim of Tims -
| somebody who coaches software engineers into becoming Tim.
| darthrupert wrote:
| Damn. Now that I read this I realize why my current team feels
| like nothing gets done and the reason is the team has no Tim.
| ibash wrote:
| That's not a good excuse
| easyThrowaway wrote:
| I mean, I've worked on some companies where management would've
| seen what Tim was actually doing and nonetheless reply with
| "We're not paying him to hang out with other developers, we pay
| him to sit at his desk and code!"
|
| Vox Jira, Vox Dei. Make sure you're not working in a company with
| such kindergarden-like approach at managing people before
| attempting anything like that.
| Beijinger wrote:
| This reminds me of the chicken problem:
|
| https://medium.com/heroicpresence/the-super-chicken-study-pa...
| Waterluvian wrote:
| When you look at damage per second graphs and conclude that all
| your healers need to be kicked from the raid.
|
| It's so difficult to quantify the value of "support" but they're
| indispensable. I have yet to really find a sensible way to
| quantify it. It's ultimately just something that you need to
| trust leaders to get right.
| pipes wrote:
| I've never worked on a team where story points aren't translated
| into time. I've found story points to be a completely useless
| level of indirection. Genuine question, has anyone here ever
| found them useful?
| cornel_io wrote:
| There are a couple important things to also keep in mind:
|
| First: just like there can be individuals who lift up an entire
| team but are not ticking off tasks themselves, there can be
| apparently individually productive team members who slow the
| entire team down for any of a number of reasons. In my experience
| it's usually either that they are a) fast but terrible, b) have
| really weird coding styles that might not be bad but are very
| difficult for others to work with (architecture astronauts and
| people who barely speak the language often fall here), or c) are
| process bullies who try to set up the entire review system to
| enforce their preferences in a hardline way that suits them but
| delays everyone but them. Each needs to be dealt with very
| differently, to varying degrees of success, but my honest opinion
| at this stage is that no matter how productive these people seem
| by themselves it's mostly harmful to have them on a team.
| Behavioral issues in senior people tend to be really tough to
| adjust, and take a lot of energy from a manager that is better
| spent helping your top performers excel; that said, if you can
| get them to adjust sometimes it's worth the effort.
|
| Second: pair programming works great for some people, but it is
| terrible for others. I've measured this on teams by trial and
| error over fairly long periods, and unfortunately it's also the
| case that people don't segment neatly based on their preferences,
| so the obvious "let them choose" method isn't ideal. There are
| pairs of people who really love pair programming and desperately
| want to do it all the time who are almost fully 2x as productive
| when split apart instead (yes, including downstream bugs and
| follow-ons, meaning that they really are just having two people
| do the job of one), and there are people who hate pairing who see
| similar multiples by being forced into it even though they hate
| it. My rough intuition is that there are two independent
| variables here, a social factor that measures how much you enjoy
| pairing, and a style factor that determines how much benefit you
| derive from it, with the two not correlating much at all. There
| might even be a slight anticorrelation, because the more social
| people who love it have already naturally done as much knowledge
| sharing as is helpful, and the people who hate it are
| underinvested there and could use some more focus on the fact
| that they're part of a team.
| karaterobot wrote:
| > 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.
|
| I'm very glad this essay turned out to take this position,
| because when I read the first couple paragraphs, I was ramping up
| to write a mean internet comment about how stupid measuring
| developer productivity through story points is.
|
| A friend of mine is exactly like this Tim guy he talks abou: he
| spends time helping other people fix their problems, or takes
| extra time doing things the right way. His personal velocity
| suffers, but the team and the code base is greatly improved on
| net. He was put on a Performance Improvement Plan at one company,
| and told his job was at stake at another as a result. No question
| it's kept him at a Senior level when he should be higher at this
| point in his career. I sort of take it personally, because I
| worked with him at the company that gave him the PIP, and both he
| and I quit as a result.
|
| When I see companies trying to measure developer productivity
| (and tying it to employment and advancement) I think about
| _Seeing Like a State_ by James Scott, and the concept of
| legibility: imposing by force a set of rules on a complex, messy
| system to make it easier to steer from some office far away.
| Makes it very convenient to managers, and often leads to
| disaster.
| noqc wrote:
| Goodhart's law is not a joke. There is no standin for value.
| dmoy wrote:
| Yea the best teams I've ever been on have always had someone like
| Tim.
|
| The best _best_ teams I 've been on, Tim's helpfulness osmoses
| onto other people, and instead of Tim always being the one, the
| process goes like this:
|
| 1. Dev gets stuck
|
| 2. Dev attempts to unstick self for appropriate amount of time
| given problem and probability of self-unsticking given resources
| (e.g. some stuff is easier to search for internally, or dismantle
| and go piece by piece)
|
| 3. Dev announces "hey I'm blocked on XYZ thing"
|
| 4. Whoever knows the most about that topic (not always Tim, but
| often Tim) puts that as like their highest priority thing, and
| almost always jumps in right away to help (unless they're like
| ignoring chat cus they're in the zone)
|
| Works great especially if you do #4 at some break time (like say
| lunch or standup), and everyone has enough things to work on that
| they can do their own internal CPU pipelining and work on other
| stuff until someone has time to help unstick them
| Atotalnoob wrote:
| Problem on a lot of teams is people skip over #2 in my
| experience.
|
| Good devs always do #2, bad devs skip it.
| ChrisGammell wrote:
| Extra points for the ones that sit down at step 4 and lay out
| all the things they've already tried so the context on the
| problem is clear
| nedt wrote:
| That's easy to solve. When they ask me it might take an hour
| or two until I come back to them. If they were just trying to
| us me as a rubber duck the problem will have been solved by
| then. And it's not only devs. Also PMs have this behaviour.
| Sitting it out before asking what they need makes most
| question vanish.
| morsecodist wrote:
| The idea of measuring individual developer productivity is kind
| of absurd to me. I'm not saying that what we do is magic, there
| are just so many variables.
|
| Measuring story points or lines of code is kind of the opposite
| of productivity. This encourages developers to do as much
| meaningless work as possible. I'd want a developer to make a task
| simpler or use an existing tool which means less time writing
| code. The value of them saving that work from knowing another way
| is high but hard to measure.
|
| What you want is measuring business outcomes but those are hard
| to attribute to a particular developer.
|
| I think unfortunately we're left with our subjective judgement
| here. I think we'd do better admitting to ourselves that we can't
| measure this than to pretend we have some sort of science here.
| mrbadguy wrote:
| Well said. There's a noticeable lack of judgement in many
| places these days; people think they can abdicate it to metrics
| and data but this is mistaken.
| jckahn wrote:
| I don't think it's that we _can't_ accurately measure developer
| value/productivity, it's that doing so isn't feasible with any
| methodology we currently have. As you said, we're not doing
| magic, therefore our value is measurable. Measuring just
| requires an impractical degree of time and energy.
| suzzer99 wrote:
| Dev productivity is like quantum mechanics. The second you try
| to measure it, the wave function collapses, and you've
| fundamentally altered the thing you were trying to measure.
|
| That said, at every place I've worked you could get a starting
| point idea of who the top devs were by looking at overall code
| commits. This Tim sensei situation may be more common than I
| think, but I've never run into it.
| elevatedastalt wrote:
| Thanks to Goodhart's law, it's true for any measure that
| becomes a target.
| lolinder wrote:
| > at every place I've worked you could get a starting point
| idea of who the top devs were by looking at overall code
| commits.
|
| This works for Junior through Senior level roles, but it
| falls apart quickly when you have Staff+ roles in your
| company. Engineers in those roles still code, but they write
| a fraction of what they used to and that is by design--you
| want these people engineering entire initiatives,
| integrations, and migrations. This kind of work is essential
| and should be done by your top devs, but it will lead to many
| fewer commits than you get out of people who are working on
| single features.
|
| With a few exceptions for projects with a high degree of
| source-level complexity, a Staff+ engineer who's committing
| as much as your Senior engineers is probably either
| misleveled or misused.
| suzzer99 wrote:
| Yeah, I've always worked at non-tech companies with pretty
| small teams and no roles like that. But it seems like any
| place with Staff+ engineers should know better than to try
| to stack them up against more junior devs based on some
| metric.
| philjohn wrote:
| Case in point, I worked with a Staff software engineer (I
| was also the same level) who consistently, half over
| half, had zero diffs to their name.
|
| Because they were leaning more into a product archetype -
| which it turns out they were very suited to.
| winwang wrote:
| With my minor dabbling in game theory, I've considered funny
| angles like secret-ish internal metrics and punish those who
| simply game the incentives. Example: bot detections and
| banwaves in MMOs. Instead of instantly banning plausible
| bots, the company has to hide its (ever-changing) internal
| algo and ban in waves instead.
|
| Basically, treating (non-)productivity like bot detection,
| lol.
| gopher_space wrote:
| I've worked on projects where every single ounce of
| enthusiasm is coming out of one mediocre developer. Nobody
| pays attention to team dynamics like this, but they're all
| over the place.
| nijave wrote:
| I like looking at lines removed and, in context with, lines
| added or PR count. Someone more experienced will be
| refactoring and removing old stuff while adding new stuff and
| will have some balance (barring vendoring or moving file
| trees between repos)
| suzzer99 wrote:
| Lines removed should count like 5x lines added. I don't
| trust any developer who doesn't get a thrill out of
| removing code.
| __turbobrew__ wrote:
| > That said, at every place I've worked you could get a
| starting point idea of who the top devs were by looking at
| overall code commits
|
| Yea, in the current place I work at we do not measure coding
| performance metrics, but if you look at the top commiters to
| the repo -- by number of commits -- you will see all of the
| people who bring the most value to the company. Even at staff
| eng the best engineers are still the ones who crank out code,
| albeit maybe as not as much as a senior engineer. Staff
| engineers who only commit 1 a month are usually the ones who
| don't bring value to the company, especially given their high
| pay.
| hamburglar wrote:
| At my last gig I spent the last year and a half as staff
| engineer and made almost no commits because I was
| constantly writing proposals, defending them to execs,
| doing architecture reviews, doing design consultations, and
| planning long term responses to large incidents. I know for
| a fact that I brought a ton of value to the company but it
| was very uncoupled to commits. I didn't really like it
| because I need to code, so I've moved on to a role where I
| commit like a maniac again. :)
| jimbokun wrote:
| Just check all of your proposals and design documents
| into source control, and you'll still have plenty of
| commits!
| OnionBlender wrote:
| I had a director that was obsessed with github enterprise
| stats. He forbid people from squashing commits and told people
| to commit every day, even if you're in the middle of something.
| This was so that he could see who was writing the most code.
|
| One of our interns was close to the end of his term and this
| director wanted to hire him. He thought the intern was amazing
| based on the amount of code he wrote. The problem was that this
| intern was bad, so we had him write unit tests. However, he was
| also bad at writing unit tests. He would run the code and then
| write tests that enforced the current results, instead of
| considering that the current behaviour might be incorrect.
| Thankfully we didn't hire him after myself and others explained
| why the intern had so many commits and lines of code written.
| lisper wrote:
| > who was writing the most code
|
| There's yer problem right there. Code _quantity_ is not
| correlated with value. In fact, it can be negatively
| correlated with value if it 's buggy and laden with technical
| debt. Measuring productivity by lines of code produced
| actively discourages writing clean, maintainable, bug-free
| code.
| thesuperbigfrog wrote:
| > Code quantity is not correlated with value. In fact, it
| can be negatively correlated with value if it's buggy and
| laden with technical debt.
|
| ** "No Code" or Nihilist Software Engineering **
|
| No code runs faster than no code.
|
| No code has fewer bugs than no code.
|
| No code uses less memory than no code.
|
| No code is easier to understand than no code.
|
| No code is the best way to have secure and reliable
| applications. Write nothing; deploy nowhere.
|
| One of my most productive days was throwing away 1,000
| lines of code. -- Ken Thompson
|
| The cheapest, fastest, and most reliable components are
| those that aren't there. -- Gordon Bell
|
| Deleted code is debugged code. -- Jeff Sickel
|
| Measuring programming progress by lines of code is like
| measuring aircraft building progress by weight. -- Bill
| Gates
|
| * Master Foo and the Ten Thousand Lines *
|
| Master Foo once said to a visiting programmer: "There is
| more Unix-nature in one line of shell script than there is
| in ten thousand lines of C."
|
| The programmer, who was very proud of his mastery of C,
| said: "How can this be? C is the language in which the very
| kernel of Unix is implemented!"
|
| Master Foo replied: "That is so. Nevertheless, there is
| more Unix-nature in one line of shell script than there is
| in ten thousand lines of C."
|
| The programmer grew distressed. "But through the C language
| we experience the enlightenment of the Patriarch Ritchie!
| We become as one with the operating system and the machine,
| reaping matchless performance!"
|
| Master Foo replied: "All that you say is true. But there is
| still more Unix-nature in one line of shell script than
| there is in ten thousand lines of C."
|
| The programmer scoffed at Master Foo and rose to depart.
| But Master Foo nodded to his student Nubi, who wrote a line
| of shell script on a nearby whiteboard, and said: "Master
| programmer, consider this pipeline. Implemented in pure C,
| would it not span ten thousand lines?"
|
| The programmer muttered through his beard, contemplating
| what Nubi had written. Finally he agreed that it was so.
|
| "And how many hours would you require to implement and
| debug that C program?" asked Nubi.
|
| "Many," admitted the visiting programmer. "But only a fool
| would spend the time to do that when so many more worthy
| tasks await him."
|
| "And who better understands the Unix-nature?" Master Foo
| asked. "Is it he who writes the ten thousand lines, or he
| who, perceiving the emptiness of the task, gains merit by
| not coding?"
|
| Upon hearing this, the programmer was enlightened.
|
| Source: http://www.catb.org/~esr/writings/unix-koans/ten-
| thousand.ht...
| musicale wrote:
| Unix-nature loves malicious argument and code injection
| vulnerabilities, while C brings its own set of issues
| such as buffer overflows.
| trelane wrote:
| This is an amazing collection. Thanks for it.
|
| It's is exactly what I was needing for this slide deck on
| I'm writing how to improve our code.
| slowtrek wrote:
| a) Would make a great coffee table book.
|
| b) Would make a great poster.
| btilly wrote:
| The author of the shell script was probably Doug McIlroy.
| See www.leancrew.com/all-this/2011/12/more-shell-less-
| egg/ for more.
| psychoslave wrote:
| Turning a 100+ lines function of 5+ intertwined control
| flow mess into a single expression using a combination of
| method chaining of just a few lines is always a delighting
| experience to my mind.
| vezcha wrote:
| code is liability for both the business and the thinker at
| the end of the day. It's worth it to spend as much time as
| possible figuring out how to avoid writing it and keep it
| minimalized.
| jimbokun wrote:
| I'm getting a similar sense from many of the AI "success"
| stories we've been hearing. There's amazement about how
| many lines of code the AI produces in a short amount of
| time.
|
| But not so much about maintaining and debugging all those
| lines of code once they're created.
| arealaccount wrote:
| Probably not the point but committing every day is one
| methodology for TBD and it's great for generating
| productivity. Not so much useful for measuring productivity
| though.
|
| I can't imagine how miserable it would be to try to measure
| dev productivity by quantifying commits on a daily basis.
| What a waste.
| oasisaimlessly wrote:
| TBD = trunk-based development
| rottc0dd wrote:
| https://yosefk.com/blog/engineers-vs-managers-economics-
| vs-b...
|
| > ...It's a common story and an interesting angle, but the
| "best vs good enough" formulation misses something. It sounds
| as if there's a road towards "the best" - towards the 100%.
| Engineers want to keep going until they actually reach 100%.
| And managers force them to quit at 70%:
|
| > > There comes a time in the life of every project where the
| right thing to do is shoot the engineers and ship the fucker.
|
| > However, frequently the road towards "the best" looks
| completely different from the road to "the good enough" from
| the very beginning. The different goals of engineers and
| managers make their thinking work in different directions. A
| simple example will illustrate this difference.
|
| > Suppose there's a bunch of computers where people can run
| stuff. Some system is needed to decide who runs what, when
| and where. What to do?
|
| > * An engineer will want to keep as many computers occupied
| at every moment as possible - otherwise they're wasted.
|
| > * A manager will want to give each team as few computers as
| absolutely necessary - otherwise they're wasted.
|
| > These directions aren't just opposite - "as many as
| possible" vs "as few as necessary". They focus on different
| things. The engineer imagines idle machines longing for work,
| and he wants to feed them with tasks. The manager thinks of
| irate users longing for machines, and he wants to feed them
| with enough machines to be quiet. Their definitions of
| "success" are barely related, as are their definitions of
| "waste".
|
| > The "good enough" is not 70% of "the best" - it's not even
| in the same direction. In fact, it's more like -20%: once the
| "good enough" solution is deployed, the road towards "the
| best" gets harder. You restrict access to machines, and you
| get people used to the ssh session interface, which "the
| best" solution will not provide.
| paradox460 wrote:
| Reminds me of a manager and a QA I once knew. QA was a nice
| guy, but a terrible QA. Would fail stories on the most
| arbitrary guidelines. Story is about changing the font size
| on the home page? He'd fail it because he wasn't able to log
| in (he tested while the auth service was undergoing planned
| maintenance).
|
| Manager loved this guy, and pushed him through several
| promotions. Eventually other employees got tired of being
| skipped for promotions and left the company, creating a minor
| staffing crisis
| renewedrebecca wrote:
| I think just about everybody has had to deal with one or
| several of these guys.
| paradox460 wrote:
| Much as cancer arises and grows from natural cellular
| processes gone awry, this seems to be an organizational
| cancer, present in any company of a large enough size.
| asdf6969 wrote:
| > Story is about changing the font size on the home page?
| He'd fail it because he wasn't able to log in (he tested
| while the auth service was undergoing planned
| maintenance).
|
| Average offshore QA team.
| rvba wrote:
| Well, I seen a fair share of "blind" programmers who just
| did their (very limited) scope, perhaps they did it well...
| yet the whole tool just didnt work and nobody cared.
|
| I imagine that if the guy pointed out things like this - he
| wasnt popular with the developmemt team, but popular with
| management and users.
| jimbokun wrote:
| This story tracks pretty closely with the Dilbert cartoon in
| the article. Except unintentionally.
| fsndz wrote:
| the worst programmer nowadays is the vibe coder. vibe coding is
| so overrated imo https://www.lycee.ai/blog/why-vibe-coding-is-
| overrated
| sanex wrote:
| I've been writing code professionally for a decade but I've
| never written so much code in my free time because I can just
| vibe code it all. I wouldn't do it at work and I probably
| wouldn't trust a juniors vibes as much as my own but no tools
| have made me feel quite so powerful.
| fsndz wrote:
| it's definitely nice for prototypes, but nothing more
| complex.
| eclipxe wrote:
| I used to feel that way but my perspective over the last
| 6 months has changed greatly. You can absolutely build
| very complex things in this style
| fsndz wrote:
| show me an example of such a complex thing obtained after
| just writing prompts
| Yoric wrote:
| That's actually not a contradiction.
|
| As far as I can tell, you can build very complex
| prototypes. But unless these prototypes can be both
| trusted and maintained, that's all they are.
| yodsanklai wrote:
| I never tried vibe code as described in this article, but I
| could see where it breaks. Initially, code works.
| Eventually, there's a bug, and the LLM isn't able to fix
| it. At that stage, you're on your own with a potentially
| large codebase which is totally new to you.
|
| Even on small projects, sometimes I'm tired, I just try to
| get the LLM do some refactoring for me or write a couple of
| tests. First, whatever the LLM writes, it's going to code
| review and I'm not submitting code that I haven't read and
| understood just to have colleagues complaining. Second, if
| the code doesn't work, it gets frustrating. For LLMs to
| help, I like to have a pretty clear idea of what I want,
| how the "right" code looks like so I can give more
| indications.
| smokel wrote:
| Perhaps give it some time before judging too harshly?
| fsndz wrote:
| vibe coding has been in the scene since the emergence of
| ChatGPT perhaps...
| bitwize wrote:
| Vibe coding is now a skill requirement for real, actual jobs
| but, thankfully I guess, no place I want to work (yet). The
| other day I saw a YC24 company in the "financial services
| industry" with a "vibe coder position". A prerequisite for
| the position was at least 50% of your current code being
| generated by AI; vibe-coding experience was "non-negotiable".
| Traditional programmers need not apply. And you'd better be
| ready to grind, 12 hours a day up to 7 days a week. It pays
| up to $120,000 a year plus squat for equity and relocation to
| San Francisco is required. That's like, McDonald's money in
| San Francisco, so guess they figure running a vibe-coding
| sweatshop is a huge savings for them.
|
| Oh, and the cherry on top? The "financial service" this
| startup provides? Automated robocalls demanding money from
| debtors on behalf of debt collectors.
|
| https://www.ycombinator.com/companies/domu-technology-
| inc/jo...
|
| YC has entered its villain arc.
| fsndz wrote:
| it's just a marketing stunt like prompt engineer with 200K
| salary back in the day. And the fact that you are talking
| about it and sharing the link to the company's profile
| means the stunt is working.
| slowtrek wrote:
| Could a company keep a subjective poor performer on for the
| lifespan of the company? As in, what is the plus or minus in
| overall revenue or profit from this charity? What if all
| companies did that? Could we distribute the "burden" of the
| charity across all companies for a better society? My point is,
| I don't even know if metrics are good or bad, we may need to
| look at why we see each other like this. Is it so offensive to
| the mind of the captain of a ship that they may have a few of
| not the best sailors? It's a chance for them to be on a ship,
| go on a journey. The concept of a "free ride" appears to be a
| serious moral hazard for us, but I can't figure out why.
| nijave wrote:
| I don't think productivity itself is absurd but it's definitely
| a hard thing to do, especially in small time intervals.
|
| I think it's important to measure employee performance and you
| can definitely can a macro look and say "what have you
| accomplished in the last year" which might be measured of
| delivery of "t-shirt" sized projects
| empiko wrote:
| It is not absurd. From manager's point of view, when they are
| deciding to let someone go or promote them, they often need
| some arguments. And since software is invisible, it is often
| hard to just say straight away who is over/underperforming and
| why you think so apart from a "vibe" you are having. Measuring
| some relevant metrics can strengthen your argument and/or your
| overview of the situation.
|
| I don't think that the blog makes a compelling argument why
| measuring productivity is bad per se. It makes a compelling
| argument that metrics should not be interpreted blindly, but
| the metrics in this case identified a guy that was doing
| something unusual, and the managers managed to interpret why
| this is the case. But if it was an IC that is supposed to
| deliver, or if you did not want "Tim" to spend his time
| coaching people, this could still have been valuable info.
| morsecodist wrote:
| I don't think it is absurd to reason about individual
| contributions, just to focus on measuring them with metrics.
| I have been on the management side as well though I admit I
| am much more of an IC. But the way I think that should go is
| laddering up to business value by describing what the person
| did and why that contribution was important.
|
| So for example I would say something like: X deserves a
| promotion because their work was important to delivering
| project A on time. Project A was difficult but worthwhile
| because it allowed us as a business to meet goals 1 and 2.
|
| That said I mostly work in smaller orgs. I have never been in
| a situation where a manager would be so removed from a team
| they would need a sort of proxy metric to direct them where
| to focus their attention to understand what the people on
| their team are doing day to day. I can see how this would get
| more difficult as a company grows.
| bob1029 wrote:
| > What you want is measuring business outcomes but those are
| hard to attribute to a particular developer.
|
| I think we could solve this by eliminating some middle tiers
| and putting the developers on the actual customer calls every
| week. Each senior developer owns at least one customer. That
| sort of thing.
|
| It's a completely different ball game when you are a developer
| on some B2B/SaaS and you are answering directly to the customer
| regarding your work. There's no one to hide behind - your
| teammates are now aside you and can only render supplemental
| aid. Once you have developers answering directly to the
| customers, you have a simple, ~boolean, qualitative metric that
| virtually any manager/investor can get behind: Is the customer
| happy?
|
| If the developers are keeping the customers happy, then they
| are performing. If the customer is unhappy, then there is a
| performance issue. Whether or not most or all of it can be
| attributed to blockers on the customer's side is irrelevant at
| the senior levels of play. Developers should be helping the
| customers get unblocked. Offer meetings & screen share time.
| Generally, make yourself as available as possible. If you do
| this correctly, the customer is likely to take note and provide
| you with some amount of cover (i.e., not be in a raging fit
| when they call your CEO).
|
| There is no reality in which you can inject more middle
| management or process to get developers to take more
| accountability. The only thing that works is to get them _out_
| of the bullshit matrix and in front of the customers. They need
| to experience how it feels to work directly with a happy
| customer and then realize how important it is to keep them that
| way.
|
| This path also happens to solve a whole host of other maladies
| in technology business, most notably shiny rabbit chases. When
| you have the fear of god in you regarding the client, you
| aren't going to be as inclined to play in traffic with a NuSQL
| engine on their watch.
| eek2121 wrote:
| lol no, I have worked with companies that do that. Many
| developers have very specific personality types, and they
| also think in technical terms rather than customer terms. It
| isn't a bad thing, it is why they are good at what they do.
|
| The most successful companies I have worked with have a good
| product manager that can take customer input and work with a
| technical manager to balance priorities/effort. The technical
| manager consults the team before making decisions (such as
| SCRUM meetings if using that)
|
| Issues come into play when folks start distrusting
| developers. When we say it will take 4 weeks or 8 weeks to
| implement something, there is a reason for that. We know the
| code. We know how much of a PITA it is to work with, and we
| aren't being misleading. On the flip side, we have been
| trained to give conservative estimates thanks to crap
| management and unexpected pitfalls, so we try to understand
| promise and over deliver. If management could recognize this,
| everyone would be happy, provided they recognize that 8-week
| timeline is fine and they don't promise something different
| to the client and trust devs to do their thing.
|
| EDIT: Managers also tend to forget that we aren't a machine
| in a factory. We have good days, bad days, and everything in
| between. We excel with using our brains, however our brains
| suffer from anything between lack of sleep, depression, and
| other nonsense due to just plain having a bad day. I feel
| like it is more noticeable with us because we rely on our
| brains so much more than other folks in other professions do.
| Shoot, even random noise in an office, whether working at
| home or at an office, can hurt productivity.
|
| Now I have myself missing dev work. Hoping to go back soon.
| Currently unemployed.
| markus_zhang wrote:
| A much easier solution is just assign a team improvement ticket
| to him and call it a day.
|
| I doubt he never worked on any tasks though, so maybe something
| for him once for a while.
| ChrisMarshallNY wrote:
| I think this was posted here a year or so ago.
|
| I love this story.
| PartiallyTyped wrote:
| What i like the most is how it describes the more senior
| engineers in my team.
| ewalk153 wrote:
| I love a good pairing ladder. While there is no absolute good
| measure of productivity, a suite of thoughts observation can
| provide at least tripwires.
|
| One major problem with tools that ask crafters to do data entry
| to show their value is that best people are most likely to
| refuse. You really need to focus on tooling to help capture
| what's going on without toil.
|
| For example, if your folks are remote and they use software to
| aid in pairing (eg Tuple), script the system to log the tuple
| sessions and perhaps even capture the pairing in the commits made
| together.
|
| This can be used as an input to bring visible to be best leaders
| in your org.
| tasn wrote:
| I get the point that they are trying to make, but Tim should try
| to find a way to ship things. It sounds like he could ship a lot
| and make the codebase better for everyone if he did.
| wwarner wrote:
| Hm. In the agile world, non-coders don't typically sign up for
| stories. So maybe this person shouldn't have been expected to
| land stories, or possibly there wasn't room in the budget for
| someone to be just a peer coder. I personally like the story
| paradigm as a way of working out (and then sticking to)
| priorities, and I love it when managers and principals work on
| stories like everyone else. Also, in the remote work context,
| everyone has to work harder on figuring out the right thing to
| work on, and stories are a decent way to achieve that.
| ibash wrote:
| Maybe.
|
| There's also folks that pair because they're a crutch for one or
| two other engineers. The other engineers never improve or are let
| go, but softly slow down the team.
|
| There's also the folks that pair because their code doesn't make
| sense on its own. Or they have some config files they've refused
| to check into the repo, etc.
|
| Pairing makes them feel valuable.
| gavmor wrote:
| > There's... folks that pair because they're a crutch for one
| or two other engineers [who] never improve.
|
| I can imagine this happening if neither pair is all that good a
| communicator, and if the seniormost never employs a little
| Socratic dialog every now and then.
| hansmayer wrote:
| I think a lot of this idiotic thinking about measuring
| productivity through "stories" is to pin on the "Agile" industry
| overselling their low value "methodologies" to the MBA-type
| managers, which are now unfortunately just about everywhere.
| Hence you have some clueless person deciding who has to go, based
| on how many tickets get moved on the board. As Joel Spolsky once
| said, no software company can succeed unless a programmer is at
| the helm.
| andix wrote:
| The title should be: Why measuring developer productivity by
| story points is bad.
|
| I was once part of a team that had a zero-storypoints developer
| too, let's call him Zero. He always refused to get any stories
| assigned during planning, his goal was always zero. He felt
| responsible for delivering all the planned stories and helped the
| people who struggled. He often came to me and told me to help
| someone on a specific task, because it was too much for him to
| help everyone.
|
| This was well understood by management though. Zero took a 4-6
| week vacation every year, and management always pushed important
| releases back if Zero was not there. The team could've done it
| without him, and it might've been better for the team not to have
| Zero around for all important releases. But management was scared
| something could go terribly wrong without him.
| snapetom wrote:
| Wouldn't Zero be a hero in disguise, then?
|
| When I hear stories about Tim or Zero, it makes sense... with
| the caveat of whether they are actually transferring knowledge
| to teammates, and whether the other team members are capable of
| taking over the function of Tim/Zero. If not, then Zero is just
| covering for low performers, and your bus factor is still a
| liability.
| aaws11 wrote:
| previously on hacker news:
| https://news.ycombinator.com/item?id=37361947
| m463 wrote:
| Reading this is similar...
|
| https://www.folklore.org/Negative_2000_Lines_Of_Code.html
| casey2 wrote:
| This just seems like you performed a social engineering attack on
| your boss to keep someone on the team who was objectively
| performing poorly but happened to be doing something that is
| valued in western culture.
|
| In short you replaced one well defined metric with an adhoc one
| following your bias.
|
| You are a peon. For all you know your local improvement has a
| negative effect on the whole company. Listen to your boss and let
| the company fail fast if it has an unfit system.
| PartiallyTyped wrote:
| This is an awfully bad reply. The person described in the essay
| is basically an L6 and an L5 moving to L6 at AWS. Our L6s don't
| write code, they build PoCs, work on designs, estimates, and
| scale through others. They use their experience and knowledge
| to scale out, and the L5s and L4s do the work.
| slowtrek wrote:
| Moral of the story:
|
| Anyone that looks for the metric to find the weakest link, is the
| weakest one at heart.
| iamleppert wrote:
| Counterexample: Not everything needs to be a group activity or
| social. If a developer of average skill can't manage to deliver a
| feature without the constant help from a "Tim", it says something
| about your code, processes, team. I've worked at places where
| they used pairing as a signal the team was working well together,
| when the reality was the code was so brittle and full of hacks it
| took the combined help (usually moral support) of a Tim to help
| support through every little change.
|
| Every team is different, but software development needs the time
| and space for individual work just as much as group work. A small
| team who needs a dedicated person for pairing, who also doesn't
| (or won't) do _any_ IC work, is a huge red flag.
| nijave wrote:
| Don't forget about the type of software. Something really
| specialized or algorithm heavy (science or math heavy) might be
| harder to do solo than a CRUD app.
| YZF wrote:
| My experience is the opposite. Easy stuff is simpler to pair
| up. Really hard stuff is solo. E.g. I expect Ph.D. work to be
| mostly a solo project.
|
| Not that it's impossible to do hard work collaboratively but
| I think a lot of heavy thinking is solo (Einstein, Newton
| e.g.) and it's hard to keep other people synchronized.
| tzs wrote:
| I had a sort of similar situation. I was one of two senior
| developers at a company making utility software for Windows and
| Mac in the late '90s and early 2000's. The other senior developer
| was the owner and CEO of the company and had to spend most of his
| time doing owner/CEO things so was only able to spend maybe one
| day a week developing.
|
| The way we organized most of our Windows programs is that I'd
| write a non-GUI core that implemented all the underlying system
| level stuff we needed, and then the junior developers would write
| a nice Windows GUI that used that core. If the product needed
| anything like a VxD, a filesystem hook, an LSP, or any other
| Windows kernel extension I'd write that too.
|
| We were profitable and there would be profit sharing bonuses
| quarterly (I think...might have been monthly but that doesn't
| significantly change what follows). The owner was always
| tinkering with how to decide how much profit sharing each person
| got.
|
| One scheme, which he was sure was going to be great, was to take
| the total amount available for profit sharing for a quarter and
| divide that by the number of employees. Call that amount "1
| share". So if there were N employees there were N shares
| available.
|
| He wanted those shares to be allocated so that 25% of the
| employees got 2 shares, 50% got 1 share, and 25% got 0 shares.
| Who is in what group would be determined by a company wide vote.
|
| Ballots were distributed that listed all N employees in
| alphabetical order, and we were told to write a 2 next to N/4
| names, a 1 next to N/2 names, and write a zero next to the
| remaining N/2 names.
|
| For each person their numbers from all the ballots were totaled,
| and the 1/4 with the highest totals got 2 shares, the 1/4 with
| the lowest totals got 0 shares, and everyone else got 1 share.
|
| In addition, the people with the 8 highest votes would be put on
| a committee that would advise the owner on the direction of the
| company.
|
| The owner's expectation when he launched this was that I would be
| the top vote getter nearly every time, and would always be in the
| top 8 so be on the committee of 8 which he was planning for me to
| run.
|
| I ended up not being in the the top 8. I wasn't even in the top
| 25%. I don't remember for sure, but it was either somewhere in
| the bottom half of the 1 share group or it was in the 0 share
| group.
|
| The reason was simple. Although I wrote the core functionality of
| all our products my role was not really visible to people other
| than other developers. It was the junior developers who wrote the
| GUIs. It was the junior developers who did most of the
| interaction with the testers. When a test found a bug they'd
| report it to the junior developer who was, to the testers, the
| face of the project. If the bug turned out to be in code the
| junior developer would let me know.
|
| So every developer put me down for 2 on their ballot, but to
| everyone else I was just some guy in development doing some
| unknown work so I didn't get many votes from anyone else.
|
| At least the owner immediately recognized that this profit
| sharing scheme was flawed and dropped it. Since he reacted so
| quickly I didn't gloat too much over the fact that this was
| exactly what I told him was going to happen when he first
| proposed this scheme.
|
| (Some gloating was necessary because the owner and I had been
| best friends since we met in college about 15 years earlier, and
| the obligation to rip on your best friend when they do something
| stupid after you told them it would not work is stronger than the
| rule that you shouldn't tell your boss "I told you so!").
| umvi wrote:
| So there wasn't a way to capture the fact that Tim was helping
| with so many JIRA stories in a way that makes Tim's work more
| visible? Like maybe pair programming stories that Tim owns and
| moves on the board (assuming Tim's time is best used in a
| mentorship capacity)?
|
| It kind of rubs me the wrong way that Tim can just fly under the
| radar and do whatever he wants without any paper trail or
| accountability while the rest of the team has to clearly convey
| what they are working on
| afro88 wrote:
| You can put subtasks under stories, and Tim can have his own
| subtask that represents his contribution. You can also (with an
| extension) put time against subtasks if leadership/management
| want to get really pedantic. Each team member should have at
| least 1 assigned story/task/bug in each sprint, and Tim should
| have at least x hours logged against subtasks off stories in
| the sprint.
|
| Or you can, you know, trust your team to deliver the stories
| they said they could do in a time window, as a whole. Let them
| figure out the how at the team level.
| TZubiri wrote:
| I don't think this demonstrates the whole system and premise was
| wrong, you can just adjust so that Tim gets some credit whenever
| he helps a teammate.
|
| Measuring stories/features/issues solved seems sensible to me
| crazygringo wrote:
| I agree with a couple other comments here -- this is a _bizarre_
| model where one programmer does _no_ individual work and does
| _all_ the helping.
|
| A much healthier situation, to me, is one where Tim does stories
| like everybody else, and when people need help they ask the group
| and whoever is the best _at that thing_ helps them -- or whoever
| hasn 't helped in a while.
|
| Surely there are easier stories for those who need the most help,
| and Tim should be taking on the hardest stories by himself?
|
| Or if you really do have an _insanely_ lopsided team where
| everyone is straight out of school with no experience, and a
| single super-senior dev, then... shouldn 't they just be a
| special kind of team lead who is expected to mentor full-time and
| not be subject to metrics?
|
| The post here is not a good example _at all_ of metrics failing
| to capture work. In reality, it is surfacing the fact that either
| _Tim 's job title and metric are totally wrong for him
| individually_, or else that Tim is _failing_ to contribute the
| hardest code, and the team is _failing_ to distribute the
| "helping" workload. In both cases, the metric is working as
| intended, and it is surfacing something very important than needs
| to be fixed. (Remember, "fire Tim" is not the only possible
| action you can take because of a metric.)
| wavemode wrote:
| > shouldn't they just be a special kind of team lead who is
| expected to mentor full-time and not be subject to metrics?
|
| It sounds like this was precisely the situation, and the
| author's company did indeed take this very action, in response
| to seeing the data. So, what is your complaint?
| nawfalak wrote:
| even though this post puts in a good word for tim, calling him
| out and putting his linkedin in a post with this title is crazy
___________________________________________________________________
(page generated 2025-03-23 23:00 UTC)