Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Worst Programmer I Know (2023)

dannorth.net

Post reply on HN
Print view View original

81–90 of 385 posts

Re: The Worst Programmer I Know (2023)

#81

Post by riehwvfbk »

bonesss wrote: post #75
bberenberg wrote: post #45

Earlier quoted context omitted.

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…

> "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 sid…

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.

Re: The Worst Programmer I Know (2023)

#82

Post by grayhatter »

bee_rider wrote: post #59
lapcat wrote: post #48

Earlier quoted context omitted.

> 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…

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…

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.

Re: The Worst Programmer I Know (2023)

#83

Post by dedup »

mrweasel wrote: post #65
JohnMakin wrote: post #9

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 again…

That's an intersting point. I don't recall ever seeing a ticketing system where you could assign a ticket to multiple people.

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.

Re: The Worst Programmer I Know (2023)

#84

Post by pipes »

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?

Re: The Worst Programmer I Know (2023)

#85

Post by marcosdumay »

bee_rider wrote: post #64
throwanem wrote: post #54

Earlier quoted context omitted.

> 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.

Is a Taylorite a known expression or are you riffing off the idea of a Taylor series? Haha.

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.

Re: The Worst Programmer I Know (2023)

#86

Post by cornel_io »

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.

Re: The Worst Programmer I Know (2023)

#87

Post by karaterobot »

> 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.

Re: The Worst Programmer I Know (2023)

#88

Post by hnlmorg »

motorest wrote: post #22
JohnMakin wrote: post #9

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 again…

> 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…

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.

Re: The Worst Programmer I Know (2023)

#89

Post by lapcat »

motorest wrote: post #76
lapcat wrote: post #32

Earlier quoted context omitted.

> 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.

> 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 bu…

> 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.

Post reply on HN