Live data from Hacker News

Many software companies are a joke

liou28335.medium.com

291–300 of 377 posts

Re: Many software companies are a joke

#291

The issue the author is talking about, in my view, is caused by the natural lifespan of corps tending towards bloating middle-management. (Very hard process to fight). At the start the founder group are rutheless productivity-chasers. Then the corp expands to include the its-just-a-job group. Everything ticks along well, and at some point, the rutheless can't manage the group. So they hire followers to listen to thei…

I suspect a lot of this is survivorship bias. I suspect if one were to compare a large number of startups to one large company (or even better a portfolio of large companies), the “ruthless founders” will significantly underperform the middle management in large companies even after adjusting for the inherent advantages large companies have. The only reason the “ruthless founders” look better is because we usually on…

sure, it's about ratios

a business needs an executive, and at scale, it needs middle management to implement the general strategic direction set by the executive

if there are more middle-managers than this requires, they start trying to own non-strategic issues -- which is where you get large numbers of meetings about non-issues

Re: Many software companies are a joke

#292

I was reading https://danluu.com/sounds-easy again today, and when reading this article I was reminded of a particular section: "Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and…

Is there anything new ever written in this space or is everyone just repeating what Fred Brooks said in the 1970s?

Re: Many software companies are a joke

#293
post #171

Earlier quoted context omitted.

> Not recognizing that after 20 years in the industry is baffling. Baffing, cognitively? Or is this a value judgment? Have you observed human nature particularly in the last ten years w.r.t. echo chambers?

"Consensus about any topic is impossible because political speech has become more polarized"

Yes -and- it isn't just political speech. Many developers naturally feel more comfortable with certain information sources (forums, blog posts, people, etc) and form self-reinforcing tribes around e.g. programming styles, languages, habits, editors, processes, and so on.

Re: Many software companies are a joke

#294
post #168
post #38

Earlier quoted context omitted.

Author is every software engineer I hate to work with. One who thinks that code is the only truly important part of a project. It's not. "Delivering a product that solves end user needs and is as maintainable and reliable as possible" is the only truly important thing, and only some of that is code. Meetings generally aren't for developers. They're to keep everyone else involved with the project sync'd up. Do I and e…

> Author is every software engineer I hate to work with. Wow. This looks like a quick and harsh over-generalization. This sounds like a pretty deep-seated lack of understanding.

How we write here on HN is important. Write once with overgeneralizations, and then N >> 1 (many more than one person) have to read that sloppy thinking. It is lazy writing/thinking and, in effect, disrespects our collective experience.

Re: Many software companies are a joke

#296
After working at several large $techCompanyAcronym companies, I agree with the author's premise, but I don't agree that the time gets wasted in planning/bickering over color palettes. I also don't agree that there's a CYA culture in large companies, at least not at the front line worker level.

Here are a few issues I see:

A lack of achievable goals. They tend to be massive multi-year long initiatives. It's hard to feel any sort of urgency from a 2 year project. Even if it's broken into 6 month long chunks, it's hard to feel urgency given if you slip the first milestone, you've still got 1.5 years to go. Additionally, large projects suffer from analysis paralysis. I don't think this is a malicious thing, I think folks genuinely don't know what it is they need to do.

It's easy to hide in a large company. Generally, the longer it takes you to be productive the longer you can do nothing before getting noticed and/or actually terminated. An 8-12 month ramp up time is average in my experience. When the company only has 20 engineers it's easy to find the ones not pulling their weight. When you have 100k engineers, it way harder, and stack rankings, and the resulting hire-to-fire, are put into place.

Mandatory and optional training and non-work related events consume a lot of time. By non-work I mean things not relevant to the team's objectives. One could easily do nothing by participating in all the summits, trainings, meetings, wellness events, interviews, debriefs, design reviews, security reviews, etc.

Re: Many software companies are a joke

#297
post #167

Every company I have worked at has been the same - very depressed people who have no enthusiasm for anything slowly dying as they sit there staring at the computer. It is in stark contrast to the physical labour jobs I have had, which have been very lively and happy places to work. I think the assumption that these people want to program for more than 2 hours per day is probably wrong, and you will just burn yourself…

People burn out on programming for two reasons: 1. For whatever external or internal reason, they fail at writing good software for a long time 2. The job takes a terrible physical toll (lack of exercise) Neither of these are improved by larping at corporate business stuff around the office. Maybe line cooks at slow restaurants have fun getting high and chatting while they cook, but many many jobs are physically pain…

I feel like line cook is the worst example of a fun physical job. Most of the line cooks I know are incredibly burnt out and survive their 12 hour shifts by abusing cocaine and amphetamines. Landscape contracting seems much tamer by comparison.

Re: Many software companies are a joke

#298

Earlier quoted context omitted.

It's always fun if a product is based on 20 year old code where there are parts that nobody can touch because there's nobody around who understands what's going on there. I once saw a flight-training software (I think it was for helicopters?) where the physics engine just didn't get touched because they don't know what's going on. Every change was essentially a hack around this blob of years old, highly optimised but…

I once saw a flight-training software (I think it was for helicopters?) where the physics engine just didn't get touched because they don't know what's going on. This is an interesting case, because it's something that I probably wouldn't document. Code should be readable. If you're writing down how your code works in a document then something is wrong with the code. Documentation can't fix an incomprehensible codeba…

Normally working out how a complex piece of software works from only the source code is called reverse engineering.

I've encountered this "readable code means I don't have to document" idea before. I have no time for it, it's just wrong:

1. Important things aren't easily visible in the code, most commonly why the code does a particular thing. "Readable" code, which is a very subjective standard, can only tell you what it does but not the underlying rationale.

2. Writing docs often exposes the fact that the way the code works, or is expected to be used, doesn't make sense or is sub-optimal. If your docs include lots of caveats or explanations of nonsensical behaviour then it's a good hint you should go back and think again.

3. Figuring out stuff by reading the code is often drastically slower than reading the docs. That's why all professional APIs have good docs and people grumble and moan when expected to use code that doesn't.

4. The sort of people who argue this, in my experience, often don't actually write readable code, they just tell themselves they do.

Re: Many software companies are a joke

#299

I was reading https://danluu.com/sounds-easy again today, and when reading this article I was reminded of a particular section: "Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and…

I was having a discussion with one of the people higher up in the org chart about why we need to move beyond a pizza-box development model. Currently what happens is that the CEO (small org, 10 people, he's effectively the CTO) makes small-talk with a dev about a feature that needs to be developed. The dev then goes and builds the thing based on the discussion (a week-10 day sprint), takes the resulting work to the C…

That description of "pizza-box development" (unfamiliar term for me) sounds pretty good actually? Seems pretty agile: informal planning, time-boxed sprint, revisit with stakeholder, repeat. It gets so much worse when the implementers are further from the stakeholders or customers. What's the issue there?

I've also worked in consulting and appreciate the explicit requirements, but I find the formality much less efficient than the process you describe earlier. It ends up being very "waterfall" and exactly the approach the Agile Manifesto attempts to counter.

Perhaps you prefer a more waterfall, hierarchical development process, or the companies (big ones) or industries (highly regulated) that necessitate it?

Re: Many software companies are a joke

#300
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…

It does seem like that's how things are. I wonder if it's how things have always been? And if not, what's changed?

This is a very interesting questions. I don't have an answer.
Post reply on HN