Live data from Hacker News

Many software companies are a joke

liou28335.medium.com

311–320 of 377 posts

Re: Many software companies are a joke

#311
post #230

Earlier quoted context omitted.

Well said. I think the key point you make is that we are paid to maximize the value of the business . If the business isn't profitable, we could all lose our jobs. Too many IC feel that if the company isn't maximizing their personal effort they are inefficient and wrong. However, sometimes more value can be added by NOT writing more code or more documents. It is sometimes more valuable to throw away a bunch of comple…

It's kind of trite to say that though. It's the business's job to ensure that the skills and resources at its disposal are put to good use, not yours. We're not all a bunch of mini CEOs.

In my view the most effective organizations are made up of mini CEOs.

When you read about organizations which were highly effective there is usually a common theme of management by objective and giving people ownership. “The HP Way” and this speech by Rickhover are two such examples: https://govleaders.org/rickover.htm

Re: Many software companies are a joke

#312
I like my own space. I'm definitely introverted. But shit like this is inexcusably antisocial and I question why it was even posted.

You wanna be a s00p3r lean, high-volume company with actual impact? Good luck. 'Bloat' scales with accountability.

That's a bit invective of me so lets play out a scenario. Its not a real scenario - this never happens at an actual software company, because the incentives all hit each other at once and its not explicit. Its not even guaranteed to happen all at once!

But this drama does illustrate the incentives, to the extent I can demonstrate a point. Please read the below as an exposition rather than a testable hypothesis.

Lets say you wanna be a lean, multinational corp providing a crucial service to high paying clients. And you do it! Congrats, you, the lead dev, and a CEO who handles 'the rest' now have a strong user base, but also a lot of opportunities to be sued if your product is actually as crucial as you suggested it was and doesn't deliver. Wait.

Oops, you got sued, and you were (morally) in the right too! But fined all the same. It's a big fine.

'Never again' you and the CEO say. So now you need to hire lawyers, who advise you that to protect yourself legally, you need to monitor your service and have evidence that backs up your claims beyond 'we designed it to do that'. So now you have analysts! You are monitoring for uptime. For security. For correctness. Et cetera.

Now you have an analyst team and a legal team on top of dev.

But eventually your staff base grows. At some stage, payroll gets out of hand. An accounting division happens.

Accounting has many jobs. One such job CAN be to lower expenditure.

Accounting look at the COGs and notice that the dev team are spending money on a bunch of software but there's nothing written down as to what it does. They aren't expected to discuss their decisions with dev, so they don't.

So a budget is set up by accounting based on their expectations from similar industry. Spending on tooling is among those cut. Devs complain. Work slows. The analysts complain. The CEO is annoyed at the excess spending and the slow devs. The devs are mad at how out of touch the CEO is - after all, the accountants screwed up right? Why is the dev team to blame? Things were WORKING before! Why does she instantly take the analysts word as gospel?!

The CEO doesn't care about the devs or analysts to that extent though - she just wants the damn product to be shipped to spec so the company isn't sued again. But she recognises something needs to change.

The natural solution is to air everyone's expectations at once. A meeting is made to make sure these show-stopping issues don't show up and a cohesive company vision can be reached.

Devs have to spend time in meetings to help accounting, analytics, legal, and now marketing (since growth has slowed) not tread on their feet, and additionally prevent dev from treading on their feet.

Dev team is mad. Not only are they losing coding time, but now they feel bossed around by other departments. They were doing so much more before these other BLASTED LEECHES came in and spoilt everything. Something something 'I could do it better' something something. Cue 30 replicas of this article, complaining about Working With Other People. If you're lucky, there might even be a touch of Ayn Rand laced in. Or Marx! Truly a lottery of philosophy.

Eventually some devs break off and start their own schtick, and make a decent living for a while - maybe even for a lifetime, if the project is well scoped and managed!

But the less cautious startups? Well, if they don't deliver...

What was my point, aside from apparently being a hypocrite who can write edgy scenarios but is mad about reading them?

What i am trying to argue is that the other departments are there for an explicitly profit-generating or loss-mitigating reasons. And more than that: I'm saying this should be fairly obvious and that the dialogue needs to move on from this point.

More explicitly: I can understand working for a smaller company and enjoy the environment, but the constant whinging about megacorps being slow for devs and highly specialised/myopic is lazy thinking. Of COURSE they're slow. Of COURSE there's lots of documentation and meetings. You get paid a secure and comparatively higher wage for those inconveniences.

Re: Many software companies are a joke

#313
post #119
post #112

Earlier quoted context omitted.

Free market communism is probably more efficient, it just requires the kind of socioeconomic conditions that attract invasions from capitalists.

Free market communism as in? Free market economy with communist political system and allocation? Trying to parse your definition of the term, as it seems like any definition for communism disrupts the feedback mechanism that is a free market's primary (only?) advantage.

Not all communism is authoritarian/statist. "Libertarian communism" (sometimes known as anarchy) is socialist while allowing freedom of association and economic self-determinism. Historically, it has been strongly linked to the concept of republicanism and unions.

Re: Many software companies are a joke

#314
post #248

