Hacker News Reader

Comment by pydry | Hacker News Reader

Large companies have a tendency to throw up all sorts of impediments to actually getting shit done.

Simple tasks can take 3 weeks because there are 7-9 dependencies throwing sand in the gears.

This not only provides plenty of cover for not getting stuff done it also saps the motivation to get it done quickly. Like, if X team sits on your request for a week that prevents Y feature from getting out are you really gonna be motivated to push it to production the second it's unblocked? Or could it wait another couple days?

Contrast that with a small startup where you barely need sign off to do anything - it's much easier to get into that pleasant loop of code -> deploy -> see customers use it -> dopamine hit -> motivation to code some more.

View on HN

> Large companies have a tendency to throw up all sorts of impediments to actually getting shit done.

early in my career i once worked for a spinoff of a very large tech company and was involved in a collaboration with the mothership, so to speak.

my boss pulled me aside and explained to me. "here's how this goes. time here does not work like time there does. what happens in one day here takes two weeks there, and if there's anything missing when you ask them for something, that two week timer will reset. so make sure when you communicate with them, you send them absolutely everything they need and then some. then be prepared to wait. for a long, long time. they will either cancel or eventually deliver something. whether the thing they deliver is relevant remains to be seen, but be prepared for it not to be. if this starts sapping your time and energy, bring it back to me."

he was absolutely right.

Reading this is making me sick. I am working on leaving my large company for a start up for this exact reason. Something as simple as changing a tag on a server requires submitting a request -> waiting for the reply that they are working on it -> getting someone contacting you 1-3 days later -> Confirming the changes you want -> finding the changes in place the next day -> telling them the ticket is closed.

You missed some steps between confirming and finding: seeing that it was done wrong, reporting that, wait 1-3 days for a response, repeat at least once.

Absolutely mirrors my experience when our small company was acquired by a large multinational of French origin. Why is France significant? Because their corporate culture is extremely hierarchical and centralised, similar to how their country is centralised like few others. Used to be we could turn small web apps into production in the course of a week. Nowadays even the most minuscule of features of an existing app will take a year to implement, because "central" will involve several project managers, somewhat related staff, external consultants, etc. etc. into the mix who spend a few months creating power points and excel tapestry under the banner of "change management" before even involving one programmer. Then, when they finally decide that the coders must be involved, stuff gets done quickly and without fuss, and often much less complicated than what was planned for us. Then they spend another few days sending each other congratulatory emails about how successful the project ended, apparently ignorant to the fact that they managed to spend a year on a feature that could have been implemented and tested in a week if they hadn't been involved.

Sounds like successful bureaucracy to me. At some point, change is difficult for a large organism. It became large by doing what it is doing and doing that well. The reality is that change is oftentimes destructive; what is so much clearly "better" to you is not clearly better to the organism. Slowing things down, getting many people to consider the new, is all purposeful and quite useful in reality.

Are you French?

I’ve been trying to get adequate access to Veeva Quality Docs API in their sandbox environment from some team at my job for two months, incrementally getting more permissions every couple weeks. My point of contact in that team is out all of December.

This is so I can build a POC of a feature that they can evaluate to tell me if they’ll give me prod access. No documentation or ui mock-ups will suffice for them to determine that. It must be a functional prototype. I’ve got two hours of working time overlap with their time zone.

Ultimately I expect it to take 6 months and be told no.

> Large companies have a tendency to throw up all sorts of impediments to actually getting shit done.

This. People get tired of the enormous overhead everything has, and gets lazy in the end.

I work for an ISP and I have my days, but some weeks I can't care less. I tried so many times to drill into people's minds how to not get tangled by complexity and then watching them just do the opposite...

Now I'm teaching myself programming so I can get out of this, but It seems I'm only going to upgrade my pay and be bitten by the same problems.

That's still an improvement, IMHO. And the degree to which you get bitten by the same problems depends on the size and culture of the company you're joining. Small, agile (usually young) companies tend to be better in this regard but you trade off other things like experienced management.

I hope so. I enjoy programming for myself, and taking some challenges in Python currently, I'm not sure how it will go as a job. Hope is confy enough to not regret the change, I'm pretty tired of having a low pay but high complex job.

Yes, and no. In both cases it can be still something of a lottery. In particular, I think you may find good management at small companies too, and I know you can find coasting incompetent managers at huge companies.

This is spot-on.

I'm used to small, get-things-done environments (startups, small dev shops).

Transitioning to working within a much more "corporate" environment (not that the actual dev team is any bigger) I struggled with the endless gatekeeping and bureaucracy because it was impeding us ... getting stuff /done/.

Once you realise they're not optimising for that goal, I feel less frustrated and have scaled back my efforts accordingly.

Want to do everything via PR, and have andless code-janitoring stylistic bollox ? Fine, I'll do that - but I'm not going to chase you to close it.

Want to spend hours in planning guff and pointless retrospective naval-gazing? Great, I can join the call on mute and get on with something else.

