Live data from Hacker News

Many software companies are a joke

liou28335.medium.com

261–270 of 377 posts

Re: Many software companies are a joke

#261
post #219
post #98

Earlier quoted context omitted.

> Imagine a dentist who is passionate about pulling teeth out ... That's a great metaphor for code-before-you-know developers. A key difference between a big decision and a small decision is what it's like to change your decision afterwards. I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing. In the programming case, you may have went down a rabbit hole that wasn't corre…

I maybe wrong but let me paraphrase what I think they meant (and why I think it's a great analogy). I don't want my teeth pulled just because. If it's a fix to a problem - a means to an end - and there's no other way to do it , I'll consider it. Likewise, I don't want to work with developers who are super passionate about typing code into vim. I want to work with developers who are passionate about solving problems .…

Also, I see every custom line of code written as a future burden. Part of software engineering is effectively minimizing and managing that burden.

If we write 10,000 LoC for something that we didn't end up needing... the team's going to be tempted to wrangle that into the actual purpose instead of throwing it out.

So overly aggressive fingers on keyboard lead to more bloated results, as requirements drift during development and more code is written to target them.

Re: Many software companies are a joke

#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.

Re: Many software companies are a joke

#263

Earlier quoted context omitted.

It's always a worthy goal to try to improve communication efficiency, but it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in, and have an inflated sense of the importance of the code they're writing (or that they wish they were writing).

Yes engineers can be at least as ignorant as the "MBA business types" they like to scoff at. I haven't seen that in a good engineer though.

Oh I have! It is pretty much universal in young engineers, many of whom are eventually great.

Re: Many software companies are a joke

#265
post #195
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…

Yeah but you get tired of the fact that all of the low level business people abuse their "rank" to turn you into their personal assistant. If I have to help them with everything, why don't I just talk to the users directly and write the requirements myself? It would be faster, and can even save the paperwork. This is modus operandi for contractors. Why do I have to drag along these type of bozos all the time, and suc…

You should talk to users directly and write requirements yourself! And then teach the business people what you learned.

> Nobody complained when Steve Jobs delivered much more sharp-tongued rants than this article.

What are you referring to? Jobs alienated people all the time, people quit their jobs over things he said.

Re: Many software companies are a joke

#266
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 don't think it's about safety and stability at all, given how CEOs everywhere are _begging_ for their employees to innovate, be accountable and take risks. All this insurance is required because large organisations tend to devolve into "cover your ass" culture. People get automatically promoted by staying, so avoiding getting ousted by being someone's else scapegoat is the safest bet.

Re: Many software companies are a joke

#267

Imagine actually caring, my aim is to get away with as little work as I can while still earning good money. ‘No nonsense coding and learning’ cringe, imagine actually liking to write software. After 11 years of embedded dev, I can safely say I rather not write a single line of code ever again. This whole industry is 99% bullshit. Thankfully I could exploit it for a lot of monetary gains

As a worker, I like your attitude. As a manager, my attitude toward your attitude is entirely dependent on your competence. Nothing wrong with viewing work solely as your means for funding the important parts of your life.

I’ve been employed at my current company for 6 years now, I do what needs to be done but my feelings are stated above.

Complete opposite to when I was a bright and hopeful fresh graduate

Re: Many software companies are a joke

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

> provide insurance to the different stakeholders of the project

A good analogy. The lower trust the environment, the higher the levels of insurance required. But it's more than this, it's almost like the "busy work" is a form of "Proof of Trust", and the lower trust the environment the more Proof of Trust is required to be exhibited.

Re: Many software companies are a joke

#269

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 CEO which will then flesh out what needs to happen in addition to the work done. There will be some iterations of this process until the code can be merged into main and the feature completed. It's not horrible really but it can be way more efficient. I'd really like it if we can move beyond this seat-of-the-pants programming and have a more robust documentation process. I've been a part of feature mills like that, I've built my own products (unsuccessfully business wise) and I've also done contracted work. Out of all of these I was most productive when doing contracted work. I think it was due to the customer having to really spell out all of the things wanted in the work product. The requirements analysis was far better than anything else I've ever touched. I don't know why it should be any less detailed when it concerns your own work. You should beforehand be certain that you know what you are about to build. You should state it in a document. The stakeholders should sign off on it being what they want built. All of this takes time and it should. The engineering part of it is mostly trivial. The hard part is building a consensus on what should be built.

Re: Many software companies are a joke

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

>> The funding bodies want us to detail all expenses and justify all the changes in the plan, because they don't want people to say that the public funds are mismanaged. This is just an example. We also write tons of useless papers, to justify that we are productive with this money. See how the solution is causing a different form of the problem it's trying to solve? I agree with your premise, but sometimes I think h…

I could see that working for a set of moonshot efforts at startups who primarily only have to keep investors interested, or some subset of research projects at FAAMG companies with money to burn.

But how could that work with big companies making contracts with other big companies as their customers? Doesn’t seem like they could afford to just “let many fail” as they could lose the customer’s trust.

Post reply on HN