Ask HN: What practice by a tech team pisses you off to your core?
Mine is small startups letting devs push code on Friday afternoon. What's yours?
53 comments
People bossing equally qualified and ranked employees around. Weak managers who don't make an effort to address problems and just complain. People who do what they want and then heap criticism on others. Short term decision making. Inability to commit to long term plans. Lazy workers who spend hours on the phone or take the longest breaks and also do very little but talk the loudest. Mercurial people who just like to argue but can never be pinned down on everything. People who just book meetings with no agenda in emails and expect you to commit to things without any prep. People who don't read meeting agendas and relevant documentation before coming to meetings, meaning that they need to be spoonfed. People who passive-aggressively stay silent at decision times and never engage and who then make fuss down the line when it's too late. People whose lives are very clearly not working who give you mediocre surface level advice about what they want to see from you when they're not qualified to offer any kind of therapy or counselling and rather than thinking more deeply about the mechanics of people. Managers who are visiting a therapist/counsellor and regurgitate the advice they heard from their last session to you. Managers who talk about their previous awesome gigs and fantasize about recreating them rather than focusing on the problem at hand. Managers who act like they're not supposed to make 50% of the effort in connecting with employees. People focused on empire building instead of doing the job well.
I can go on.
I can go on.
Non-stop complaining. Totally kills optimism and energy of an entire team. Complaining is contagious too, so it's not long before 1 chronic complainer infects the team.
I don't mean focused retrospectives, which is time set aside to constructively address things worth complaining about.
I don't mean focused retrospectives, which is time set aside to constructively address things worth complaining about.
[deleted]
speaking of retrospectives, I'm also in one where they refuse to do them, such a pain to make the same mistakes over and over
The CIO, or such, that tries to show he/she is the smartest person in the room. It's especially common in the tech interviews. Or the want-to-be tech person whose conversation is a salad of tech acronyms but has very little understanding of what all of them are about. It's about trying to impress the common person since most people are too afraid to ask what they mean and risk look dumb.
> Or the the want-to-be tech person whose conversation is a salad of tech acronyms but has very little understanding of what all of them are about.
This must be the person who writes job descriptions.
This must be the person who writes job descriptions.
Mine is when people start talking about XDR, SIEM or SOAR systems.
There's so much bullshit going on in the cyber security scene, it's ridiculous. From supposed "AI driven network analysis" to "data enrichment pipelines"... everything is built as Enterprise as possible, and as useless as possible.
An XDR system that costs more than 500k per month and cannot even show the geolocation of an IP it's supposed to be able to block traffic from...I mean, come on...
Let alone the alert fatigue Blueteams have to deal with every day, where 99% of alerts is just noise, and the supposedly "intelligent" system doesn't even correlate the OS, let alone the programming language its services are running on.
Analysts are so overworked because all the products suck and use UX from the 90s, and are not even capable of batch-closing alerts when they are identical. It's so stupidly built that I don't even know why upper management buys that crap.
There's so much bullshit going on in the cyber security scene, it's ridiculous. From supposed "AI driven network analysis" to "data enrichment pipelines"... everything is built as Enterprise as possible, and as useless as possible.
An XDR system that costs more than 500k per month and cannot even show the geolocation of an IP it's supposed to be able to block traffic from...I mean, come on...
Let alone the alert fatigue Blueteams have to deal with every day, where 99% of alerts is just noise, and the supposedly "intelligent" system doesn't even correlate the OS, let alone the programming language its services are running on.
Analysts are so overworked because all the products suck and use UX from the 90s, and are not even capable of batch-closing alerts when they are identical. It's so stupidly built that I don't even know why upper management buys that crap.
Sounds ripe for someone to disrupt! :D
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.
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
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
Agreed - most leadership arises out of a necessity to ensure that the boat stays clear of the rocks. I know (and have experienced) a few managers that were equally hopeless on both technical as well as people management fronts; their proclivity for using the boat's hull as a depthfinder made for some frustrating efforts, so to speak.
This is the wrong interpretation of my point
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.
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.
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.
Insisting on a CI/CD "deploy-direct-to-prod multiple times a day" process without ever investing in the things that are needed to allow this to happen successfully.
I've worked in the past with teams that have cargo-culted "Build fast, break things" to mean "If CI can builds it, let it deploy to prod". No tests, no Dev checks, barely any code review (The namesake "LGTM" on 1000 line PRs within 5 mins of it being opened or the worse Reviewer=Self), and things pushed to prod which invariably breaks and then everyone is scurrying to push hacky fixes because "it's a prod issue". And rather than fix the issue, it's always suggested to add more folks on call for critical issues etc.
It's okay when junior engineers do this because they're still building up their best practices, but when senior/staff engineers still bat for this process, it really grinds my gears because they not only mess up the company but "teach" junior folks that this shit proces is an acceptable way to build software.
Everyone will acknowledge that customers are seeing a lot of bugs (to the point where customers have attritioned because of buggy behaviour), and we need to be better, but noone acknowledges that CI/CD is not a silver bullet, but a rather intricate process that has many moving parts and needs to be built up accordingly.
I've worked in the past with teams that have cargo-culted "Build fast, break things" to mean "If CI can builds it, let it deploy to prod". No tests, no Dev checks, barely any code review (The namesake "LGTM" on 1000 line PRs within 5 mins of it being opened or the worse Reviewer=Self), and things pushed to prod which invariably breaks and then everyone is scurrying to push hacky fixes because "it's a prod issue". And rather than fix the issue, it's always suggested to add more folks on call for critical issues etc.
It's okay when junior engineers do this because they're still building up their best practices, but when senior/staff engineers still bat for this process, it really grinds my gears because they not only mess up the company but "teach" junior folks that this shit proces is an acceptable way to build software.
Everyone will acknowledge that customers are seeing a lot of bugs (to the point where customers have attritioned because of buggy behaviour), and we need to be better, but noone acknowledges that CI/CD is not a silver bullet, but a rather intricate process that has many moving parts and needs to be built up accordingly.
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.
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.
unsolicited advice: "like nothing else" is a meaningless intensifier that sounds like something a 10th grader would say, distinct from "more than anything else" which would specifically imply that the demotivation is more impactful than any additional work towards the impossible
thanks for the reply, actually i was thinking the same after i had submitted the comment... appreciate the feedback ^^
Management pushing for new features without a care for tech debt.
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.
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.
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.
When the team doesn't talk synchronously. So many times I've seen folks post a question that needs swift response to some issue tracker and then act indignant when they are held accountable for the thing not getting done. The answer is almost always "well no one responded until 3 days later".
Yes well no one asked you to leave some text on a server somewhere and hope someone sees it. They asked if you could do X by Y time and you said YES.
Yes well no one asked you to leave some text on a server somewhere and hope someone sees it. They asked if you could do X by Y time and you said YES.
To me it's often the variety of channels to communicate. When a question is asked that needs swift response and that question is not answered, naturally the person asking the question is stuck. It's quite awkward to try to get a response by some other means, one never knows - people don't want to answer? They don't know? They don't care, and anything goes? They just didn't receive the question? If there is just one channel, which in case of remote teams should be mandatory - and frequently monitored - at least some of those questions could be avoided. Like, a single channel in Slack, or email only. Otherwise, answer "well no one responded" becomes awfully justified.
Of course this usually isn't that much of a problem when the question is not too important, or the asking person knows possible options to proceed - it's usually a new or junior team member who suffers most from this. On interviews everybody is encouraged to ask questions, but in real life many become tired answering something which they know for too long - even though it's the specifics of the system, which they built unnecessarily complicated and just got used to. So unfortunately in subpar teams it becomes harder to obtain necessary information.
Of course this usually isn't that much of a problem when the question is not too important, or the asking person knows possible options to proceed - it's usually a new or junior team member who suffers most from this. On interviews everybody is encouraged to ask questions, but in real life many become tired answering something which they know for too long - even though it's the specifics of the system, which they built unnecessarily complicated and just got used to. So unfortunately in subpar teams it becomes harder to obtain necessary information.
Just any kind of “cheating”/intentional tech debt/low quality to meet an arbitrary deadline.
yeah it has never been worth it so far in my career and I always expend 10x the energy cursing such compromises
A true 10x engineer.
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 missing useful things, because exact change isn't easy.
The PR which is hard to review may mean that the code isn't understood the same way by different people, and this is a signal that some discussion is needed. Unfortunately often that's not done, and after some efforts PR is pushed through, while misunderstandings grow.
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 missing useful things, because exact change isn't easy.
The PR which is hard to review may mean that the code isn't understood the same way by different people, and this is a signal that some discussion is needed. Unfortunately often that's not done, and after some efforts PR is pushed through, while misunderstandings grow.
"Reduce the scope of your PR" a reviewer comments on a PR for a project that hasnt meaningfully addressed its technical debt in years.
I think this may be a valid point, and cleaning up could be seen as a separate concern.
The frustrating part is ALWAYS needing to clean up before making any contribution.
So following the advice, you always need two PRs.
The frustrating part is ALWAYS needing to clean up before making any contribution.
So following the advice, you always need two PRs.
Depends on the cleanup no? I mean, if it's just obselete version of one library, and the ensuing lockfile change, it doesn't really matter. If iys upgrading to a new language/framework however, yes, please do so.
I'm not saying cleaning up separately isn't warranted.
But it isn't always legacy that needs cleaning up.
It can also be mess created very recently by active team members.
So on the one hand, a separate PR for the cleaning up is warranted, but since it isn't being matched with a separate PR for introducing the mess, the double standard is magnified by introducing more book-keeping for those who clean up after others.
For that reason, when working with messy people who are not held accountable, I usually clean up in separate commits in a PR. This way, when looking at the blame for the logical changes that I introduced, and when reviewing, this is separate from the cleanup.
But it isn't always legacy that needs cleaning up.
It can also be mess created very recently by active team members.
So on the one hand, a separate PR for the cleaning up is warranted, but since it isn't being matched with a separate PR for introducing the mess, the double standard is magnified by introducing more book-keeping for those who clean up after others.
For that reason, when working with messy people who are not held accountable, I usually clean up in separate commits in a PR. This way, when looking at the blame for the logical changes that I introduced, and when reviewing, this is separate from the cleanup.
My last team was like this. So painful
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.
I have a personal rule that I won't merge to master after lunch on Friday. I'd just rather wait until Morning.
Yeah I have this personal rule too. I have another rule for any interns I have: if you break something, you have to fix it AND add tests ensuring it can't be broken again (although I'll be fairly pragmatic on this one)
Not sure if you mean to production but we have this rule. We only deploy bigger things to production on Tuesday/Wednesdays since that gives us enough time during the week to fix any issues without having it bleed into the weekend. It’s important that we don’t encroach on weekend time.
Changing code you have committed working on (as can be seen in the product management tool) without notifying you, which makes git return hundreds of merge conflicts when merging the main branch into your work branch -- basically ensuring you either can start over again based on the new code or risking drama when force rewriting the main tree without said unexpected changes.
Worst time it happened to me was the day just before the start of my Christmas holiday and it almost made me quit.
Worst time it happened to me was the day just before the start of my Christmas holiday and it almost made me quit.
Teams that don't take responsibility for their fuck ups. "Oh, that's your code." Yes, it's in our repo, but you wrote it in service of your needs. "We need you to help us get this out this week" well then you should have started sooner.
Had this happen recently. Their manager insisted we make the fix since it was in our repo. He was so rude about it that I pushed back and there was a long heated back and forth. Then a colleague found their PR and the associated ticket. I added them to email thread and included our director. Then radio silence for a couple weeks. In the end we had to fix it anyway.
"Hallway meetings" (even if virtual) which do not include all stakeholders and at which nothing is recorded. Just "oh yeah we decided" a week or a month later. When I was in a position to do so, my answer was "no you damn well did not".
micromanagement.
Hate it when director joins regular meeting and brings a lot of confusion with their little domain knowledge but speaking loudly thei ideas...
And also when people try to understand what business value brings shifting a button from right to left and talking about it for 40min.
Hate it when director joins regular meeting and brings a lot of confusion with their little domain knowledge but speaking loudly thei ideas...
And also when people try to understand what business value brings shifting a button from right to left and talking about it for 40min.
>>And also when people try to understand what business value brings shifting a button from right to left and talking about it for 40min.
"Bikeshedding." Ever since I learned that term I realized how much of my meetings are just that :(
"Bikeshedding." Ever since I learned that term I realized how much of my meetings are just that :(
[deleted]
"Seems fast enough to me," when something is clearly slow.
So instead we're just not going to optimize anything, and every tool just gets slower and slower and slower.
So instead we're just not going to optimize anything, and every tool just gets slower and slower and slower.
Scheduling {anything} for release in the 4th quarter.
It isn't going to make it, and it will annoy/discomfit/make life miserable for everyone.
It isn't going to make it, and it will annoy/discomfit/make life miserable for everyone.
When the culture is very hierarchical, so even small change requests travel up the chain several notches for approval.
Mis-handling public communications about releases of significance.
Mis-handling of public communications on significant outages.
Mis-handling of public communications on significant outages.
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.
There is no such thing as full stack. Unless the stack is super small.
A while back I went for an interview, they asked about my "full stack" experience and I started talking about the filesystem I was working on. That day I learned that the filesystem is not part of the "full stack".