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

41–50 of 385 posts

Re: The Worst Programmer I Know (2023)

#41

Post by kcoddington »

lapcat wrote: post #32
motorest wrote: post #27

Earlier quoted context omitted.

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

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

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?

Re: The Worst Programmer I Know (2023)

#42

Post by throwaway7783 »

Clubber wrote: post #13
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…

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.

Agree on silly games, but this is simply acknowledging others' contributions. I think this should be encouraged in general, metrics or not

Re: The Worst Programmer I Know (2023)

#43

Post by cratermoon »

eckesicle wrote: post #14

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

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

Re: The Worst Programmer I Know (2023)

#44

Post by Vampiero »

lapcat wrote: post #32
motorest wrote: post #27

Earlier quoted context omitted.

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

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

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!

Re: The Worst Programmer I Know (2023)

#45

Post by bberenberg »

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

Re: The Worst Programmer I Know (2023)

#46

Post by inetknght »

lapcat wrote: post #32
motorest wrote: post #27

Earlier quoted context omitted.

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

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

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

Re: The Worst Programmer I Know (2023)

#47

Post by dedup »

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

Re: The Worst Programmer I Know (2023)

#48

Post by lapcat »

grayhatter wrote: post #34
lapcat wrote: post #23

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

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…

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

Re: The Worst Programmer I Know (2023)

#49

Post by sally_glance »

lapcat wrote: post #23

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

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.

Re: The Worst Programmer I Know (2023)

#50

Post by whatshisface »

bberenberg wrote: post #45
motorest wrote: post #22

Earlier quoted context omitted.

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

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.
Post reply on HN