Live data from Hacker News

The worst programmer I know

dannorth.net

361–370 of 668 posts

Re: The worst programmer I know

#361

Earlier quoted context omitted.

[flagged]

Just say whatever point it is you are trying to make instead of making people guess

I'm actually quite enjoying how divisive a simple quote can be.

I wonder how often I've made a comment and gotten no engagement. This quote seems to have gotten more engagement than the original comment. And quite emotive engagement.

Makes me wonder what that means. Is it genuine curiosity? Or is the quote saying something that the original commenter couldn't see themselves? It's interesting they suggested if I was insinuating something negative about them.

Importantly, they did not ask me. They told me. That too tells us something about what pairing experience with them would be.

Re: The worst programmer I know

#362
post #70

Alternate lesson: If your manager is telling you to complete tickets, don’t go months and months not doing that thing until you’re on the verge of being fired because — despite being a valuable member of the team — your manager is all confused. Communication skills. Week 1 Tim could’ve brought up the issue of overall developer productivity with his manager and his manager would’ve at least been aware that Tim wasn’t…

Maybe Tim could have also added his name to the tickets as he was pairing and helping the others complete them...

Certain tools (Ahem MS) don't allow more than one person to be added to a ticket

Re: The worst programmer I know

#363
post #274

Earlier quoted context omitted.

"Buy in" is what you use for people acting in good faith. But managers aren't acting in good faith. They just want it done so that they look good to their own bosses. They don't actually care about the product/service. Their ask to "go faster" is a bad faith argument where there is no real need to go faster except for the manager to look good. I don't feel the need to get "buy in" for bad faith managers.

> but managers aren’t acting in good faith An overly broad statement which, my experience, is not true. Managers come in many shapes. Although, I suppose ironically, if you act in bad faith as a response to this perception, then I think that perception will quickly become true.

Why is asking for requests to be in writing an "act of bad faith"? Literally cna't see a single outcome that would be an act of bad faith here.

If the project fails, and the manager tries to blame it on you, they are de facto acting out of bad faith given the request. Documenting it just identifies this. If the project succeeds or fails, but no one blames you, then the documented request is just there for the record.

Re: The worst programmer I know

#364

Earlier quoted context omitted.

Annoyed? I’d love it: it would be an incredible door opener anywhere you went.

Get your resume. HR looks up your name. Throws out the resume. It could be fun if you can get an interview. It might hurt you though.

If HR is going to throw it out because of the title alone, they're going to be obnoxious to deal with even in the scale of HR departments.

Re: The worst programmer I know

#365

It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…

> That's over 100K lines of code a year. Think of the unnecessary complexity.

I've got a colleague like that. It's all good and management praises him, but this is a time ticking bomb. When he leaves, someone will have to maintain that code.

Re: The worst programmer I know

#366

It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…

I could be brief.

Or I could elaborate, expound, simplify, and expand my solution.

It depends what I’m getting paid for.

If I’m getting paid for lines of code, guess who’s going to re-implement functions that could have been a single line of code?

Why bother writing a loop function when I could just copy-paste the same code as many times as needed?

Turning one line of code into 3,000 - easy.

Turning 1,000 lines into 100 - that’s when you know you’re working with a professional.

Re: The worst programmer I know

#367

Earlier quoted context omitted.

Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor. It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role i…

It also doesn't get people promoted to that position just because that's what they're doing. Because politics.

Is that a higher level position ("promoted" suggests that)? In my FMCG IT department I am the TL & "technical architect", but I am on the same level as a senior developer, just having in the top 3 priorities the coaching and mentorship of all technical people in the department and no code expected (I do write some as examples or templates). What is the TL level in Google vs developers and architects?

Re: The worst programmer I know

#368

Tim’s productivity score was zero I also have a Tim in my team but he is a net negative. Most of the time he would try to pair up. He just make noises that implies he is following your work. But you can see that is not the case when he tries to make a comment or a suggestion, he is clueless. Trying explaining things to him is a waste of time. Rarely he decides to work on a task himself. No matter how trivial the task…

In Europe firing people is not always straightforward. There are so many people doing jackshit which make me go insane. I guess, good for them and I'm glad I'm not a shareholder. Management handle the most blatant cases in 6 months. There are so many people who are not completely clueless at pretending to do something and they go undetected for their entire career. From previous experiences, in a US startup they woul…

What value to society does making companies carry dead weight provide? It raises the company’s costs, lowers productivity and morale, all to protect someone unfit for a particular role?

The unpredictable layoffs and terminations of US companies are their own issue, but companies pay unemployment insurance to let people go with some safety net. I can’t imagine UI is more expensive than keeping an underperforming employee.

Re: The worst programmer I know

#369

Evaluating someone’s performance, especially, software engineers by non-tech people might produce dramatic results. Let me tell you a story about a friend of mine, codenamed tommy . Tommy was an IT guy with incredible skills in networking. He moved to an energy company, fully-owned and operated by the government. Just a few weeks from his arrival, they had to rebuild the entire network from scratch with new, modern,…

Was Tommy upset?

Re: The worst programmer I know

#370

I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good re…

Pair programming sounds so stressful and unproductive to me. You can't read someone's mind. Any interjections while someone is in the middle of coding can't be more than distracting noise most of the time. And I would constantly feel self conscious that I'm taking too long to write something, googling or asking Copilot stupid questions, etc. Reviewing after the programmer believes it's ready to review makes much more sense to me. Though Copilot can be very helpful as an artificial pair programmer.
Post reply on HN