Live data from Hacker News

The Worst Programmer I Know (2023)

dannorth.net

271–280 of 385 posts

Re: The Worst Programmer I Know (2023)

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

This must be satire. It is a stretch even for Poe's Law. Someone is punking YC.

Re: The Worst Programmer I Know (2023)

#272

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…

Might it be that he’s so good everyone comes to him first and not you?

Re: The Worst Programmer I Know (2023)

#273
Agile methods are often applied wrong and then are a disservice. There is no one-size-fits-all method to manage people and teams. Leadership naturally buys into those method as they are promised an easier life, but there is no shortcut to management and leadership. It's always situational.

At my (very large) company Scrum and SAFe is applied to all kind of projects. Even to manage organisations with highly heterogeneous responsibilities and workloads. Think of 2 people doing dev, 2 conceptional work for various larger projects, 3 are basically consultants for other orgs, 4 are data analysts and 1 is doing some spreadsheet work all day long. Now our manager had the great idea to manage us with Scrum.

Re: The Worst Programmer I Know (2023)

#274

Earlier quoted context omitted.

In every organization I've worked in, everyone knew who the productive and non-productive people were. Just like in school. Everyone knew who the good teachers were, and who the good students were. I don't fathom how you can work with other people and not be aware of it.

Frankly, I think you might be confusing "productive" with "smart" or "easy to work with". I've had several past team mates at several companies gush to me about staff eng Bob and while I agreed Bob was a cool guy (or just talked good game) I also knew his last few projects were a failure, it was 100% his fault, and management took notice. It happened in the other direction too but not as often. Alternatively you migh…

> I think you might be confusing "productive" with "smart" or "easy to work with".

Working in teams for most of my career, and especially when I make or lose money depending on how the team performs, I am not confusing them.

At work, I am not really interested in how smart they are or how easy to work with they are, or how nice a person they are. At work I'm interested in results. I've had workers come to me and complain about "Bob" who has annoying habits and an abrasive personality. I defend the ones that produce results.

Outside of work, I value smart people who are good friends. I've had several friends who were laid off for poor performance, yet we continued as friends.

(Being somewhat on the spectrum myself, I recognize that in others and give them a lot of slack.)

> you might be underestimating how oblivious some (most?) people are of those things.

The oblivious ones were the ones who got laid off. They honestly believed they were god's gift to the company. Frankly, it was tragic. The ones I kept in contact with would ruefully admit to me years later that the company was right in laying them off.

Re: The Worst Programmer I Know (2023)

#275

Earlier quoted context omitted.

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

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

Yea it is dependent on your company.

When I think of highly functioning staff engineers Im thinking of people like Jeff Dean and Mitchell Hashimoto. Similarly at companies I have been at, even the highest level principal super staff++ engineers still code. They do the high level strategy and design, but they are still writing PRs at least every week or two. If you are spending 100% of your time on politics and architecture as a staff eng I think that shows a somewhat dysfunctional organization.

Re: The Worst Programmer I Know (2023)

#276
post #212

Earlier quoted context omitted.

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

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

Sorry but what is your point? I feel like you got offended by identifying yourself in it, but did not really understand it. My point being, as a non-engineering manager, you can be great at 1) approving holidays 2) doing a bit of project management 3) doing formal 1:1s . But it does not mean much because you don´t understand the work being done and you are just doing performative actions, e.g. busywork. Or we just say, f*ck it, let MBAs and scrum masters keep running our critical engineering businesses and at the end of the day the doors fall off of Boeing airplanes and astronauts end up spending 9 months instead of 9 days in space.

Re: The Worst Programmer I Know (2023)

#277

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…

This is why I like working on my own stuff. All that nonsense goes away and I’m left with just the two numbers that matter to me:

- how much money did it bring in this month, and

- how many hours did I have to work to make that happen.

The goal is to make the first number as big as possible while keeping the other as close to zero as possible.

Re: The Worst Programmer I Know (2023)

#278

Earlier quoted context omitted.

As in, if you are on the ship, we can absolutely find something for you to do. Here, color the fucking map, clean the sails. Why would we throw them off the ship?

That's another angle of what I mean, but absolutely. Stop expecting everyone to be above average, use your human resources intelligently, put people where they're productive and happy, and stop chasing nonstop growth. Mostly the last one. If we recalibrate our expectations about growth, I think we could tame the boom/bust cycle.

We need to start blogging about this, because it's been a torrent of utter filth advice being marketed to businesses.

Re: The Worst Programmer I Know (2023)

#279

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…

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.

Sounds like Tim's in a position where he knows he's appreciated by his team and enjoys his work, and is more than skilled enough to jump ship the second upper management decides to upend that. He has no reason to play the silly metrics games

Re: The Worst Programmer I Know (2023)

#280

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

> Some things that don’t measure whether a developer is “good”:

> # LoC added, changed, removed

Everyone loves to say this, and yet at every company I've worked at, the top developers just cranked out code. High quality, performant code.

And at every company I've worked at, the lowest performers would take a week to write 100 lines of basic python.

"Oh, but khazhoux, those 100 lines were really very complex!" No, not actually.

"But won't people just pad their code with comments to increase their LOC?" 1) I've never seen anyone bother, 2) I'm not saying "managers should count LOC"... I'm saying managers should look to see how much code each developer is actually committing to the codebase. If someone isn't committing much code, but talks like they're writing a lot of code, then you may have a problem.

Honestly, somewhere along the way people seem to forget that software is made from code.

I would never suggest a manager stack-rank their team by LOC, but the notion that the code people write means nothing, is preposterous.

Post reply on HN