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

411–420 of 668 posts

Re: The worst programmer I know

#411

Post by andy_ppp »

I worked with a copywriter who did similar stuff and made the team tick. It was great to watch him effortlessly get everyone doing the right thing for the project and it worked both ways, he'd communicate effectively with the dev why we needed to hack things and with the business about getting us extra time for certain things. It lead to a better project with a manageable amount of technical debt.

He was let go and the project became a lot less successful and enjoyable, once he was gone a large group left soon afterwards...

Re: The worst programmer I know

#412

Post by epanchin »

crazygringo wrote: post #287
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 li…

The point of scrum is to provide employment for consultants and non-engineers.

I left engineering for an engineering job in finance. No scrums, no POs, just trader driven development and I haven’t looked back once. Glorious.

Re: The worst programmer I know

#413

Post by sodapopcan »

vikramkr wrote: post #303
orpheansodality wrote: post #192

Earlier quoted context omitted.

pairing is taking stories, it’s two people working on one task together.

So then he hasn't been taking zero, "literally zero" stories like the article says.

The article said zero stories according to Jira.

This is, of course, rectifiable in Jira by allowing a ticket to have multiple people assigned to it.

...unless they aren't using Jira and some tool that doesn't allow this.

Re: The worst programmer I know

#414

Post by varispeed »

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…

I worked at companies where de facto lines of code were a metric of performance. Then when I moved to first company where "how" was more important I had a heavy anxiety where I didn't write a line of code for a couple of weeks. I was worried I'll get fired. We were just having meetings and just talking about problem at hand and throwing ideas, without actually trying to implement anything. Then when the ideas how to tackle the problem matured, we would try to turn it into code, like a proof of concept thing (tested with people looking for solution) which could be thrown away. Eventually we would get the solution to the problem and most of the time it was flawless. In the code heavy approach, company would have ton of bugs, support requests, fixes on top of fixes, sometimes it turned out the feature was misunderstood, but it was already so embedded in the system, it was difficult to remove. So things were piling on. The other approach? Boring. We had some bugs here and there, usually when something was not covered by the tests or some edge case we didn't think of. But I never forget the anxiety...

Re: The worst programmer I know

#415

Post by astrange »

thereisnojesus wrote: post #266
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…

I have struggled to find work my entire life, but people like this get jobs. I hate life

You live in a different country probably.

Or, the past isn't the present. It was very difficult to get a job in the US in 2008 and now it's easy because it's 2023. (slightly harder for some kinds of tech)

Re: The worst programmer I know

#416

Post by ozim »

TuringNYC wrote: post #48
ww520 wrote: post #34

Stories like this happened is because managers want to treat software development as a manufacturing process.

I heard stories from past employers where they wanted bi-monthly increases in scrum velocity. "OK, last sprint the team did 150 points, so we should do 160 points this sprint." The funny thing is that point estimates just went up to compensate for productivity gain demands. "More productivity" yay!

Well I think that is the worst that can be.

Maybe best as well because you quickly know to pack things up and look for a new job.

Re: The worst programmer I know

#417

Post by csours »

I've asked this question a number of times now: What is the unit of work for software development?

If you work on a factory line, you can measure widgets per hour and quality. In construction, you can measure distance or area completed. But in programming, you are not making a repeatable product like the factory line. You can say that developers deliver story points; that is the product, not the work.

I invite you to come up with your own answer before you read mine.

----

----

----

I think the inner cycle of development is learning and trying. You learn about a system, make a theory, try that theory out, try to extend that theory, then you test. That test will let you learn some more - was I right or wrong, was there some side effect. Then you repeat.

I don't think this learning and trying is a good unit of measure for performance, but I do think it's a good basis for an engineering notebook, which may be reviewed with a manager.

Non-junior developers are essentially managing themselves when it comes to getting the work done. So how do you manage a manager, when that manager is not responsible for widgets?

Re: The worst programmer I know

#418

Post by BirdieNZ »

raincom wrote: post #185
Philip-J-Fry wrote: post #124

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…

In almost all companies, even seeking help is frowned upon. One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'. Some actively don't want to help out others, due to PIP/bonus culture. At Amazon, some team members explicitly give bad advice when asked for help. That's why we have this culture of "lone rockstars", who spend a lot of time to learn without being mentored.

> One ex-Microsoft manager, now a senior Manager at Atlassian, called that 'hand holding'.

Which senior manager is this, out of interest?

Re: The worst programmer I know

#420

Post by ChrisLTD »

voytec wrote: post #314
hibikir wrote: post #302

This is also why the most hilarious anti-feature of Jira, supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. If you do sufficient pairing, the person assigned to a ticket is completely useless. Also why performance measurement from the outside of a team is always going to be dubious. Every team knows their best performers, and their lowest performers. The number of points aren…

> supposedly a tool to manage agile teams, is how every ticket has one person assigned to it. It's whoever owns the issue. You can make it an epic and assign particular sub-tasks to team members if it's a teamwork.

Not sure how that solves the pair programming issue. What you’d need is a way to split the points for a single task among 2+ people without the overhead of duplicating the ticket.
Post reply on HN