All these meetings, reports, plans and apparently useless things, provide insurance to the different stakeholders of the project. Projects fail in many ways, and you need everyone to feel safe. That's why you need to document things a lot, in order to say “this was explained in section 3.2.1 of the manual” when the other team doesn't correctly use your tools. And this is true for everyone, the finance guys, the produ…

> I never worked in a large company

I don't want to be rude, but it sounds like you don't know what you're talking about.

It often goes far beyond "insurance." A lot of this stuff is performative. Some people simply aren't good at executing, and many managers are focused on appearances and increasing the size of their kingdoms. Most can't allow themselves to be fine setting a roadmap and having it execute smoothly. There are all sorts of other perverse incentives and absurd behaviors I could go into, but the notion that it's all completely rational is silly.

Re: Many software companies are a joke

#315
post #262

> You will be asked to write a documentation for some little code you wrote. You will carry out tests. You will argue with your colleagues and supervisor on every decision you make. imagine thinking this is bad, unironically.

This is not what the article says, however. You misquoted in order to leave out the fact that the documentation is 50 pages, and some of the tests are useless, and arguing with colleagues is not always productive.

I removed the obvious exxagerations. of course nobody ask you 50 pages, so why is it relevant for the discussion? and who decides for how much documentation is needed anyway? the producer, or who pays for it?

also, you don't know which tests are and arent useless beforehand. code coverage may not be the perfect metric, but correctness is is semi-decidable anyway, so if one claims before hand that some coverage test is useless, he's most likely being lazy or drown in his self importance.

and arguing technical decision is always productive, so much that rubbe ducking is an actual methodology becuse even arguing alone is better than go head down with aggressive randomness.

Re: Many software companies are a joke

#316
post #230

Earlier quoted context omitted.

It's kind of trite to say that though. It's the business's job to ensure that the skills and resources at its disposal are put to good use, not yours. We're not all a bunch of mini CEOs.

From what I understood, they are talking about the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting. That doesn’t necessarily mean that the companies were poorly run - larger enterprises with more projects, teams and customers are going to require more meetings. Maybe he worked at poorly managed companies, who knows. The fact that he was asked to participate in meetings i…

> the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting

The author's complaint was that he only gets to spend 12-25% of his time on these tasks on a good day.

Re: Many software companies are a joke

#317
post #74

Earlier quoted context omitted.

Interesting observation. I wonder how much of the difference is between high physical activity, where often the work requires multiple people manipulating the same physical object (I hold the door, you attach the hinge), vs low physical activity, where often the work requires multiple people manipulating highly abstract concepts with purely imaginary connections (I write the API, you write the caller).

The physical/non-physical distinction might be a bit of a red herring, as this seems more a differentiation between repetitive and non-repetitive work. I.e. assembly line worker vs carpenter I'd hazard most people tend to dislike repetitive work, if they have the choice.

Our minds generally don't work well on repetitive tasks requiring high concentration with low interactivity. Yet, we're so irrational we can't see the obvious.

Take a "self driving car". Except... you can't really crawl into the back seat and eat lunch. No. Are you kidding me? You have to pay attention! You have to be ready to grab the wheel! A walrus could be napping on the freeway! Just because it's self driving doesn't mean you don't have to pay attention! Good god, what's wrong with you?

What's wrong with us, collectively, is we don't immediately recognize the absurdity of what they're saying. There's really something very very wrong with that person.

Re: Many software companies are a joke

#318
It's not a charity. Spoilers your company is making money hand over fist. Many company's boast a $600,000 or more revenue per employee figure. In many cases you are there just for insurance. I employ more people than I need on purpose because someone might up and leave at any moment and I have to keep operations going

Re: Many software companies are a joke

#319

Earlier quoted context omitted.

Buy a pizza for the devs, rip off the lid, sharpie draw the sprint on the lid while eating the pizza.

As long as the next pizza lid doesn't contradict the last one, that sounds like a good early-stage startup process!

Even if it does, it means we’ve learnt something in the middle. And at least the first box was in production.

Re: Many software companies are a joke

#320

Earlier quoted context omitted.

I would argue most meetings can be mostly replaced with ticket comments, documentation, emails, and chats. Devs are constantly expected to adapt and learn new things, while others apparently don't need to learn to use comments, documentation, emails, and chats to stay informed. Learning to use search features should be a good step as well. Outlook has search, Azure DevOps has search, there's Google, and most chat pro…

My experience is the following: Many meetings can indeed be emails. Developers tend to be only so-so at identifying which meetings these actually are. And developers are terrible at identifying which two week long email threads could have been a short meeting. It isn't enough to say "there are too many meetings" and be done with it. You need to identify which meetings can be removed - and that can be tricky.

Yes! My reply to "this meeting could have been an E-mail" is often: "OK, do you read your E-mail and respond promptly?" I love killing productivity-draining meetings and turning them asynchronous --BUT-- these meetings often get called because a decision needs to be made synchronously(now), and the decision makers can't wait two weeks while you get around to reading your E-mail and remembering to answer.

Those meetings that are simply "status story time" where someone reads a doc to the room? Yea, they should be removed. I don't think anyone likes them.

Post reply on HN