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

231–240 of 385 posts

Re: The Worst Programmer I Know (2023)

#231

Post by godelski »

fsndz wrote: post #148
eclipxe wrote: post #140

Earlier quoted context omitted.

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

show me an example of such a complex thing obtained after just writing prompts

Sometimes you enter a codebase and it looks like there's some obscure attempt to summon a Lovecraftian entity made of spaghetti and duct tape. Those codebases are both the shitiest and most complex stuff I've ever seen. They sure don't work well and I'm not even sure do a good job at summoning the old ones. I don't find LLM code significantly differing from that kind of monstrosity. It sure is complex.

Re: The Worst Programmer I Know (2023)

#232

Post by epolanski »

paradox460 wrote: post #181
OnionBlender wrote: post #108

Earlier quoted context omitted.

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…

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

Then the other employees found that this is how the world works: don't promote people that deliver results or you may have to replace them.

Re: The Worst Programmer I Know (2023)

#233

Post by ArthurStacks »

In my company I would have told him to start doing some work and getting stories delivered or he's gone. Yes, he's being useful in assisting others but I can easily find someone who can do that and their own work at the same time. He doesnt need to be sat there with others the whole time. What is likely going on there is Tim is playing his boss, playing up his pairing role and its benefits in order to sit being idle watching others work while providing commentary.

Re: The Worst Programmer I Know (2023)

#234

Post by [deleted] »

winwang wrote: post #142
suzzer99 wrote: post #107

Earlier quoted context omitted.

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.

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.

[deleted]

Re: The Worst Programmer I Know (2023)

#235

Post by godelski »

bitwize wrote: post #175
fsndz wrote: post #114

Earlier quoted context omitted.

the worst programmer nowadays is the vibe coder. vibe coding is so overrated imo https://www.lycee.ai/blog/why-vibe-coding-is-overrated

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

  > +3 years of experience.
Ummmm..... what?

This seems like it was written by someone who loves Dystopian Sci-Fi. Loves in the way that it is the future they want to live in.

Re: The Worst Programmer I Know (2023)

#236

Post by failrate »

SJC_Hacker wrote: post #121
failrate wrote: post #17

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.

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.

I was the ci/cd guy. I am not exaggerating when I say this person's code just would not compile and they would not test locally.

Re: The Worst Programmer I Know (2023)

#237

Post by sour-taste »

slowtrek wrote: post #146
morsecodist wrote: post #94

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

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

This is what Japan does. Employment is presumed to be for life. There are games companies play to get out very poor performers but most people get approximately lifetime employment.

Re: The Worst Programmer I Know (2023)

#238

Post by Aeolun »

paradox460 wrote: post #181
OnionBlender wrote: post #108

Earlier quoted context omitted.

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…

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

We kinda have this, but… At least we have a dedicated QA team. That spends their whole day literally just confirming that the shit we write is up to spec. We spend a lot of time resolving discrepancies between implementation, spec and test, but when things roll out the other end, they work.

Re: The Worst Programmer I Know (2023)

#239

Post by giantrobot »

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…

> For example, I’ve been running a remote team for 8ish years now and I keep begging people to have conversations in public channels.

No one does this because it's a bunch of bullshit noise in a channel disrupting everyone. It also opens a conversation up to bikeshedding which drags down the entire discussion.

Small ad-hoc groups can be very effective at solving problems.

1. The more intimate the group the less friction there is in conversation. There's less need/desire to put everything in "business speak" so no one gets their feelings hurt.

2. Small groups don't need to dumb down conversations for less technical participants if there's no non-technical participants.

3. Private chats mean no one is hovering over the conversation demanding some useless status update. A problem is either solved and committed or the group is still working.

Re: The Worst Programmer I Know (2023)

#240

Post by Aeolun »

lolinder wrote: post #133
suzzer99 wrote: post #107

Earlier quoted context omitted.

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.

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

I have a decent number of commits as a staff engineer, but barely any are on ‘features’ as measured by story points.

We’re building the things that other people use to deliver features better and faster.

Post reply on HN