Live data from Hacker News

The worst programmer I know

dannorth.net

221–230 of 668 posts

Re: The worst programmer I know

#221

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…

If your leadership is tossing these incredibly valuable engineers aside, then it's time for you to toss that leadership out. You can do that by leaving, or talking to management about this, or unionizing. It's crazy to me tech workers aren't unionizing anyway.

(I am from Europe, so I have a fairly good idea of what Unions can do, also thanks to having lived and worked in two different countries).

I am not against Unionizing "per se" but the role of Unions has never been "tell the management how to run their business". There has been some cases of (smallish) company being "acquired" by their own workforce, and the Unions might have helped with formalizing the deal, but this is rare, and anyway happens only when the company goes bankrupt or decides to shut down.

So I do not understand exactly what you mean here.

Re: The worst programmer I know

#222

Smells fishy. Senior engineers in my knowledge and experience are all delivering on something relatively high impact while contributing massively to the team by occasional/often "pairing". I've seen rare examples who don't "pair" but just deliver by themselves. I've never seen an example where they don't deliver on anything (planning, design, architectures included) but only "pair" as their job every day.

This^^ The article depicts it like it's an either-or when in real world capable engineers can consistently do both

Re: The worst programmer I know

#223

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…

It sucked being that person back then too. The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.

A lot of that is from Frederick Taylor, who invented “scientific management”.

He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1].

The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apart when the workers have unique knowledge and insight that management does not have.

[1] https://www.mentalfloss.com/article/63341/frederick-winslow-...

Re: The worst programmer I know

#224

I often wondered why s/w development is always a rush at the expense of quality. Well I do know why just don't agree with the principle of seeing how much the company can get out of a developer in x hours.

Management doesn’t always know what they are building is correct. They are going to manage risk of low quality with risk of wrong product.

If management doesn't understand what is being built, maybe they are not fit to be a manager?

Re: The worst programmer I know

#225
post #61

> He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses. I do not like people who do this. just tell me the answer. this is such a gigantic waste of everyone's time. you figured something out months/years ago, great for you. give it to me NOW, so I can get on with my day. if we BOTH run…

Quite simply, no. You're not going to learn from being handed an answer on a silver platter. You'll implement it, get on with your day, and not at all think about why the answer is what it is.

I've worked with several types of people. For me, the best mentors were the ones who would answer questions I had with the full answer, often with details. Then they got on with what they were doing while I went back to my desk and tried to understand/retain some of what they told me.

I'd personally find someone shadowing me and asking questions super annoying.

I don't think this would work with all teams, the takeaway I got from the article is about artificial metrics.

Re: The worst programmer I know

#226
post #68

Earlier quoted context omitted.

I sometimes use my job title as a higher level senior or lead to say vulnerable things like: "This change is hard for me to read and understand" or "This is a large PR, and it may be difficult for me to schedule time to review it. Can it be split up into a series?" I also configure linters and code quality tools to automatically flag some of the more egregious problems.

> "This change is hard for me to read and understand" Believe it or not, I consulted at one place where the manager decided I was the problem because I was consistently assessing problem code and team processes in similar ways. She asserted that "everyone else understood", even when they plainly didn't understand but where just going through the motions. Said manager had a number of other issues as well. Worst gig I…

I would start being less diplomatic once I get the hunch polite phrasing isn’t getting through - “this code is badly structured, brittle and will make debugging harder”. As programmers being tactless is expected so might as well use it to your benefit.

Re: The worst programmer I know

#227

Smells fishy. Senior engineers in my knowledge and experience are all delivering on something relatively high impact while contributing massively to the team by occasional/often "pairing". I've seen rare examples who don't "pair" but just deliver by themselves. I've never seen an example where they don't deliver on anything (planning, design, architectures included) but only "pair" as their job every day.

It's a great deal for Tim. He never has to work overtime to deliver something, and never has to fix bugs on stuff he built.

That said I believe the author that Tim was a huge net positive.

Re: The worst programmer I know

#228
post #88

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…

"Negative 2000 Lines of Code" https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

nice, thanks for the link

Re: The worst programmer I know

#229

Earlier quoted context omitted.

> That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy. And I learned that doing it my way will get me fired because the manager has asked to do faster. The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once…

This sounds like possible malicious compliance. Regardless, it’s an important life skill to learn that it’s generally not enough to ask people to do what you want, you need them to actually “buy in” to what you want, and then they’ll actually care enough to at least try make it happen. This applies to managers and their employees, or also when trying to get on the ground employees to adopt a product initially sold to…

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

Re: The worst programmer I know

#230
I have been this person and I'm trying to move away from it. It really is a great skill to enjoy lifting others and to be the glue of a team. But there are multiple slippery slopes inherent to that role that make it difficult. You can begin to confound the knowledge of others as your own, and almost certainly your own IC skills will atrophy if not purposefully maintained. I think it also requires the explicit buy in of the team, or at least other seniors who understand the benefits and can help keep balance.

It just takes one jealous colleague or one "efficiency minded" manager type to completely rug pull you. I know it's valuable because I have benefitted from that person many many times, but it takes empathy and a lot of balance.

Post reply on HN