Live data from Hacker News

Ask HN: What practice by a tech team pisses you off to your core?

news.ycombinator.com

21–30 of 54 posts

Re: Ask HN: What practice by a tech team pisses you off to your core?

#21
post #17

Pull requests which have artificial requirements. Which, these days, may mean many things. It's illusion that PR can usually be compact in terms of lines and files. That not only requires a good quality of code, which isn't ubiquitous, but also good understanding of code, which changes all the time with different opinions resulting in that code being modified. So PRs become rather large - and sometimes surprisingly m…

"Reduce the scope of your PR" a reviewer comments on a PR for a project that hasnt meaningfully addressed its technical debt in years.

Re: Ask HN: What practice by a tech team pisses you off to your core?

#22
post #17

Pull requests which have artificial requirements. Which, these days, may mean many things. It's illusion that PR can usually be compact in terms of lines and files. That not only requires a good quality of code, which isn't ubiquitous, but also good understanding of code, which changes all the time with different opinions resulting in that code being modified. So PRs become rather large - and sometimes surprisingly m…

"Reduce the scope of your PR" a reviewer comments on a PR for a project that hasnt meaningfully addressed its technical debt in years.

My last team was like this. So painful

Re: Ask HN: What practice by a tech team pisses you off to your core?

#24
post #8

not letting devs push code on friday afternoon

I'm with the bosses on this one. Nothing more fun than having some small side-effect out in the wild for a full weekend.

I have a personal rule that I won't merge to master after lunch on Friday. I'd just rather wait until Morning.

Re: Ask HN: What practice by a tech team pisses you off to your core?

#25
post #4

1) Sprint boards are not locked and things are added close to end. 2) Sprints are made overly ambitious because if not everything is done it makes it seem that someone slacked off when the achieving all targets was impossible in the in the first place.

  > when the achieving all targets was impossible in the in the first place.
slightly related: when managers keep pushing for "increasing velocity" every sprint, causing those impossible-to-achieve targets (and ends up demotivating the team like nothing else)

Re: Ask HN: What practice by a tech team pisses you off to your core?

#26
When my job description gets expanded. I am a rails/elixir dev. I don't do ops, that is a hard and complex job that takes practice to be good at. I respect the ops team. I can't just dip in and do one of their tickets when things are slow.

There is no such thing as full stack. Unless the stack is super small.

Re: Ask HN: What practice by a tech team pisses you off to your core?

#27

Most of the people getting promoted/going into management arent the smartest or best fit, its just someone willing to gun for it/jump through hoops. So you get those types potentially bossing around someone more competent, odd dynamic

> its just someone willing to gun for it/jump through hoops You mean motivated people with stronger work ethics? There’s a lot more to life than being smart.

The impulse for leadership rarely corresponds with the impulse to be a maker of great things. The best leaders arise of necessity, but would rather not, is a phrase I've heard mamy times that somewhat resonates.

How you get as belittling & insulting a turn as "people with woth stronger work ethic" (as though people who like doing work versus being overhead/commanders are all low ethic) is a sheer mystery to me

Re: Ask HN: What practice by a tech team pisses you off to your core?

#28
I'm not sure this pisses me off "to my core", but I've seen so many teams stop fixing bugs in something because they're writing a replacement that's supposedly going to be done in 6 months and will have none of those bugs. 2 years later the V1 is still the only solution that exists, and it's been allowed to rot while everyone suffered through the same bugs for 2 years. This happens most often when a team inherits a codebase they aren't familiar with and aren't excited about learning.

Re: Ask HN: What practice by a tech team pisses you off to your core?

#29
Two, related:

Not enough bottom up feedback. Roadmaps that can reflect the opportunities with high mechanistic-sympathy or address the real issues/opportunities seem rare once scale gets even mildly higher.

Product driven orgs that too often ask for quick & dirty & fast. Cutting corners is ok sometimes but if you keep doing ot, everything becomes a geometrically worsening half-baked barely-thought-out terribly-tentaclly-tangled mess, and the managerial/product class people never face it, see it, & move on, leaving the engineersired on their shit.

Quick & dirty also has a raft of personal issues associated with it. It's pretty insulting, often, as though product thinks they know best & are going to get some big savings. But 4 out of 5 times the damage more than makes up, but thats rarely admitted to or seen, and the savings never seem super significant. Also, good luck telling engineers to not take pride, to just throw shit together; I have found few respected peers who like being told that & who stay motivated when being told this is low quality whatever we're working on & to you know, just make some rough cuts at it & ship it.

The second of my two, asking for quick & dirty, leads to shit relationships & shit systems, which are major major reasons why my first issue, the on the ground knowledge of what we have & what we should be springing for & ehat we should be improving, becomes just a critical restabilization; bad jobs (or more often just accrued legacy to be honest) make it so fewer & fewer have the technical appreciation to right the hole-ridden old ship.

Re: Ask HN: What practice by a tech team pisses you off to your core?

#30

Causing others to lose face publicly. For example, calling out team members for a bug they introduced, when you could ask them about it privately. Another one - refusing to do any testing or CI because they think it will slow down the team.

> refusing to do any testing or CI because they think it will slow down the team.

This is a new one for me. I found an open source project with ~40k stars that I wanted to contribute to. I thought, there are almost no tests here, so I wrote up some tests and hooked it up to GitHub actions to run on PR submission. The maintainer of the project told me no thanks. It really surprised me! I thought everyone would be grateful to have more testing, but that apparently isn’t the case.

Post reply on HN