About 10-15 hours actual work per week is fine. "Office Space" is just as true today as it was when it was filmed.

I’m struggling with exactly what you describe. I literally LoLed at your code-janitor and pointless meeting comments. Something that would take a day at a small shop takes a week. It’s sad. I can’t do it for much longer.

Wow. A mere 3 weeks to get something done.

I worked somewhere once where it took 8 months to implement a two page sign-up process, and I counted about 60 people involved. A colleague said I didn't know the half of it and that there were actually more than 100 people involved.

I didn't last very long.

One of the reasons I left a company recently, despite it getting better, was how it took over a year before I could start working on SSO (despite it being critical, super-duper-high priority item) because it took 3/4ths of a year before we started getting user data necessary, then I spent fixing stuff that atrophied due to similar issues.

We were also over a year into "how do we setup direct access between on-prem and cloud" where I stopped attending meetings because within two or three meetings we always got back to starting point, whereas I joined the first meeting with reasonable, implementable solution.

> where I stopped attending meetings because within two or three meetings we always got back to starting point

This is a reliable litmus test for company dysfunction: how many people are in meetings & do meetings end with clear, concrete decisions?

I repeat these exact same words on each retrospective of my new scrum team with 16 people. The amount of overhead is insane and I've simply started not showing up to some meetings and just asking for conclusions. Usually, there aren't any or it has been concluded that another meeting is neccessary.

I remember a certain retrospective and being called out for not participating enough.

I was one of the few people dealing with outage at the time, which was known to project management... (And we had to deal with said outage with laptops on knees in overfilled conference room)

impressive!

Whrereas I (alone) finished two client projects this month (programming) and am starting the third. Help colleagues with their stuff, and am supposed to work on an internal project ( client projects are merely a distraction from the internal project ). I'm also supposed to make a certification ( I'm not sure whether in my free time or not ). I'm paid for 24h a week. And I have bad concience every standup because I didn't manage to finsih more the day before.

At a previous employer we had an extremely urgent escalation from a very large customer which had made its way even to the CEO given the visibility. Meeting is scheduled with customer, problem reviewed, initial action items identified.

Also, the next sync up meeting is scheduled by the customer... for about 5 month later! So much for urgency.

OTOH, there's great life balance when everything isn't a mad rush to complete everything by tomorrow. A lot to be said for a sustainable pace of work that can be maintaned for an entire career, instead of the agile sprint model where you're expected to be running at 100% mental utilization forever. Which isn't sustainable by any human, so just leads to burnout in a year or three.

It took us five years to get our customer (the Oligarchic Cell Phone Companies) to add some additional information to one SIP header we consume.

Yep. Or never mind dependencies: you're simply getting interrupted so many times that between zoom calls, slacks, and emails, that a 2 day tasks turns into 2 weeks.

Slack culture is very toxic to productivity. Numbers of channels grows forever and at least in the places where I've been that use it, there's an expectation for a reponse to everything within a minute. So one ends up all day just looking at it, can't get any work done with interruptions every couple minutes.

Yeah. And if you don't respond immediately, you starting getting friendly reminders. "Have you found the problem yet?" "What do you think it is?" "Can you fix it soon?" Ugh.

I see this regularly at small companies, too. They add process they think is necessary but don't have the human resources necessary to ensure these don't become blockers.

It's called: arbitrary. Someone in power makes up a new rule or policy based on what they think. Authoritarian government.

It's usually a result of cargo-culting: companies think that if they imitate what the big boys are doing they'll see the same kind of success. You also see that with hiring practices or adopting technology such as microservices or Kubernetes which are overkill for their real needs.

Three weeks? It took me 6 months to get a dependency installed and they didn't even install the version that I requested.

Oh man, the relatability of this made me laugh

Until just recently, I couldn't increase the disk and filesystem of a server without waiting for weekly approval. And there had never been an instance of someone using lvm breaking anything... Same with adding RAM (these are VMs). If you haven't read Pournelle much, he calls this the Iron Law of Bureaucracy.

the startup i just left did this. they have about 300 employees, and are pre revenue. the process to add a field to an api response was incredibly tedious and sapped my motivation completely.

Adding a simple endpoint to an existing API somehow ended up being a 3-day back and forth in my latest GitHub PR. Worst part is that I knew beforehand that was going to be the case, since it happens all the time. Can't se myself lasting long here.

But what exactly was the problem here? That the PR took 3 days? The back and forth comments? That you needed to make a PR in the first place?

Because any of this things seem pretty natural to me, specially if you are a new dev in the team and are not familiar with the style they use.

But there may be some details missing that will explain the situation.

One thing that can reduce the PR back-and-forth is to use linters in pre-commit hooks and/or pipelines. For example, if you are using Python then run flake8/black etc automatically on the committed code so you don't end up with bikeshedding over stupid things like line length and bracketing style. This can be enhanced by automated services such as Sonarcloud to catch potential security issues, code repetition and so on.

Reply on news.ycombinator.com