Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The worst programmer I know

dannorth.net

Post reply on HN
Print view View original

281–290 of 668 posts

Re: The worst programmer I know

#281

Post by Chris_Newton »

ChrisMarshallNY wrote: post #262
jongjong wrote: post #18

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…

> There is a very good chance that the same feature set could have been implemented with just 10K lines of code, less buggy and in half the time A significant part of my personal code review process, is going back through my code, and factoring out complexity. It takes time and humility, but is very much, in my opinion, worth it. Documenting my code is a trick that helps. When I am writing why I did something, I some…

A big, big tool for that, is OOP inheritance, which is considered "bad coder" signal, these days.

Is it? I’d agree that there’s increasing awareness of the limitations of OOP, and I’d agree that using inheritance excessively can be one of the limiting factors, but I don’t think I’ve ever personally seen anyone criticised or penalised for using inheritance appropriately.

Re: The worst programmer I know

#282

Post by AtNightWeCode »

Metrics. I used to work on a team with skills in agile development. The process was evaluated at every retro and everything was tweaked. One member of the team however continued to put tasks into states that was not even in our agile board. Meaning. You could not drag a task into that state. You had to set it. Turned out that the idiot CTO used an unknown report to evaluate staff. One metric was putting a task into a specific state no longer used by our team. The idiot CTO had told his favorite pet dev about this metric.

Too bad I quit before the CTO, CEO and most of the board members got fired. Would have enjoyed sitting there and going. Yes, yes, yes.

Re: The worst programmer I know

#283

Post by ChuckMcM »

88913527 wrote: post #269
ChuckMcM wrote: post #255

When I've been asked to coach someone on "technical leadership" I always ask them to be on the lookout for "facilitator" employees, those whose help makes another employee more productive or effective. I am convinced there are "service oriented" personalities where people get more job satisfaction out of helping someone else do a great job than getting all of the credit for doing something amazing. As the author poin…

Have you ever seen an organization filled with service-oriented employees and no doers? Zero-interest rate policy has lead to having more Senior Director of Jira Board Management and Lists of Tasks type roles and not enough people that can do the work. I'm not opposed to the idea that others can be a catalyst for the productivity of others, but you need the others for anything to get done, otherwise it's necrosis.

> Have you ever seen an organization filled with service-oriented employees and no doers?

Yes, but to be fair it was an IT organization which had settled on a metric of "tickets processed" for their quality metric. As a result people who processed a bunch of tickets but never addressed root causes were seen as "good" vs people who wanted to fix fundamental problems that would reduce the number of tickets. It was, for me, a pretty classic case of picking the wrong metric. And to be fair the "best" IT/Service org is one that looks like it has nothing to do because it is always ahead of the curve of upcoming issues, and upper management has a hard time with that.

Re: The worst programmer I know

#284

Post by notyourwork »

ChrisMarshallNY wrote: post #270
tnel77 wrote: post #268

Earlier quoted context omitted.

In my experience, the best raises are from getting a new job. What were raises like for your engineers that stuck around for 10-20 years?

Not very good. These were highly skilled engineers that could easily have commanded better salaries, elsewhere. That meant they stayed for other reasons. I wonder what those reasons could be?

Will be five years with my current manager. Team has shifted some but money is not the only reason to stay somewhere.

Re: The worst programmer I know

#285

Post by yourapostasy »

jongjong wrote: post #18

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…

This is why software craftsmanship is rarely recognized. When you build with craftsmanship so features are easy and fast to add on top of what you built because you thoughtfully the most likely ramifications of the current requirements within reason, operational excellence is easy to accomplish because you sat down with front line operators and took the time to understand their incentives and daily operations pain points from a first-person perspective, and so on, you aren’t the one who is recognized with the commensurate credit, those who benefit from your work in the future are the ones who grab the limelight as if they did your work, unless the leadership are themselves highly technical (and many times, not even then). Incentives currently in most of my clients are mostly aligned to the fulfillment of keywords and not an outcome.

“Produce a procedure documentation” gets keyword fulfilled into “here is a document with some steps”, instead of “here is a procedure we wrote, used spelling and grammar checker upon [I’m still shocked so few take the few seconds to correct as they go], run through an automated editor, then iterated through random people from the user population until someone who never saw it before accomplishes the procedure without assistance”.

Some startups succeed because they’re forced into conscientiously thinking through these ramifications in just the right contexts because they’re so close to the coal face. It is also possible to overdo this in the wrong context and end up bikeshedding.

Re: The worst programmer I know

#286

Post by [deleted] »

ChrisMarshallNY wrote: post #260

> Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team. This was the money quote. Teams do big stuff. Good teams do good big stuff (very good). Bad teams do bad big stuff (very, very bad). It seems that the hyper-competitive nature of today's workplace means th…

[deleted]

Re: The worst programmer I know

#287

Post by crazygringo »

wonderwonder wrote: post #104

I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers. Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week…

> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.

But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.

I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds like the devs who you think gamed the system, were mostly behaving the way scrum is meant to incentivize. Happy, stress-free development that delivers consistently improving software.

(Minimum point totals per week leading to inflated point values is terrible management, though.)

Re: The worst programmer I know

#288

Post by twic »

Aperocky wrote: post #117

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.

The team being described here was one where all work was done paired. Senior engineers were never delivering by themselves. It sounds like you have experience of teams which are not like that, which makes comparisons ineffective.

The real reason Tim showed up as having zero productivity was because he always let his pair put their name on the ticket, and so get the credit for it. This is really a story about how things go wrong when a ticket tracker designed for solo work is used by a team which pairs.

Re: The worst programmer I know

#289

Post by [deleted] »

shultays wrote: post #212

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…

[deleted]

Re: The worst programmer I know

#290

Post by twic »

tchaffee wrote: post #263
owenmarshall wrote: post #74

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.

This is just not something that actually happens.
Post reply on HN