Many software companies are a joke | Hacker News Reader

Many software companies are a joke

liou28335.medium.com

451 pointsopenplatypus368 comments

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 see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years"

Dan goes on to say: "When people imagine how long it should take to build something, they're often imagining a team that works perfectly and spends 100% of its time coding. But that's impossible to scale up. The question isn't whether or not there will inefficiencies, but how much inefficiency. A company that could eliminate organizational inefficiency would be a larger innovation than any tech startup, ever."

Communication scales extremely poorly compared to code and large organizations require a very different skillset than small companies. The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies.

There are also good and bad big and small companies. A well run big company is still going to have a large amount of communication overhead vs a small company.

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 completed work and not fall victim to the sunk cost fallacy. Sometimes a "worse" architecture is the highest BV.

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 instead of only being assigned purely code-related tasks isn’t very compelling evidence of a company being a “joke”.

I tend to find that where the PO/product job doesnt have to be shared with developers the velocity and quality of the product improves considerably.

I dont think that relatively speaking companies that dont do this are horribly run since it seems to be the norm but I can see why somebody who isnt used to it would rant.

In general larger companies do everything inefficiently. It's to be expected. Small companies wouldnt exist otherwise.

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

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

An excellent illustration of the difference between a professional and an employee.

> The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies.

I think the point is that very little actual business value is being created. This not necessarily due to "actual business needs" but because of deterioration of culture over time and the inevitable principal-agent induced issue of managerial bloat.

Instead of accepting that increased communication needs will slow down everything to a crawl, how about eliminating needless communication? Thats how Amazon does it, and look where they are now.

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

But that goes for everyone, until you can put it into numbers which aren't gamed. That's what is being challenged here. Do the communication methods as they exist today provide value, and to what degree? Do we have actual numbers?

Whenever the "we hate meetings / the current bureaucracy" crowd criticizes the current state of affairs, the opposition tends to seek the high ground and go "well but you just don't understand what drives value". Meanwhile, there is a surprising lack of numbers regarding all this.

Ironically, trying to measure this better would inevitably require more bureaucracy! It's a good point nonetheless.

But I'll also say a positive word for qualitative reasoning based on experience being a good first approximation of things. If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right. I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.

>If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right.

It's one thing to consider it an approximation, it's another thing entirely to consider them "right" which is frequently followed with "so we won't investigate any further". Most of us don't live in situations where such decisions are actually critical. We can afford to criticize and experiment. Instead, this line of reasoning tends to be misused and shush any investigation.

>I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.

And you don't think that group, much like others, may be a little self-reinforcing?

It isn't "so we won't investigate any further", it is "we don't think it is the best use of our resources to investigate this" and in my view it also implies "but if you have a good idea for how to investigate it empirically, please feel free to do so".

I don't think "that group" is self-reinforcing at all. Essentially everyone who comes in with no experience comes in thinking "meetings are crap, communication is crap, we just need to write code". Most of those people (but not all!) slowly but surely change their minds as they gain experience. But every one of those people is an opportunity for the thesis to be disproven. Similarly, nearly every new organization is an opportunity to try something new. Google didn't start out with lots of meetings and engineering committees and design review processes. They started out just wanting to write tons of code. They didn't hire management (or "agile") consultants or bring in outside managers as they grew to come tell them how to behave like a big company is supposed to. The people who started out writing all that code and ridiculing bureaucracy are the same people who eventually accrued processes to manage meteoric growth.

I really don't think people are as narrow-minded and closed off to this as you seem to believe. People are hungry for a better way to manage organization growth, it's just a high bar because people have seen lots of these kinds of efforts, and frankly just get kind of bored of chasing "one weird trick to make everyone way more productive" again and again.

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.

> 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

If that's common and not being addressed, it must not be important. If it's not important, why mention it? Seems like victim-blaming.

"very little business value" is highly subjective. I'm sure that Amazon also has a lot of activities which generate "very little business value" under whatever measure you define.

Don't see how politics or "bickering over the pettiest feature like [...] what colour the chart should be" is what "deliver[ing] maximum business value" is about, as you put it.

The amount of energy and time spent on “politics” or “bickering over petty issues” is usually highly overstated by bloggers.

It’s easy to understand why. The 15 minutes spent bickering over the color of a button will be far more likely to leave an impression and remembered vs the 90 mins spent on ordinary, necessary and useful discussions in the same meeting.

Eh, it's been causing a lot of issues over a long period of time at least in my workplace, and it's been dragging projects that should've been 2-3 days to 2-3 WEEKS.

I'm sure it varies for people (which is why you're downplaying it), but for at least some of us, it is simply the truth, the reality we have to face every day we go to work.

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.

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?

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.

> a week-10 day sprint

A week-10 day sprint on _one feature_? They haven't drunk the scrum kool-aid yet. Just wait until they do - then every feature will be a "story", and no individual story will be allowed to be assigned more than 8 "story points" (which for some reason means "one day"). If you think a "story" will take more than 8 "story points", you'll be asked to break it down into "subtasks" of no more than 8 "story points" each (you'll be asked to do this accurately in a few minutes in a standup meeting). Trust me, if you tell a higher-up non-programmer that there's anything wrong with the development model, they'll hear "we need to move to the 'scrum' everything-is-mandated-to-take-less-than-a-day development model".

Don't scare us like that :-)

The most successful software company I have worked for used your “pizza-box” model all the time. With 150+ developers. It worked extremely well. The worst software company I have ever worked for spend 95% of its time documenting things and 5% of its time implementing things. It took forever to get anything done.

Somewhere betwixt those a happy medium lies

Not my experience at all (25+ years of experience working for companies in 5 different countries). However YMMV of course.

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

Not sure I understand the thought behind the statement so apologies in advance if I am barking up the wrong tree, but communication scales beautifully in many different contexts. It's almost like a superpower if done right. I do agree though that poor communication does scale extremely poorly if that's what you meant.

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 product guys, the programmers, the marketers, everyone. Providing insurance to everyone is very expensive, but it makes the large organization stable. If everyone worked like cowboys in an small company, then the large company would disappear in a large fire of infighting.

I never worked in a large company, but I work in academia, and we academics are also working on insurance a lot. 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. This makes research very difficult. If you really want to do science, you should become rich and do it from home, like Nassim Taleb does, but in Academia we must work on all this insurance stuff, like in corporate world.

That's how things are.

>> 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 having multiple efforts in parallel and letting many fail might be more productive than going the safe route.

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.

Big corps doing big projects are already doing risky stuff. Those big projects often fail to deliver the expected result within the expected time frame and budget.

Devils advocate: Having multiple efforts in parallel with the crazy overhead would probably give at least one of them a fighting chance of succeeding. Who cares about the ones that failed when the whole big project worked for once.

I see, we are referring to an internal mechanism for the vendor to try multiple routes to meet the customer ask - this makes more sense, but I could see a lot of traditional enterprise customers being hesitant to buy in if they were made aware (if you could do it with only the partial resources that delivered the “successful” solution, why am I paying for the others?)

Most software is essentially rented. It already written and has zero marginal cost. The vendor is using the rent to develop the next version. An exception would be specific contracted work, or bug fixes under a maintenance contract. How that next version gets developed is really up to the company.

Or we can just continue getting great stuff like windows 10 and 11.

Well the original article talks about how the work that a software company does in a year, can be done in a few months by a freelance developer with zero bureaucratic overhead. But which freelance developer? For every freelance developer that succeeds, there will probably be ten or a hundred that fail, or push out a mediocre product. This is what all the meetings and design docs and testing is for. To increase the chance of success.

I'm sure the same can be said for the academic world. If I was in academia and I was given funding without oversight, I would probably waste it all on researching things I found interesting but weren't necessarily useful to anybody. If you don't want to have to justify your expenses, then just fund it yourself.

> multiple efforts in parallel and letting many fail

I actually worked for a company that did this for a while and the results were amazing. There were multiple tasks, each task being a way to improve or cost-reduce a part of the machine we built. Each task had 3 teams attempting to solve it a different way. We met back 6 months later to compare/contrast the outcomes. I've never seen so much innovation in such a short time. The job was a blast for those 6 months because you were only limited by budget (we had to build hardware) and imagination.

And then, of course, since it was a multi-billion dollar company, the entire thing got shut down and we went back to business as usual. But at least I still remember it 10 years later :-)

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.

This. Incredibly risk-averse behaviors indicate an industry ripe for disruption.

>CEOs everywhere are _begging_ for their employees to innovate, be accountable and take risks

Executives like to say these things, but what they say and what they mean often diverge. The nail that sticks out gets beat down.

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

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.

Whilst I agree with a lot of what you say, this part:

> We also write tons of useless papers, to justify that we are productive with this money.

doesn't seem to be a logical part of your argument. Writing useless papers is not a form of insurance nor proof that work is being done. It's rather the end product, what all the 'insurance' is trying to ensure gets done. The fact that academia outputs a torrential flood of useless papers has little relevance to the corporate world where the final product is, hopefully, useful despite sometimes being inefficient to get there. After all companies that produce truly useless outputs do eventually get the rug pulled from underneath them, either by bankruptcy or forced sale.

Yes and no. A scientist should generate knowledge and insight, the scientist must discover things. The only way to prove that to a bureaucracy is through papers. It should not be the end product, but it has become the end product. In any case, it is still insurance, if you publish cited papers, you are safe, even if their contents are useless.

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

I believe (s/t)he(y) means in the sense of risk management. A lot of things are done to ensure that certain risks are minimized.

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 their orders and thereby manage others. In this sense middle management is really "corporate following".

Now you have the its-just-ajobs, rutheless-productives, rutheless-leaders, and leader-followers.

When the corp grows too far the balance in these populations is thrown way off (by, often, the shortsightedness of the real leadership in balloning middle-management to cover for them).

At this point all the meaningful decisions are still held by the exec, but middle management are now so large they have to "find something useful to do", which is regulate all the meaningless decisions.

At this point most of the ruthelessly-productive leave, and you're left with the justajobs, leader-followers and the few clueless productives who'll destroy their mental health trying to grapple with it all.

this is the gervais principle

Same phenomenon, slightly different analysis.

The gervais-style analysis mystifies some of the issues it describes. The heart of the group dynamics is "leader vs follower", "rutheless vs clueless" and "transactional vs passionate".

A startup is largely "passionate rutheless leaders", it grows to include "transactional ruthless followers" (its-just-ajob), then to "passionate clueless followers" (middle-management). At this phase its highly stable... you hire in "passionate rutheless followers" (ie., more actual workers)... who also need more middle-management... and at somepoint this becomes unbalanced due to poor executive incentives.

That gives you your large population of "passionate clueless followers" (ie., middle-management), and the death of the productive phase of corp. action, into a more rent-seeking (or death) phase.

In gervais, "losers become sociopaths" in a mystifying way; and likewise the "clueless" population is inexplicably unpromotable. My breakdown, for example, clarifies why: the "clueless" population never become rutheless-leadrs as they arent leaders at all. They're followers.

I think muddling "transactional" dispositions with "rutheless" ones also mystifies the issue, under gervais, the "noble sociopath" is hard to explain. Really, its that they're both passionate (internally motivated) and rutheless.

---

NB., rough definitions: "leader vs follower" (I command vs. I am commanded), "rutheless vs clueless" (success requires it vs. virtue requires it) and "transactional vs passionate" (external-reward vs. intrinstic-reward).

"Passionate ruthless leaders" also aren't guaranteed to stay that way as the company gets more established.

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 only talk about the successful ones because unsuccessful ones have disappeared.

Middle management is more successful and ruthless founders are less successful than immediate appearances would suggest.

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

Perfectly describes my last job.

> the few clueless productives who'll destroy their mental health trying to grapple with it all

Ah. Damn. Thanks for the reminder.

I am 100% sure I can dramatically improve the productivity and bottom line of any software company by simply firing 50% of middle management and using the money saved to hire good software developers.

I tend to think most of engineering is rather mundane but potentially very rewarding. I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out.

A project that I quite enjoyed involved months of investigation work, finally solved by tweaking a single software parameter that dictated how far a release mechanism moved. The number of internal/external meetings I had to demonstrate that this can indeed fix the problem could have seemed silly but it was also very reasonable given the risks involved.

> I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out.

There was a case here were an (employed) dentist was apparently bored and started to drill and fill perfectly healthy teeth. Iirc, criminal charges were filed.

Malpractice because bored (or feeling undervalued/underappreciated etc.) isn't just a problem for SWEs, but actual doctors. Also see: nurses and doctors inducing code blues to get to be the hero saving the patient; firemen becoming arsonists to have a fire to extinguish.

What are some estimates for the likelihood of these behaviors?

In dentistry? 1 of every ... ? 1,000 teeth? More? Less?

Not sure how many good studies there are on it, but the likelihood of an unnecessary operation occurring are strongly linked to that months financials.

https://www.theguardian.com/society/2000/apr/16/futureofthen...

> imagine a dentist who is passionate about pulling teeth out

That's a great metaphor for code-before-you-know developers.

> finally solved by tweaking a single software parameter that dictated how far a release mechanism moved

I think of this type of work as programming by other means. The problem couldn't have been "fixed" without all the discovery meetings and understanding. The "fix" couldn't have made it to production without political agreement.

Is that computer code? No. Is it building a solution to interact with a complex system (of people), using the primitives available to you (less than VP-style "Just do it"), to realize a desired outcome? Yes.

Others may be different, but I find hacking obtuse process problems and corporate political structures just as fun and rewarding as a nice piece of code.

> 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 correct but at least now you're 1 step closer to the right solution. You probably learned something and the business can write that off as R&D.

In the pulled tooth case, well, I'm not sure I want to Google that haha. Is it possible to fully replant a pulled tooth in a way where it's 100% healthy and you'd never notice it was pulled? I know there's implants but I mean the real natural tooth, complete with its root. I'm sure the process in any case would not be fun for the person who needs the work done.

You could classify one of these as a small decision and the other one as large.

I still think planning and understanding the problem before coding most things is a very good idea btw, but I would feel way more comfortable experimenting with code in short periods of time vs experimenting in a dental chair / operating room.

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. Code can be a means to that end, and by the time it gets to us we typically already know we need some code for it, but the danger is spending days or weeks writing code nobody needs and nobody asked for because it's "their passion."

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.

Meetings advance problem-solving insofar as they inform the code eventually typed into vim.

Some problems genuinely require a lot of this kind of deliberation, but most don’t. Some meetings aimed at this kind of deliberation make meaningful progress, but most don’t. The person who can terminate or pre-empt an inflated or stalled conversation with working code is extremely valuable.

Even if that code is not the ultimate solution, it has a definite shape and objective properties that can be investigated and weighed, which brings rigor to discussions that get lost in abstraction.

Organizational politics and entropy also tend to create too much talking: it is good for your career to present the work you’re doing as requiring a lot of collaboration (whether or not it does), it is easier to spitball in meetings than to actually solve problems (if you even have the skills), and you have to go to all the meetings you’re invited to (while coding time gets ruthlessly prioritized).

> imagine a dentist who is passionate about pulling teeth out

Exactly. Many times, the best code is no code. And making decisions about what code to write need meetings, unfortunately, or at the very least some kind of coordination.

There is really some questions that should be asked: Why are we doing this? For what reason it has to be done this way? Do we need to do this at all? What do you actually want? And so on.

Meetings are useful to clear up this stuff and at best result there is simpler solution, or not need to do work at all.

Yes, some kinds of meetings can be useful.

The author of the post, in my reading, laments petty meetings not productive ones.

However it is often the case that programmers "at the leaves of org charts" (to paraphrase another commenter) won't get to participate on meetings that can define if something can be replaced by "less code", let alone "no code".

In small orgs with a headcount of tens that's very easy for developers to grasp the value and the need for certain things.

But when you're in a 1000+ developer organization it is often the case that the reason you have to do something is because this is a requirement coming from two or three management levels above.

In some orgs, a lowly developer might even be unable to even sit at the table with the big boys. They might have a say and a good perspective in micro decisions, but not in macro ones. In this case, I can definitely see TFA being written.

To use the dentist example, imagine a dentist that's passionate about pulling teeth, but doesn't get a say on wether the teeth should be pulled or not.

The sad thing is that it’s a joke that many people don’t seem to be in on.

You get all these defenders coming out of the woodwork when people wonder what the hell all the programmers at say, Twitter, are doing. Supposedly you puny mind can’t comprehend the challenges of developing a website “at scale”

The real answer is, almost nothing. People are being paid very high salaries to do nothing.

Nah, most people feel some guilt at doing nothing when they're paid well, so my guess is lots of internal projects that don't go anywhere and that we never hear about. That's quite different to nothing at all.

Oh I’m sure that it feels like they are doing something.

But in a badly managed company each person is like a randomly oriented vector.

You sum them together and the end result is something near to zero.

It goes to minus something imho, wherein lies our problem.

> The sad thing is that it’s a joke that many people don’t seem to be in on.

On each of my job in my early career, I spent considerable effort weeding out people who got too used to such mode of work.

There are software developers with vastly different prior work experience, and expectations. People who do 30 minutes of actual coding a day, and ones who do 11 hours in coding sweatshops.

People who spent their entire career on 30 minutes of coding a day jobs, and think of themselves too much once they rise in seniority are the worst, and are the biggest source of dumpster fire/death march projects.

My third serious job in Canada: work in a consumer electronics trading company, upgrading their shipping system to get shipment status from DHL API, and submitting new ones. My predecessor, and ex-unit head wasted close to $1m, and more than a year, got SAP involved, invited many consultants, change managers, a project management contractor, and just been in the process of "fixing deficiencies" of his work by buying "enterprise SOA solution."

23 year old me called this bullshit on the second week, fought to have a serious talk with the company owner, rewrote a 10 years old steaming pile of PERL, and BASH scripts to Python, Postgres, and JS frontend in under one week, showed it working, and countered "You don't understand SOA!" protests of the unit head in front of the boss. He gets fired, I get a bonus the size of my annual salary.

Since then, my bosses always threw me as a "firefighter" on projects in crisis.

------------

We now have 2 major trends in the industry:

1. More, and more non-IT companies are trying to do software

2. A giant amount of newcomers to the industry who would've normally went working for banks, and management consulting companies eroding big IT companies as later grew with little regard to quality of hires.

But I'm encouraged to take a project it would take me a day or two to do and give it to a junior engineer to take weeks on it so they learn.

How do I get in on this? For the 10 years I've been in this industry I've never been in a job where I felt like I had it easy. It's always been a rush to get one project done then there's always something else in the pipeline. Whether those projects are actually worth doing is a different question...

Become a contractor or even more so a consultant. You'll often find yourself on dysfunctional teams where management barely knows what they want and things often never get done.

I wouldn't recommend it though since it's soul crushing.

Manager pay correlates with how many reports they have. So all of them are incentivised to making it look like their team is spread thin, so even if you don't have to work hard he will make you work hard so that he can tell his manager that he needs more headcount.

Careful what you wish for. It's not "easy" at places like that. It's just different. Instead of your work being keeping a system up and running putting out fires or implementing features or coming up with algorithms on a tight schedule... it's, instead: figuring out who is doing what, what you're supposed to be doing, what permissions list you need to be on in order to access X system, asking to be on that list and waiting, submitting a minor feature to code review that takes a week to go through because someone didn't check their email, rewriting a major part of the code in that review because someone came in at the last minute and didn't like some thing about it that was actually decided on weeks ago but they weren't looped in.

The amount of actual lines of code written by an average SWE at a BigCorp is miniscule. The amount of churn and spinning and hand wringing that goes into that code is staggering. But it's like that for a reason. There's just a lot of people.

It's torture, and in order to maintain productivity you need to have about 5-6 of these processes running concurrently, and it's why you get paid a lot of money to do it.

Do poorly at juggling that and making "progress"? Find yourself on the receiving end of a performance review where the label "meets expectations" actually means "you better start kicking ass at this, or you'll find yourself with no stock refresh grants for next year."

All the money and free food and so on is just a salve to try to make the whole thing less unpleasant. Some people get a high out of the process, while it drives other people slowly crazy.

(In my last months at Google the only part of the job I "enjoyed" was the week I was on-call for the first time on my new team. Because it was the only time in over a year where I felt useful even though it was quite stressful. That's how I knew it was time to pack it in)

https://goomics.net/364/

Sounds exactly like my current job.

It might sound exciting but its actually super depressing. You get paid mad $$ and in ur head ur think "what the ef are these idiots paying us for?". I ended up leaving just because it made me feel so useless i couldn't handle it anymore.

> a job where I felt like I had it easy

They don't have it easy either. They have to demonstrate at least once a year that they've "accomplished" something in spite of an entire organization of gates that make accomplishing anything nearly impossible. But they still have to figure out a way to do it, and it still has to be somehow represent enough to justify their pay.

There's scale, and then there's _scale_. And I can happily believe that Twitter is working at the latter.

It's like something like AWS or Azure. You can provision and deploy a K8s cluster? Awesome! Now, can you do that consistently for the next 100 thousand K8s clusters you're selling to your clients?

It's a very different kettle of fish.

I think regardless of scale, spending over a year working on edit functionality is endemic of something being horribly wrong organizationally. Maybe it doesn't even involve the software engineering groups (though it probably does). But that's simply not something that takes even a fraction of that time in a healthy organization.

That's what I am thinking. E.g. I am looking at lichess which has a massive user base and is developed by one full time developer and a few dozens volunteers. Twitter is obviously bigger, but I simply don't buy that you need more than 7000 people to run that site.

Maybe you don't need 7000, but software is even worse than icebergs (Only 30% visible). How many people at Twitter are there to fulfill functions we aren't even aware of? Compliance, privacy, legal, internal tooling, etc and god knows what else.

My experience at a tech company with around the same number of employees is that it actually feels understaffed in some of the areas I've seen. It's surprising how much responsibility some teams have.

The whole reason it feels understaffed is because there's too many people.

I know it sounds counter-intuitive, but software doesn't really scale linearly. Unless they're 100% independent, the communication overhead will always be there. Fred Brooks and all that.

With 7000 developers working in a connected system, it probably feels slower and less things get done than if there were less people.

It's not simple to go back to having less people, however. The architecture is most certainly tied to the organizational structure (Conway's Law), and firing people will make it worse in the meantime.

Please elaborate. It doesn't feel understaffed because of communication overhead or being in a connected system, but because of the level of responsibility (I.e. critical system) or product surface area a team is responsible for.

Sure. The things you mention (Compliance, privacy, legal, internal tooling) also have to grow together with the number of developers to scale. Not only those, but also support, QA, management, UX/UI. All those ares have to increase when the dev headcount increases. But since most of those need some degree of centralization and coordination, they can't escape communication overhead and orgs slow to a crawl.

Also, software development teams have to assume more responsibilities just to escape this communication/interconnection overhead: devops is a good example, you no longer have to depend on another team, but now you gotta do operations yourself. An example of avoiding interconnection overhead is having isolated services: now you don't run queries on team Y's database, but you still have to maintain that data on your own DB. Isolation is a good alternative, but it also has its costs.

Unless we're talking about 7000 software developers working on 400 completely different and completely isolated products and answering to different people, there's gonna be a lot of invisible communication overhead, or overhead because of the need to work together with the other 6999. We developers tend to abstract it as being "part of the job", even though it is definitely non-essential complexity.

Even consulting companies doing different projects can fall prey to that: I know lots of cases of internal frameworks/libraries/UI-toolkits being adopted to accelerate development, but they ended up being a bottleneck in development because the team that owned had a full backlog.

Honestly why I'm considering not starting my own business. Getting the product to work is the first 80% of the work. The remaining 96% is billing, authentication, and marketing.

I have been an independent consultant for almost my entire career - working with clients large and small, mostly on solo projects.

Took a FT job at a megacorp a few years ago and assigned a new project - I read the specs/requirements and in my IC mind thought to myself - if I was hired as contractor to develop this tool, how much would I charge? and how long would it take me? - and came up with 1 person, for 2 months, and would have been delighted to be able to bill $40K for it, but probably would have went it at $60K on a fixed bid (I always preferred fix bids).

Of course this wasn't a project I was bidding on, I was just the lead dev - the company pulled together a team of almost a dozen people and a budget of just over a million dollars with a 8 month timeframe to get it done - they also budgeted another $120K/year to host it when it was done on multiple big servers in the internal data center.

We spent the full million dollars and got it done - I did however have one small win and pushed them to micro-services solution in S3 and Aws Lambda and got the whole thing to run within the free-tier of an AWS account.

If you ever start a small software company, don't ever hire people that have only worked in large enterprises - they just don't know how to get things done cost or time efficiently.

Companies like twitter operate at a different scale. Lichess can off load hiring devs by using out of box solutions like paying for AWS, paying for cdn, using adsense to serve ads, utilizing thirdparty libraries, etc. For large companies, a lot of these are in house solutions, because at that scale, it could be cheaper, they wont as dependent on other companies for reliability, they have more control over where the data is being used or stored. etc.

It is funny because people who are unemployed are shamed for being "unproductive members of society", yet when you get out into the real world, you see all of these people doing nothing and getting paid lots of money, which is even worse than being unemployed in that context.

Anyway, it seems there is just a lot of money to go around and political and social favours dominate a lot of the decisions.

Free market capitalism is the least efficient allocator of work and pay, except for all the others.

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.

Free/Libre software is free market communism.

It's a free market but with the financial incentive system removed, but maybe social/status/religious incentive retained. Everyone does what they want but at 100% tax rate and the product is shared. Of course this only works in IP because it has zero marginal cost of consumption (and taxation!). In meat space you have the political problem of how the fruits of labor are distributed.

Who pays the developers of said software so they don't starve? The state? Then the state will decide what projects gets traction, such centralized planning is the main reason communism fails. Software engineers would then be more like scientists having to spend most of their time writing grant requests to motivate why they should get any pay, I really doubt this would give society better software compared to the current free market solution.

you could have a ubi system and then add incentives for devs on open source products that are used. Just a thought, I'm sure there would be corruption of this system too

Or the same thing, slightly differently, who uses FOSS? For-profit companies.

I think history has born out how FOSS incentives get entangled with a primary and majority patron.

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.

What part of it is most socialist? (Honestly asking and curious, I'm terribly ignorant in the more niche -isms of potential political-economic organization)

It's socialist in the sense of promoting mutual aid and communalism. The union movement was originally very influenced by these ideas. Unions, co-ops, FOSS projects, and community organizations are good examples of these type of political/economic structures.

If you're interested, Peter Kropotkin wrote a lot of books and pamphlets that are freely available.

This ongoing debate on productivity at small startups vs large companies will never be resolved by argumentation. But as we can see from this thread, corporate engineers overwhelmingly outnumber early-stage startup engineers. Therefore, they tend to "win" the debate by being louder.

The other thing about big corps is that they work on stuff that actually matters to customers for a long time, not "Our Incredible Journey" demo software intended to be rug pulled as soon as the founders get acquihired.

Yep.

With an addendum: it's not that they do "nothing", and that's the "problem". The end result is minimal, but the amount of work is still significant.

In any saner place it would amount to almost nothing, but for certain companies it is an Herculean task. And developers know it.

However due to the fact that the company hired thousand of coders, their communication overhead is now too massive. Their architecture also suffers due to the needs of handling those thousands of developers, so there's also a lot of work to be done in coding.

But the pressure is still there. Why hasn't your team changed the color of the button yet? "Why is it so hard?", "Why is it taking so long", etc etc

Jokes have been made about it: https://www.youtube.com/watch?v=y8OnoxKotPQ

The answer to all that was known since the 70s. Fred Brooks wrote a great book about all that.

> People are being paid very high salaries to do nothing.

I'm patiently waiting for some kind of deep-dive historical monograph to be written in the 2050s. What I suspect may have happened is that these companies overhire top talent simply so their competitors can't have them. For the actual work they do, it's massively overpaying. As a strategic investment to prevent said talent from working elsewhere or starting their own business, perhaps it pays off.

I am not sure it is even that rational though.

I think it is like brand name vs off brand. I just bought off brand oatmeal that was $1.98 vs the brand name was $3.50.

Someone buying the brand name is just operating on an unthinking heuristic that they only buy "the best". I am sure they would justify it after the fact that the brand name taste better even though it is just oatmeal.

So many decision points in society run on that heuristic IMO.

> to do nothing

The author puts it better: they do lots of things, all day long, but produce almost nothing.

As I commented elsewhere. They're not doing nothing. They're maintaining the organization. In a large company with a service that needs to be reliable, doing things quickly can result in things... breaking quickly and causing headaches when there's no consensus, etc. So everything needs to be done slowly and carefully and looping in dozens of people even for small trivial things. It sucks working this way, so they have to pay a lot for it.

Yup i recently worked at a company that had a lot of their base technology already built out. They hired a lot of new expensive talent and the talent was pretty bored so they made a big project to re-do all the existing technology that already worked pretty well. The results are less than good..

> People are being paid very high salaries to do nothing.

People are being paid very high salaries to be frustrated by explicit prohibitions on doing anything. Nobody gets to being good enough to be hired by a company like Twitter if they don't actually want to do real software development - management exists to crush that desire and ensure that nothing ever gets done.

They are correct.

It doesn't matter, and nothing will change in large corporations. That's not a bad thing, or a good thing.

It's just the way things are.

I spent most of my career in large corporations; many of those years, as a manager, where it was my job to maintain all that overhead the author complains about. I'm quite aware of the need for it, and a good part of my job, was trying to streamline the overhead, and shield my coders from it, so they could get more coding done.

Nowadays, I work on my own (mostly), and the difference in productivity is amazing.

I remember when I first read The Agile Manifesto, I was, like, "These guys really get it!" It was a dawn of a new era. The scales fell from my eyes. There was hope! There was a light at the end of the tunnel!

The headlamp of the 5:15 Express, out of Sheboygan.

Seeing how "Agile" is being implemented in corporate (and also small corporate wannabe) shops kinda took the wind out of my sails.

But large corporations seem to get done what they need getting done. Very often, it's fairly "klunky" stuff.

But that gives small shops an "in." If they can speak to the customers of these corporations, they could make some sales.

Then...it comes time to scale.

Let the meetings begin...

>>Seeing how "Agile" is being implemented in corporate

Dictionary definition of agile: "able to move quickly and easily."

There is nothing 'agile' about how 'Agile' is being done in most/many big corps - yet another buzzword sold by high priced consultants who like buzzwords, to top-level execs that think they know what they want.

One large corp I worked at, agile was really just an excuse to use minimum viable products in production.

We were agile until this shitty software was in production and then we would move on to the next project.

That was literally what we were calling having a startup mindset.

There seems to be unnecessary vitriol towards the author.

What he mentions about big financial companies (where software are for internal workflows) that is the life, and there are many of them and they are usually big employers.

And what he says "You see, we were always busy but seldom productive" is actually the essence of 'Mythical Man Month'.

About FAANG/MAANG, I have seen brilliant college toppers mucking around with html tags (but not able to get them right).

High salaries to a lot of software worker is a joke indeed.

I feel really sorry for the author, what he said does not deserve such mean comments.

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 out trying to do 8 hours of programming every day. In fact, many of these people burnt out long ago and just try to find anything other than programming to do.

I wonder though, it is true that these companies are very inefficient, yet they never get taken over or superseded. Why can't the group of rogue programmers that are more productive take over any of these companies?

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),

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.

Yes, although repetitive physical (exertive) work is a bit less soul destroying if only because it makes you too tired to think about it too much.

As someone who has dug ditches in Georgia clay, agreed.

Although I guess even the most repetitive physical task still has infinite physical fidelity, if you look for it. E.g. digging a hole in the same place 50 times vs writing the same code 50 times.

It's the middle ground that is mind-destroying. Extremely repetitive work lets you turn your brain off or redirect it to more worthwhile thoughts. Non-repetitive work keeps your brain engaged with the task at hand. The middle ground requires too much engagement to focus on other things but also leaves too many gaps to remain focused on the nominal task.

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.

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

They even made a movie with that premise (Office Space).

I work in bursts. I probably code 1/3 of the work week. The rest is spent on meetings, helping others, looking at logs/data and keeping up to date on tech. I think that is a healthy balance. There are many ways of adding value to a business.

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 painful, intensive and low-rest, and/or high stress and bad hours service work.

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.

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.

I think that many "software companies" are actually marketing companies that plan to make almost all of their profit from a product that has already been built. They're not necessarily a joke... it's just that software engineering is no longer their main business.

Finding out what needs doing - through meetings, documentation and so on - is very much a part of software development unless there is only one developer and he is also the only stake holder.

This isn't even necessarily inefficient, because productively doing work that isn't needed isn't helping anyone either.

One place I worked at some years ago...

We had this "important project" coming up, a certain big feature that was wanted in the platform. A project which would take about 6-9 months with the collaboration of various teams across the company.

I was involved but only in a helping role. One member of my team was involved but they were fairly inexperienced and so I was asked to go in as support.

After the first two meetings a number of things became clear. Mainly that the product owner for the project was extremely ambitious, clearly not knowledgeable about the technology involved and got very upset about any concerns or problems anyone would point out. They wanted "those stupid meetings" to be just for informing them of solutions and progress, not for discussing problems and options.

At the third meeting I made the mistake of mentioning that a particular detail, not too important, would be extremely costly to do as asked and that we would be better off doing it in a much simpler form. Unbeknown to me, that day the product owner went behind my back and asked for me to be immediately removed from the project. So I was. I didn't care much for it and I only learnt about that move much later, when I had already left the company.

Anyway, the project ended up taking about 2 to 2 and 1/2 years and it had to really reduce its scope in the end. And some of the people involved confessed that it was because of the product owner, because they had wanted people to "just build this thing I say and stop arguing". A lot of work was simply thrown away several times simply because of not having had the proper discussions it needed.

Yes, some product managers or whatever are terrible at there jobs, just as some programmers/engineers are.

Doesn't mean the job role is useless.

I don't really care much about what role was responsible. I commented it more for the usefulness of discussions/meetings.

This particular PO wasn't useless he was harmful. But the job of the PO is not useless.

Comments like this are why I find reading HN to be both depressing and cathartic at the same time. That's quite an achievement.

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

I agree. Actually, I have never met anyone who has liked writing code. How much code do any of these high profile programmers even write anymore? Linus, etc? If the leaders of the industry don't even write code, it says a lot.

I've been writing code for 16 years, which is now over half of my life.

I've been a full time software engineer (now lead) for the last 9 years. I've been in similar situations to this article where most of my time was spent in useless meetings that I disliked, I tried to improve things, to focus meetings, to improve our efficiency.

And all that aside I still love coding. Granted not all types of code, not the one I have to write sometimes at work.

Just now I'm starting another little fun side project that I've been coding on my free time these last few weeks.

All this is to say that coding is just a little tool, what you build with the tool is what can be fun. I think it can be healthy to write code that does fun things from time to time, even if the code you write at work is for the most boring aim.

I'm glad someone else said it. I want to think of problems that other people write the code to solve for me. I'm so tired of having an idea and no one but myself to work on it. It's led to a nice GitHub portfolio but I'd have rather that the stuff I built had existed already.

This is mainly because most other people can execute with a better level of completeness than I can in the context of open source dev. This is mainly because I don't actually like programming, but I sure as shit love the niche I am programming for...

I love writing code, nice to meet you. I know lots of people who love writing code. (Side note I also do see the value in meetings too.) I work with some relatively high profile programmers in my field (computer graphics) who still write lots of code, and will continue to do so until they retire.

Linus doesn’t write any code, in his own words, but that’s in part because his knowledge of software makes him better at leading people than writing code now. But Linus is not all leaders of the industry, many of them still do write code. John Carmack still writes code. That said, why should high profile programmers continue to code? What exactly does it say if they move into management?

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

> imagine actually liking to write software

I assumed you were being sarcastic, but re-reading your post and looking at the replies, I guess you're being serious here - I do actually like writing software. I'm not pretending or fooling myself - besides playing music and raising vegetables it's one of the few SFW activities I actually enjoy. I tolerate meetings because they're part of the price to get to write software and actually get paid to do it. What I don't enjoy are the unreasonable expectations around how long things ought to take or how predictable software development ought to be.

I agree in general. But the business is not a joke. It is a farce.

Why have one time reporting system when you can have two or three? Why not also add some burndown charts to that so you must report every hour left of that ticket? Why not add an additional spreadsheet with the same info while you’re at it to get a “holistic view”? Make it two or three different spreadsheets btw so you can separate progress from work hours and gummy bears. Cause abstractions are important CS.

“Gummy bears” is of course named different in each project. Remember to not mix up the gummy bears with mentos and the skittles. Some random management person will get insulted otherwise.

Then the boss tells you to only work on the highest prioritized tickets. 2 minutes later the same boss mails you a side-quest that takes a day. Then the same boss asks why you have not only worked on the highest prioritized ticket.

Then you show the boss 5 tickets and ask: What is the highest prioritized ticket? The boss replies: They are all the highest prioritized. Then you start to work on one ticket and the boss asks about the progress on another ticket 2 hours later.

Then the boss calls you into a meeting. The meeting is set for just 20 minutes but you quickly realize that there are a lot of people in the meeting. The meeting is about some design that nobody was prepared for, so everybody must read up and improvise. 2 hours later it is decided to apply the same kerning on each heading. What the problem was or what the solution solves nobody knows.

Now you get an encouraging email about what success that meeting was. But the day before some marketing person without prior notice or permission managed to do a fundamental configuration change leaving the system offline. You fixed the problem and saved the company tens of thousands of dollars even though it was outside agreed work hours. Then you get criticized by the boss because “the system is supposed to work”.

And this just repeats over and over.

> Believe me when I tell you that I could have worked on the entire software myself in 5 months.

I find this way of thinking very short-sighted. It may be true that this application can be written in net time in 5 months, but much more important than writing code is to know clearly what is needed, what users need. Moreover, requirements and wishes change over time. I have seen more than once that months of development time were wasted on something the users didn't need, so good product managers and senior software engineers who question things are often more valuable than engineers who write hundreds of lines of code a day.

I think the problem here is that the company has software engineers sitting "idle" without any good requirements.

I don't think it's uncommon at all. The "hard" part of almost every project I work on isn't the ultimately the code, it's the "soft skill" of extracting a good specification from stakeholders.

What's the reason for the dysfunction here? It could be that the software development team is just overstaffed. Maybe if they had lower headcount, they wouldn't be idle so much of the time.

Of course, it could also be that there are too many stakeholders providing incompatible requirements and muddying the waters, and that there's nobody in a position to make a decision about the real requirements.

I think it's easy for an organization to misidentify an organizational problem as a technical problem, then throw more technical headcount at it while ignoring the underlying dysfunction. And this is how you end up with "bullshit jobs."

I work in infosec and I have seen this problem quite a bit but not at every company. An advice I received early on was "better to ask forgiveness than permission".

So what I do once in a while is, if there is a major problem and the bureaucrats want to strangle it or play games like this, I just quietly do all the work and say "he, look! It's done!" Some will get a bit upset and inevitably my done work takes months to get reviewed and discussed before being implemented with no change.

It is not good for scoring political points but shit gets done. In normal IT or sofware dev, this just means delayed projects. In security it means reduced security posture. Bad guys are not taking months and years in meetings when they attack us. It in itself is a security risk and what I do to work around such b.s. in my opinion is remediating that risk.

But regardless of this, bureaucrats will still continually tear down and the build backup. Migrations the proof of concept meetings and demos. It is very hard to communicate with management that in infosec, you need to be agile and stable at the same time. Agile when responding to threats but stable in your tooling and people so you can develop maturity.

I too like job security and all that but damn it! I would feel so shitty if we get pwned and all we have is excuses.

I work in a devops role, and I also have the flexibility to work on fixing things that management does not deem a priority, typically when I get bored with my assigned tasks. I am much more motivated when things actually get done vs. revisiting the same problem over and over.

As the top comment points out, the author comes off as arrogant and their view is unbalanced, but they do have a point.

I find the saying "What a programmer can do in a month, two programmers can do in two months" is quite true. I consider myself competent and the people I work with are even more so, but human communication is always very imprecise and slow. If you stack it into a hierarchy of teams and managers, efficiency loss becomes exponential.

I really do think that the best way to organize software development is to have discrete components with exactly one person in charge of a component. Of course there are notable downsides. If only one person is in charge of a component it would become quite opinionated and it would be difficult for devs to spot each other's errors, but I think it would be a great tradeoff nonetheless.

I really don't want to spend even 5 minutes of my life debating whether we should split a folder into 2 smaller folders or not. I'd much rather have any member of the team go with their gut on this. An individual's choice may not be as good as that of the entire group, but it's good enough.

This approach involves a high degree of risk, i.e. your bus factor is 1: https://en.m.wikipedia.org/wiki/Bus_factor

Yes, absolutely. Having a single person do what they want with a component involves risks but I think they can be managed.

Say the dev in charge of an important component of a service is struck by a bus and dies. The optimistic scenario is that the code was well enough written that people developing adjacent components (ie. components that interface with that of the deceased dev) can effectively take over development in the short term until a new owner is found.

A more interesting scenario is that in which the dev abused autonomy and the component is utter spaghetti. In all but the most extreme of cases, the component could be kept in maintenance mode as is for some time. This would block progress that relies on changes in the component, but allow the service to continue working. In that time, other devs could either untangle the spaghetti and refactor the code into something workable or rewrite it. In both cases a significant amount of resources would be spent, but this is a scenario that's unlikely to occur often and the fact that the component was owned by a single person places a soft cap on the size of the component (and ideally an employee would maintain a couple of unrelated components to ensure they can continue working if one service is deprecated) ensuring it could be replaced within reasonable time.

Here's something I learned.

Yes working in big tech or a big company can have its fair share of red tape.

You can either accept this and work as a cog in the system, or you can start to poke the sleeping bear.

When you're overburdened with more meetings than time to do the work you talk about in those meetings, that's really on you, not the group of humans we call a company.

If your boss starts to attach your performance towards meetings, then maybe its time for you to have that conversation about how nothing is getting done and that by not accepting meetings is how you do get stuff done. It's all about balance at the end of the day. Most people are reasonable and will listen.

So while big companies may never change in practice, you can change how you work in a big company and see tremendous results by just saying "No" every so often. Most of the time nobody notices or cares, and when they do they respect you for protecting your time to do meaningful work.

I 100% agree. It's about creating your own oasis. There will be friction from everyone around you, the only way to overcome it is by producing results and being very clear about your intentions.

Also don't be surprised if your manager / co-workers around you forget agreements that have been made. Occasionally you might have to compromise, other times stand your ground.

Moreover there is a fine line between poking the sleeping bear and acting like a prima-donna because things are beneath you. You can't always work on the most complex, or interesting projects. Someone has to fix the defects, produce the blue widget, now that the red widget is working.

Personally I try to alternate between working on "cool" things and a boring but relatively important thing. That way I support the team, but also make 10x progress on some things.

Meeting wise, I block out 4 hours a day (if I can) in my calendar. If you are using Microsoft Outlook you can setup Focus time. There are days that I do end up going to meetings during my focus blocks, but I consider it a choice.

Of course I have had multiple honest discussions with my manager to manage expectations on both sides. Figuring out your manager's main needs / goals can help a lot in those discussions.

I was expecting to find some interesting thoughts on this one, but its the usual rant of the "freelancer" who does not understand what production means!

Yes big companies have productivity issues, however they have to create software which will outlive most engineers working at the business. You cannot reach the SLOs of google by hacking something together in 2 months!

These were not “software companies”. Such companies sell software. These were “normal” companies dabbling about automating processes and “being modern”. If software isn’t what keeps the lights on, it’s just a playground or a cost centre.

I have been in a company that is similar to one of these but the codebase was massive and very problematic - a good reason for why it was hard to get things done.

I think many folks here think if you work for FAANG or similar - it’s all cushy and you’re sitting on fat stacks but it just isn’t. You’ll get on a PIP real fast because you didn’t have impact - something which was out of your control because your boss assigned you a low impact feature. You’ll be kicked out within 1-2 years and back to the grind - meanwhile stressed and possibly underpaid because no refreshers and no salary bump.

Again - it sounds nice in some ways but it’s a mostly brutally toxic environment and the bar to get hired is exceptionally high. If you’re getting repeatedly hired at FAANG and crew - you’re in the top 1-5% or so and it’s a very competitive bracket to stay in. Seen many go in and never be able to get back in…

Astonishing to me that someone with 20 years' experience in any industry could have so little perspective. Obviously there are inefficiencies with big companies, but complaining about needing to do documentation, or basic project management?

The writing is smug and shows no self awareness - it seems to me that the author cannot recognise that there may be other priorities than exactly what is in front of them and therefore everyone who disagrees with him must be wrong.

It is good that the author has found something that suits them better.

I'm pushing more than 15 and feel like the author is right.

What you're missing is that doing soft tasks is a tradeoff and big companies are leaving a lot on the table by having an inflexible culture.

Those same big companies will end up buying startups for 10x their ARR to get some mediocre product with no documentation or tests, cranked by developers on redbulls swearing at each other instead of doing retrospectives and yoga friday.

I understand the trade off, and big companies do too. You're going to lose a lot of very talented staff because that is the work environment doesn't suit them. It is a trade off companies make because they are managing risk, and because they have other priorities than having software coded at the fastest possible speed.

> Those same big companies will end up buying startups for 10x their ARR to get some mediocre product with no documentation or tests, cranked by developers on redbulls swearing at each other instead of doing retrospectives and yoga friday.

And yet, that mediocre product still is orders of magnitude better than what the big-co would have been able to produce internally, simply because of all the ass-kissing and butt-covering involved in big-co office politics.

Yeah, it's a strange article. They seem to miss the underlying point that in a business, generally speaking, writing the code is relatively easy. It's working out what problem you're trying to solve and who you're solving it for that is the hard part (an the bit that requires you to spend time talking to other people). Of course you write more code working on your side project, because you know exactly what you want to do with it and there's usually no consequences if it goes wrong.

The problem with the article is that it's the perspective of an engineer who hasn't had to think about higher-level problems. If I had to summarise their perspective it's "if engineers are writing code, that's a good thing, and anything else they do is probably a waste of time".

But what if engineers are writing bad code? What if their code doesn't solve any customer problems? What if the other thing they're doing is helping them write better code? Or scaling the company so they can hire other engineers who do write better code?

We've figured out 20 years ago that writing code, showing the resulting program to customers and getting feedback was the most effective way to find out if you're actually solving customer problems. Some group of people wrote about it in something called the "Agile Manifesto" or some such.

How do you think an author of the Agile Manifesto would respond to the original article?

Considering how companies are implementing the "Half-Arsed Agile Manifesto" rather than the actual "Agile Manifesto", I think reading this article might be what pushes them to jump off a bridge. 20 years of companies failing to understand your 4 line text, and using it to justify things that are utterly antithetical to what it stood for, has got to hurt. It's so simple:

- Individuals and interactions over processes and tools

- Working software over comprehensive documentation

- Customer collaboration over contract negotiation

- Responding to change over following a plan

Sounds like an environment the author of the post would like, he even describes such an environment later on, one that he enjoys so much he overworks for no extra pay.

Then there's the twelve principles, one of which is:

"Working software is the primary measure of progress."

Another one is:

"The best architectures, requirements, and designs emerge from self-organizing teams."

Another is:

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Following bullshit company processes and pointless meetings is the opposite of the above. The one that might be contentious is:

"Business people and developers must work together daily throughout the project."

This sounds a lot like meetings, but that's the smallbrained take on it. Here's an easy alternative: Continuous Deployment in a staging area and a Slack/Teams channel for business people to comment on changes they feel are necessary. Not only does the request get recorded (often nothing gets documented in meetings) but the communication is asynchronous and doesn't require booking the entire team for hours. The discussion is also a lot more actionable because it is about something concrete.

Given the above, what do you think about how an author of the manifesto would respond?

I imagine the author of the original article works in a company which is prioritising the right hand of the principles over the left. We've all worked there, we've all hated it. I did, so I set up my own company where we'd do agile right.

Hired my own team of devs. Got no revenue, velocity was low. Ended up annoying all the devs by trying to push them to spend more on the right-hand side of the manifesto than they thought was necessary so I could figure out why nothing was getting done. Still got no revenue. Eventually gave up.

I think the authors of the agile manifesto would say that building complex software requires the business to adopt agile (real agile, not half-arsed agile) with the tech team subsequently following it. The engineers also need to deliver on their side of the bargain. That means continous value, and not just fiddling with shiny new tech and fancy design patterns. When both sides of that operation work well together, you get good software. If you've got enough good people that already know how to do this, it bodes well. But how do you find and pay for all these good people? That's why you get people that merely think they're good, but are at least much cheaper.

The engineering tendency when given freedom is to over-engineer everything, leading to disappointed clients, and a fragile system that's buggy and can't be fixed. It's one of the big reasons so many tech-led startups fail, and also why bigger businesses end up putting all these bullshit processes in place.

And that's my take on the OP. Lots of "managers bad" without recognising the faults of engineers in that process.

I'm sorry to hear that, indeed, the engineers have to follow through on their end as well. That means "working" software, minimally functional, has to be delivered ASAP, at least to be able to gouge customer engagement.

"Design Patterns" and the latest "Web Framework" fad are the opposite of delivering working software. How you find people with the right mentality? I'm not sure.

Low-level game devs tend to have that "make it work" mentality but they like to reinvent the wheel a little too much because the existing wheel is 0.1% slower than their custom made one.

Web devs are the opposite, they seem to think the wheel has manifested itself from the ether. They probably don't even know about half of the 50 wheels they brought into the project, and they'll replace them with newer, shinier wheels in a week.

I think hiring a good team lead with the right priorities is key. Not a "manager", but the team member everyone else looks up to and follows out of their own volition. It might be worth wasting a lot of money and time on finding and hiring that person at the very beginning. If you do, the rest should fall into place, as they'll hire people who work well with them, meaning same priorities.

Look at the impact someone like Jim Keller had on the companies he worked for, as an example.

Yep, both managers and contributors have a faulty model of agile. We're all guilty of it, even those of us who know it when we see it because we know the theory so well.

Finding people with the right mentality is, as you say, very hard.

The temptation of the manager is to get people with the wrong mentality and wrap them enough process that it will fix them. The temptation of the contributor is to blame the manager without looking at their own faults.

As good a solution as I can suggest is to work with people who are willing to collaborate on a positive outcome, and go through genuine continuous improvement.

And just to clarify, I've been both the "shinny new framework" and the "I can make it 0.1% more efficient" guy at different points in my admittedly short career (still a senior though). These days I'm the "make it work" guy but only after suffering the negative outcomes of the other two a little too much. You only really "get it" after doing the "wrong" way first.

I've also had to deal with the "bad" manager that gives no push (nor any time) for stabilization, leading the code to a near-project-killing state of constant malfunction. Quite a few of the principles in the manifesto are about avoiding exactly this state, but they too are not followed correctly.

The following are in a different order in the manifesto, but I think this should be the way to read them, they almost form a coherent paragraph:

"Continuous attention to technical excellence and good design enhances agility. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

This means quality needs to be considered from the beginning and maintained, but that's not contradicting the fast delivery, quite the opposite (proven by many studies on Continuous Delivery).

Quality arises from constant refactoring the working code to be better, based on the results obtained from seeing that code running. Not from planning ahead with some insane micro-service bullshit architecture 3 months in advance for a project that probably will never scale to a size that needs that nonsense (at which point you deal with it).

But you have to give time for that cleanup work, and introduce a culture that demands that quality (where quality is measured by the software working well and delivering value, not by how theoretically "clean" the code is) otherwise it simply won't happen.

I've also had to deal with the "good" manager that tries to fix the above issues (after they happened) with processes. In my experience they just slow down velocity and don't resolve any of the actual problems. It's like telling a plumber that is almost swimming in shit to read and sign a 20 page document before turning off the valve of the pipe that's spewing brown liquid everywhere. That plumber is just going to hate you.

The only thing that works is to demand both continuous delivery and consistent quality (and allow time for the latter at the expense of the former if need be), ensure you have the right lead, communicate openly and regularly, and then let the team do its thing. If the devs and PMs don't see each other as allies rather than annoyances, the whole thing falls apart.

Also all it takes is 1 bad dev to spoil the bunch, I've seen them do so much damage it's nuts (stuff like introduce some whole new web framework nobody else in the team knows on some part of the project, or rework entire parts of the code to be async even though then it doesn't work with the rest of the codebase). Code review / pair programming is supposed to prevent this but if the team lead lacks the strength to keep devs like that in line, you're screwed anyway.

"Individuals and interactions over processes and tools"

If the individuals and interactions are wrong, no amount of processes and tools will fix it... I guess companies the size of Microsoft and Google can throw enough money at the problem that things work out somehow, despite the abysmal quality of most of their software.

Pretty well since he at VFX company he seems to working closely as a team and with his customers.

This guy also wrote a hater’s take on open-source a few months back: https://liou28335.medium.com/why-i-dislike-open-source-acbc2...

Something tells me he’s gunning for that Medium paycheck.

Oh man, that open source article is hilarious! Thank you for sharing.

I haven't contributed to open source in a few months and I still can't find a date to take to Starbucks. What am I doing wrong?

> Medium paycheck.

I'm sorry, what? Out of the loop here.

I’m referring to the Medium Partner Program, which pays based on level of engagement with readers, particularly subscribers (as this is a Medium post).

Find "What Stats/Data Points Will Be Used to Calculate Medium Earnings?" in the link: https://medium.com/blogging-guide/how-much-money-can-you-mak...

But basically: outrage increases readership increases Medium author payout

It's not like the points he is bringing up are invalid though - and I say that as someone who actually likes using, creating and contributing to FOSS projects. Most of them eventually boil down to funding - it's rare that open source projects get decent funding or that big-co employees are allowed to feed back stuff back upstream. The result is a shit ton of people all doing what they want, but there is no overall vision where the ship should head - and those that do want to break the cycle of misery often enough get badly burned. Just look at systemd, how much hate it got and how it's practically unthinkable now for people to ship handcrafted initd scripts instead of a sane unit file?

How many Heartbleed, left-pad or whatever similar instances of catastrophe does the IT industry need to recognize that relying on self-exploitation and intermittent government grants is not the way forward?

That's true, the points are not invalid. Some of them aren't even coherent.

Yep. I think the author fails to understand that coding is only a small part of the process of writing production software.

Do you think that sw engineers at startups aren't largely writing code for most of their job?

I think sw engineers at startups very often write way too much code rather than spending time thinking about, and talking about, what to write.

As the old saying goes, "you can save hours of planning by doing weeks of coding."

Most discussions at large corporations are bikeshedding. Huge issues are ignored, but some minor detail which can be changed easily later gets talked about for weeks. It's often because its a detail middle management can understand, but the huge issue isn't.

You then have to spend a significant amount of time trying to guide people to focus on the right things. And that is draining.

But there are different roles that come into play when it comes to writing production software:

- the code, obviously

- infrastructure

- documentation

- wireframes, mock ups

- user manuals?

- monitoring

- ...

Software engineers shouldn't be the ones who address all the points above (otherwise that leads to burned out developers like the author).

The delivery of the message is a rant. It’s blunt and negative. But the content is something that many polite, loyal workers will tell you after a beer or two (so to speak).

You are mentioning perspective and priorities. But from what I know these are exactly the problem. The more people you have that are disconnected from production and use, the more BS work tends to get generated. Not only because of increased bureaucracy and overhead, but also because decisions get made by disjointed actors and are often based on buzzwords or company politics.

> complaining about needing to do documentation

The article's formulation:

> You will be asked to write a 50-page documentation for some little code you wrote.

The author does not complain just about writing documentation, but about writing an unproportionate amount of it that presumably isn't being read by anyone. I've seen that happen. People writing essays about software that are bound to get outdated and will never be read by anyone. In systems that are disconnected from the source code.

> The writing is smug and shows no self awareness

Maybe I share the author's disdain for the corporate setting, but I don't see the smugness.

While the article may not acknowledge the cost and value of doing things slowly and bureaucratically, I fail to see how that is an expression of lack of self-awareness. It is mainly an expression of a preference for seeing direct change to business logic in a short amount of time, even for aging projects, because of direct ownership.

> The author does not complain just about writing documentation, but about writing an unproportionate amount of it that presumably isn't being read by anyone. I've seen that happen. People writing essays about software that are bound to get outdated and will never be read by anyone. In systems that are disconnected from the source code.

This has been the norm more often than not in most companies, especially larger ones. Hence the Agile Manifesto, written by people who've been there again and again.

And still, working in company that does not document what the system does, it sux massively more.

Because end result is that no one knows how to use our own software. You dont know what it is supposed to do, so it is impossible to keep that stuff working. It takes ridiculous amount of time to configure anything or reproduce bugs, because you need multiple calls to find the one person who barely remembers.

Also agile manifesto is 20 years old. Agile is literally what most large dysfunctional companies do these days. It does not have no new solutions to actual real problems of companies, because it is old.

No-one ever suggested not to document!

The comment I replied to says "inappropriate amount of documentation", the Agile Manifesto says "comprehensive documentation".

That's the problem. Months, if not years, spent on pages after pages of comprehensive documentation that does not add any value and is obsolete by the time you start writing actual code.

Lastly, the age of something is not a relevant criterion. Not much has actually changed over the last 20 years. What has changed is the explosion of web-related software, which is actually the best suited for the ideas behind the Agile Manifesto.

> That's the problem. Months, if not years, spent on pages after pages of comprehensive documentation that does not add any value and is obsolete by the time you start writing actual code.

This picture is not any real company I ever worked in or real company I heard of from friends. Literally, not even before agile manifesto.

> Not much has actually changed over the last 20 years. What has changed is the explosion of web-related software, which is actually the best suited for ideas behind Agile.

That is not actually true, really. A lot did changed.

This also glosses over something else. Comprehensive documentation can even be really well documented code!

And in small corps, there's the "guy who wrote it" was "hit by a bus" scenario. It doesn't matter how dilligent, or how faithful someone may be when they leave, eg walking a replacement through the codebase can't happen of you're dead!

This is how I document. I think about being hit by a bus, and what would this corp do? A replacement hiree do? See?

Not doing this is, IMO, should be criminal. Like a CFO not keeping books.

People writing essays about software that are bound to get outdated and will never be read by anyone.

I write a lot of documentation entirely with the awareness that no one else will read it. I write it for myself. I don't want to have to remember the intricacies of a system. I want to write things down, then move on immediately, and have the security of something I can refer back to if I need it when I revisit the system.

But doing so is your personal preference, you (i hope) are not required to do so. Some people find it easier to organize their work differently or not at all. Some people are astonishingly productive despite not writing anything down, ever.

But doing so is your personal preference, you (i hope) are not required to do so.

I am required to in the sense that I define the policy about what gets documented on my team, and I said we write documentation about everything.

What if the teams changes? Intricacies must be documented despite that probably nobody will ever read it. Somebody might depend on it.

Writing code is more about communicating how to solve a problem than just solving a problem, that's how I view it. If you don't communicate, nobody except you will ever understand it. It might be that you don't need to document a lot, maybe most is obvious if the key parts are sufficiently explained. But it's vital and sometimes it's better to write a bit more than a bit less. A thing is, outdated documentation might be worse than none, so it's a delicate balance.

What if the teams changes?

Yeah, documentation will definitely help in this case. With it, you can swap teams and even companies, and it still works! This only fails in companies which do not review documentation and have no routine for keeping it in sync and testing it on e.g. newcomers, like you do for backups. Cause otherwise it is as good as never tested six months old backup.

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 totally incomprehensible C.

EDIT: It might have even been fortran code. The rest of the project was C++

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 codebase. I document how algorithms work, what the business logic is for things (which is another algorithm really), how applications work in a 'data flow' sense, what integrations there are with external services and how they work, what things mean, and so on.

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.

This type of documentation is the only kind I have positive experience writing. Tutorial-like documentation is another kind I have positive experience reading.

I've never seen anyone having to write a 50-page document just for "some little code", unless the author's definition of "some little code" is drastically different from mine. Without anything to back it up, that statement comes across as a huge exaggeration.

Everyone is at a different stage in their lives. It feels like the author hasn't had much challenges and found most of the work boring. I agree with some of the points the author has raised but not all. I don't agree with your comment about "writing is smug and shows no self awareness". It feels like you're jumping to a conclusion.

Working directly for clients and being personally responsible for the entirety of the development process gives you this perspective. You can have successful multi-person projects with almost no documentation and project management contained entirely in a single trello board with basic features.

Then, when you land in a corporation you can see how large teams barely manage to match your former personal productivity by choosing wrong technologies, taking wrong approaches, discussing irrelevant things in countless meetings and producing tons of write-only never-read documentation that gets obsoleted almost as fast as it is written. If you are too youthful and idealistic you can get a little arrogant experiencing this inefficiencies when you have a context to fully appreciate their insanity.

Or you may take another approach. That efficiency actually doesn't matter. People don't work to achieve anything. They work to get paid. And corporations have a lot of money. So the game is no longer about building stuff efficiently. It's about raking in as much money as you can for as long as you can and every inefficiency that justifies further work is actually best friend of everybody involved.

“ So the game is no longer about building stuff efficiently. It's about raking in as much money as you can for as long as you can and every inefficiency that justifies further work is actually best friend of everybody involved.”

You’re describing the goals of the individual becoming divergent from the goals of the company.

In the article the writer described his team’s goals at the VFX software company as being well aligned with the goals of the company and the customers. They even stayed late because they were enjoying solving the problem so much.

The same misalignment in goals is what made Communist Russia so awful. The stated goals were about providing prosperity to all workers and citizens of the USSR, but the goals of the committees became about personal advancement and the preservation of the party. It could be argued that the extreme job security of the dictatorship allowed this situation. If there had been a way to democratically fire officials, they would have been more aligned with the goals of the people. (A politician is only as good as your ability to fire them.)

Many large companies end up like the USSR. The way to solve this is to allow teams to fire their managers.

"The way to solve this is to allow teams to fire their managers."

I don't follow. Wouldn't most teams replace their manager with a manager who would give everyone the biggest raises and the easiest working conditions?

Why would a team want a manager who cares about the goals of the company?

"Why would a team want a manager who cares about the goals of the company?"

Bind their avaiable budget to their success.

Well, there is that, but you know, the countless murdering of their own people did not help either.

I don’t think the two concepts are separate. The depths to which some people will stoop only goes as low as their accountability.

"That efficiency actually doesn't matter. People don't work to achieve anything. They work to get paid."

That is fine, but now you are stuck playing politics. You have to keep whoever is in charge of the money happy. And no value is created because everyone is trying to avoid getting blamed for problems.

Obviously, real companies, making real software also have to keep customers happy, but at least those requirements are somewhat predictable as they are tied to the real world use case, and real world value customers are getting from the product.

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 every software engineer wish we had fewer meetings? Absolutely. Do I recognize that meetings are valuable to people not me and are critical in helping them deliver their (often non-code) parts of the project? Absolutely.

Not recognizing that after 20 years in the industry is baffling.

I'd be curious if author has ever worked on a large, 1 year+ project that went awry because the requirements were incomplete and the end users' needs poorly understood. If so, then I'm not sure they took the right introspective lessons away from that.

Edit: And I recognize that some companies are incapable of delivering software, due to broken development processes. I've worked for health insurance companies and know how baroque it can get. But that's been the exception rather than the rule.

I would even add that sometimes "maintainable and reliable" are overrated.

Sometimes being quick to market is more important then having to maintain the product. Sometimes providing a bad product is only relative to the competition (which may have a worse product). Sometimes having a good customer service is more important than the reliability of the product. etc.,.

I do agree with solving the end user needs... if a client does not need your product you really can't run a company for long.

>Sometimes providing a bad product is only relative to the competition (which may have a worse product).

Eventually will came someone with a truly good product and distrupt the market

will they?

In some fields having a good business and regulatory relationship with the customers (e.g., hospitals, DoD, banks, etc.,) is much tougher than building the product. There are many barriers in place and these fields are not so easily disrupted (having a superior product is definitely not enough).

Also note that having a bad product now that is better than the competition does not mean you cease to improve.

Exactly. I've worked in companies dominating a particular niche. Everything about the technology is "terrible" from an engineer's perspective, and yet nothing shifts their dominance. A massive rewrite that damages customer relationships is more risky than doing nothing to improve it.

Or this company is bought up, which was there first and therefore has the larger financial reserves.

>"maintainable and reliable" are overrated

That is popular opinion among the unemployed, as hoisting that BS on your project lead has real world consequences after your code audit. =)

It was Facebook's philosophy and also Twitter used to go down a lot in the early days. So I'm not sure I'd agree with your statement. It depends on your company culture.

Both are in a strong first mover / network effect industry (social). It's definitely an optimization in certain cases.

In general, a well planned API allowed Facebook to integrate a lot of 3rd party features to attract more users. Simply put, a messy standard is still a standard.

Here is a quick CEO dilemma: You have startup with about 4 people, you did a quick prototype, showed it to some potential customers and the worse has happened:

They want it! and they want it now!

The head engineer says it's all just a temp hack, it is completely shitty, they could give it to costumers but then the maintenance will be impossible, they will need months to add any new features on top of it, they will probably waste all their time on fixing bugs, and they'll quit if they have to maintain it for long.

What would you do? (A) continue develop until you have a nice maintainable product, or (B) sell the product now and face the consequence of wasted developer time and loss of their motivation.

Sometimes in such situations the answer is (A), but not always. It depends. How much money you got? how certain are you of the timeline for "finishing" the product properly? which option is riskier? How much competition you have and how likely they are to publish a product before you? What could having a real customer teach you about your product? What do you need in order to get the next round of investment?

This is just an example, but IMO product graveyard is filled with great maintainable and reliable code no one had a chance to use. I love software and I'm really not disregarding its importance, I just think it's not always the most important thing.

A CEO rarely accepts designing a product for a single customer. If you did, than your team just becomes dependent contractor labor rather than a business.

I will tell you a terrible secret of successful software companies: "One doesn't make money writing software, but rather reselling the same software mullions of times over."

You should know this already. =P

You seem to talk in absolutes while I'm just acknowledging there is more than one right answer.

And I do have specific real cases from my experience in mind... One of a great product that never finished (money ran out, CEO didn't want to provide something that was for "a single customer" as in your words), another of a shitty buggy unmaintainable software that did grow a company from 4 to 100 employees then to an exit and only then came the nice eased-back rewrite.

The 3 year survival odds are about 1:23 for software/services startups, and 1:70 for hardware projects.

I have culled many half-arsed options... and the decisions are far from arbitrary. Also, who budgets for a project burning over $100k a month in labor without a detailed plan... lol

I agree with what you wrote here... I just don't see how it relates to what I said.

Start-up have terrible survival odds. Decisions should not be arbitrary. There should be a detailed plan.

That moment when one person recognizes what is happening in a conversation; namely;

1. when two people are "talking past" each other.

2. It isn't only about 'what I'm saying'; multiple streams of conversation can happen at the same time and all be useful and even true

> You should know this already. =P

Groan. This comment could make its point without assuming what the other party knows or doesn't.

Yes, I agree, there is a continuum there. It is easy to judge from afar, but it is much more insightful to see what people do in real situations with real resource constraints and complicated human beings trying to succeed -- and not always with the same definitions of success.

For example, for many engineers, what they (a) can learn and (b) be proud of while building a product is a big part of success.

For some CEOs, engineer satisfaction is only a secondary or tertiary goal -- their business success crowds out most other things. This is complex; sometimes this drive is what helps a business succeed; sometimes this is why people get treated poorly or ethics go out the window.

"what people do in real situations with real resource constraints"

As this is mostly on-topic for the parent thread... I can respond...

When faced with a painful product launch/schedule, as management messed up resource budgets etc... there are a few actions one can usually take:

1. ignore the issue, accept a 60% probability of failure risk, and naively hope management is replaced

2. adjust current project scope, follow MVP rules, and defer features for v2

3. cull the project, and eject unprofitable/unhelpful members from the team

4. Leave the company before the shite hits the fan

Note, compromising workmanship is not on the list, as a business "Brand" is often more important than non-stakeholder opinions of intangible asset valuation.

Excellent comment, just wanted to add to this:

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

that it should also bring money, or enough money, to be more precise.

It may sound strange but lots of products that fall on your very on-point definition fail to bring enough money in order to keep the lights on (and then some), this is a point that gets lost on many software developers. For context, I've been a paid programmer for 15+ years now, mostly in small companies, maybe as part of bigger companies/projects the view is a little different and "bringing in money" is not seen as that important for the developers.

[Tangent]

> And this isn't to say that some companies aren't pathologically incapable of delivering software...

"isn't", "aren't", "incapable"

Three back-to-back negatives have me confused. Somewhat mysteriously, I (think I) understand what it means when I read it quickly, but if I pause to think I get confused. English isn't my first language :)

Update: Thanks for editing to make it clearer!

Point. Edited and hopefully clearer. I try to keep non-first language readers in mind, but vernacular crept in before a second cup of coffee.

IMHO, "this isn't to say" is a common expression in English, so I didn't register it as a negative. But you're absolutely correct.

Negatives cancel, so I think you cancel the first 2 and get "this is to say that some companies are pathologically incapable of delivering software", which reads a bit nicer

Generally that works but sometimes it doesn't.

For example, some people say statements like "I don't want no towels".

What they really meant: "I don't want towels"

What I get if I cancel the negatives: "I do want towels"

The meaning flipped :)

Double-negatives in the "not+no" formulation tend to be a special case. The easiest rule (as you realized) would be "If there's a 'no' before the noun (direct object?), in an already negated phrase, then ignore the 'no'".

It's technically incorrect but common English.

That is incorrect usage though; every rule 'generally works but sometimes doesn't' if we account for people not observing it.

But pointing out that language rules aren't something that people strictly adhere to, with rigorous logic, is a useful observation.

Undoubtedly, but it was a response to someone explaining how to use English (correctly), not how to understand someone else using English (possibly incorrectly).

If I say 'proper nouns have a capital first letter' I don't think 'actually oliver sometimes people don't do that' is helpful.

> That is incorrect usage though

We don't need no education

You wouldn't be here quoting that line if it were correct.

Was he hired as a product liaison with corporate to attend meetings with clients. No. He was likely hired as a developer. Most of this should appear as requirements via his inbox not be meetings he attends unless there is a screaming problem with a request.

I've worked at a fair number of companies (as either consultant or employee) and rarely have requirements landed neatly and fully-formed in my inbox.

I'm sure it happens reliably somewhere, but I'd hazard not at most companies.

That doesn't mean it doesn't happen when working with competent people doing their job well.

Consultants only seem to get called in after things have gone wrong too so does your experience support that not doing this is bad practice?

Agreed on consultants. It provided so much enlightenment on the multitudinous ways many companies can screw up the discovery and development process.

Setting aside the "This company was fundamentally disfunctional" cases, my takeaway has been that knowledge gaps between roles are an underappreciated cause of bad development outcomes.

Writing requirements is hard. Writing requirements without some intuition of what developers need to know is harder. Writing requirements without context on the business domain is harder.

So the ideal BA is someone who is a developer who is also experienced in the business domain.

The majority of companies don't want to pay enough to hire BAs with that experience.

So you get users (who may know nothing about software) + minimum cost BA (who is doing their best, but has no context for anything) coming up with requirements, which are of course incomplete and/or incorrect.

But fundamentally this problem is too large of a skill/knowledge gap between the user and BA, and between the BA and the developer.

Sure, if he is a junior engineer with the proverbial "20x 1 year of experience" and is paid like one.

A few days ago, I made a comment about good developers knowing how to think of their work from the business’s perspective. One guy responded by saying his only job is to write code and he doesn’t care about anything else. I just can’t imagine coming to that perspective, even if I understand the desire to have minimal responsibility.

> One guy responded by saying his only job is to write code and he doesn’t care about anything else.

Which is such a weird perspective to me. The point of writing software for business is to solve a business problem. Maybe it's a function of working in small companies and/or roles that straddle code writing and business, but I have a hard time writing good code unless I know the business problem space.

It's also why I think I don't get too worked up in the language arguments. I've written code from VB5 to Java to Go to JS all which deliver immense business value. When I think about the best code I've ever written, I don't think about how pretty it was or even the language, but is it still in use 5-10-20 years later.

Code 'longevity' is influenced by many more factors than code quality; e.g. rate of business change, traffic changes, infrastructure dependencies, and the complexity of the surrounding system.

As a pathological counter example think about arcane obtuse code that people are afraid to modify.

That's a good point. I didn't really define what I meant by 'best'. In some cases the code was used, updated, etc... for many many years by people I knew. If people were too afraid to touch it when a bug was found, then definitely not good. But, if people had no need to touch it b/c it works, that's a good spot to be also.

I think it's a failure to separate work and hobby. A lot of — heck, maybe even most — developers get into it because they enjoy programming. That's entirely reasonable, but you have to accept that some compromise is going to be required of you in the working world. You can't just do whatever you want to because it's fun and get paid for it.

If you find yourself empathising with the author, you really only have two choices:

a) Quit, do something else for a living, enjoy your programming in your spare time

b) Suck it up

Even rock stars have to sit in meetings and do things they'd rather not, like hold press conferences, give interviews, etc.

At many big companies there is plenty of room for those types of people. They just need to be put in a role where their customer is another developer. They can see things from the developer perspective and can be plenty successful working on things that are not public facing.

These are often some highest paying and prestigious jobs in large companies.

As a developer (and sysadmin), I want to write less and less code as time passes. It's not I don't enjoy coding, on the contrary.

However, I understand that a project is documentation and future planning, too. So, I want to build an artifact complete with its documentation, which can be sustainably moved forward by anyone other than me.

If I don't document what I've coded, then the joy project becomes a weight on me, and prevents me from moving to new, bigger things. Also, I can show the whole shebang as "I made dis!", and anybody can have an idea what the project is all about.

As a developer, I've been writing lots and lots of code every day for around 15 years. I write documentation quite rarely, only when it's a customer facing feature (a lot of stuff that I do is in the background where customers have no idea things are happening) or a very technical piece of code that I want future developers to understand better and keep the intended design in mind when making changes (this is much more common for me to do). Most documentation, however, can easily get stale almost as soon as it's been written, so with experience, you learn to focus on the important concepts as opposed to implementation details..

I rarely have meetings about things are not entirely technical, and I actually enjoy the meetings we have as we always come up with valid points that one alone may not have considered.

Anyway, just wanted to mention my experience as I don't agree that as you become more experienced, you tend to write less code. I am as productive now as I've ever been, even being one of the main and most experienced developers in a team of 20+.

Ah, no, I didn't mean to share my perspective as "this is the correct way, yo shall do as me". It's just my perspective and formed by my own experience and work structure.

As it comes up here from time to time, I work as a sysadmin, and have my side academic gig, which I'm the solo developer on a serious piece of code. I design, code, test and verify the whole thing, which is immensely satisfying.

My daily job is very connected to my academic gig, and they feed each other. As a result, I can apply what I've learnt from one to the other. We're a small team, doing a lot of big things, hence my work environment is drastically different than yours.

The gist of my comment was actually, "As I get more experienced, I design and write less code because it's more correct from get go. Then I document it at the level needed and I have something concrete and which can be passed over to anyone who wants to maintain or fork it, and this is equally, if not more satisfying".

The thing is, there is absolutely a cost for all those meetings. Time spent working with stakeholders and building consensus takes away from the urgency and energy you can devote to good work.

My experience is very similar to the article's. I just draw a very different set of conclusions.

For risk averse, cost constrained, low stakes projects.

Good engineering work is neither demanded or required..

My viewpoint is simple.

Don't work on software nobody cares about.

Work on software that's doing something genuinely important.

Then people will feel obliged to cut the meetings short and be more efficient.

Time spent working with stakeholders and building consensus takes away from the urgency and energy you can devote to good work

I don't see how I should square that statement with your next:

Don't work on software nobody cares about

How do you know what software people care about unless you spend time working with the stakeholders?

Think OKRs.

"Is the high level goal for this software critical."

If yes. Then, people will give the problem the full attention it deserves.

And once you have their full attention, you are more likely to get their cooperation to being actually productive.

If no.

You're going to have a bad time.

> Meetings generally aren't for developers. They're to keep everyone else involved with the project sync'd up.

But if every project has non-developers deeply involved in them then the software is very shallow. So to me anyone who thinks that every developer needs to be involved in such meetings just shows they have never worked on anything deeper than a crud app with some basic business logic. If you work on anything like a compiler, a garbage collector, a database engine, a load balancer, any kind of software framework etc then you will have plenty of teams never needing to talk to non-developers.

> If you work on anything like a compiler, a garbage collector, a database engine, a load balancer, any kind of software framework etc then you will have plenty of teams never needing to talk to non-developers.

Replace non-developers with "people outside your immediate team". In a developers-all-the-way-down shop, there are still people who are intricately dependant-on but not involved-in your work.

But developers are much better at describing what they need so there is much less need for meetings in those scenarios, instead they just send emails or open bug reports that gets resolved without the meetings.

Generally, I'd agree, but I've also worked with developers who are as egotistical, shortsighted, and/or stupid as the worst person with any other title.

Being a logical, cooperative, well-communicating human being is not a requirement to be a developer.

> Being a logical, cooperative, well-communicating human being is not a requirement to be a developer.

If your company is fine with them being unable to communicate then your company obviously is fine with you not being able to communicate as well, so why try? And if your company hires people who are good at communicating then there is little need for meetings between developers except politics, and most developers shouldn't have to deal directly with company politics.

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

> 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?

To be honest, pretty much all the experienced developers I met understood that. The "my silo and nothing else" kind of thinking tends to be something unexperienced people are more prone to.

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

I mean the author mentions meetings about the color of a chart... it's the kind of meeting they should be able to reject, because I don't believe they would have much of an opinion on the matter, only a decision that they can implement.

So if you're in a position like that, assert yourself and your presence in meetings; do you have valuable input that they need? Is there a time set, a concrete goal / agenda? If you don't have to be there for any other reason but to be kept in the loop, can they just send a tl;dr?

I mean I get that a lot of things need to be discussed - and a subject like chart colors can be reused for years after the decision was made - but not everything should be an all hands meeting. Have the least amount of people in a meeting to come to a decision and keep others in the loop. Let everyone do what they do best.

Rejecting meetings comes at a cost.

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 programs have search as well. Some developers need to learn to use these too.

You don't have to be a wizard at search engine flags or features or anything - it just needs to be the first thing you do to avoid shallow, easy-to-answer questions.

> I would argue most meetings can be mostly replaced with ticket comments, documentation, emails, and chats.

s/would/should/

The real benefit of those forms of communication is that you have a written, hopefully searchable, record of the discussion. It also forces people to mold their incoherent thoughts into complete sentences.

Meetings should be reserved for brainstorming and decision making.

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.

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 suck up to them like they are my masters. Cut the fat and get rid of the useless bureaucrats. Or at least get rid of this stupid "rank" that programmers are "the bottom of the food chain" so they can at least root out the shitty PMs.

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

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.

> "Delivering a product that solves end user needs and is as maintainable and reliable as possible" is the only truly important thing

I gotta disagree: "Delivering a product that solves end user needs and is as maintainable and reliable as necessary" is the goal.

Getting five 9s uptime on something that needs only 99% uptime is pointless.

> The writing is smug and shows no self awareness

Definitely. This style of writing immediately put me off the rest of the piece. I've worked with software engineers like this, and it's no fun.

> but complaining about needing to do documentation, or basic project management

There's a difference between "writing documentation that fits the need at the moment" or "write fifty thousand pages of documentation no one will ever read, just to check a checkbox on some manager's checklist / compliance requirement". Or endless "sync" meetings that are effectively nothing more than filling the desire of managers to (micro-)manage.

With a decade of industry experience from freelancing over small agencies to big-corp/government jobs I've worked, I can say this: The core problem at the root of most big-co/government projects and associated disasters is that there are way too many levels of "deciders" and especially a fundamental lack of trust in people to do the right thing. When everyone is just in cover-your-ass mode and no one is willing to risk making a decision that is not backed by weeks worth of analytics and big data, shit will hit the fan real hard sooner or later.

The most successful projects are done by startups or in the big-co world where a significantly high-up person says "we're going to deliver a solution to the problem X" and everyone is focused on reaching that holistic (!) milestone, not on micro-optimizing their KPIs, OKRs or other bullshit. The key to success is trust, the focus on one shared goal and actually paying enough to hire decent seniors to lead.

> complaining about needing to do documentation, or basic project management?

Some engineers are allergic to teamwork. I deal with coworkers with a similar attitude on a daily basis.

The most frustrating aspect of it is that companies are usually bad at acknowledging someone is a bad fit for a project or a team, even when they are shown solid evidence.

A big part of it has to do with how broken the interviewing process is - the focus at the moment is almost entirely on coding exercises and ignore tasks that many developers perceive as boring but can be crucial, such as writing documentation. It leads to mixed results where you end up hiring some engineers with T-shaped skills along with absolute code monkeys.

Focusing on the author instead of the discussing the topic really misses the point imho. We don't get good discussions from it. The point is the amount of inefficiences in big corps and how people react to it. This post has so many upvotes for a reason.

Unfortunately what you have just said is given as a shining example of why some coders hate other coders. If they're not going to contribute to core work, then add "perceived value" like docuemntation which a good manager should be allocating people to rather than wasting time in more meetings.

There is no real excuse why when you're paid to code you're not doing that 4-5hours a day at least 5 days a week. Career development is one thing, but there are 7 working hours between 9-5 so if someone wanted to work on that they have a full 10-15hrs a week excluding a break for lunch. Lets take out 5hrs of meetings a week which is still likely too much to be productive and we're down to: ~10hr for personal growth, ~5hr for lunches, ~5hr of meetings to keep people up to date and 20hr of actual work every week out of every employee.

Some meetings are important. Most are not. This is another common problem that middle-management gets into. Constant cracking of the whip and arguing-about/discussing small details is just toxic to productivity. (Small here being what style/color/toolkit. Not knocking up a prototype and pivoting when needed based on strategy and risk analysis performed at the start of a good project).

Most "divergences" or decisions can be worked out through a SWAT analysis (yes I'm quoting Scilicon valley), or by managers making decisions and pissing someone off some of the time rather than holding everyone back all of the time.

I've worked for managers with both management styles and I can guarantee the boss that makes a decision (even if it's wrong) is better than the boss that holds 5 meetings on the topic, because often you'll either get over it and move on, or prove it's wrong by the 2nd/3rd meeting and will still be ahead of the 5-meeting nod-fest.

This mantra of hire more bad coders or letting talented coders go to waste because they're not being allowed to do their jobs is adding to a huge bubble in the sector and frankly, on the precipice of a major recession I think people in such companies should be starting to panic.

I think if you read the author's other posts, they appear to just enjoy ranting. I wouldn't be surprised if they manifested after a beer or two considering how myopic and exaggerated they become.

Alongside this we also have: open source is inferior because of... reasons, something about older developers ageing like fine wine unless they work as web developers with all of those young whippersnappers learning new JS frameworks every month, something else about maths and algorithms but is really about Big O Notation being bullshit.

Not to dismiss the author's point: I'd like to believe they're being genuine and not just being controversial for clicks. But they have quite the chip on their shoulder it seems.

Also, it is quite amusing. I do enjoy the occasional rant.

Can you point out where he is wrong, though? His criticism might not be true for all teams in all large companies, bIt I've worked at one of the FAANG companies and left for the same reasons. And I know similar stories from friends and ex-colleagues.

It is easy to confuse "so little perspective" with "a different set of values". This seems to be the case with ^.

^ wrote:

> but complaining about needing to do documentation

Here is what the blog post writes:

> You will be asked to write a 50-page documentation for some little code you wrote.

The parent post (^) misread and mischaracterized the blog post. It is notable that the ^ called the other author 'smug' and then proceeded to respond to the least charitable interpretation.

I agree that the tone of the article is off but I don't agree with this statement:

> Obviously there are inefficiencies with big companies, but complaining about needing to do documentation, or basic project management?

This sounds like you've never been in a big org where you write more word docs than you do code. I have. It was terrible for a few reasons:

* Those docs go out of date with the code very quickly and so are not a good reference to what the code actually does

* They eat up a lot of project time and so projects tend to become late. As the documentation is what you have to write first by the time you get to the code you have much less time to actually write the dam code

* Extreme documentation actually reduces code quality. I've worked on many code bases where the code actually references page numbers and sections rather than what it actually doing. This is often the case with contractors that are only on project for a short amount of time and thus translate the docs directly into code. Also if there are and errors when creating these docs they are often translated into the code often into performance / non-functional problems

* Docs written after the fact end up being rather pointless / unusable as you'll have to describe all the weird things you done to make it work properly / fast ...etc

* Non technical people will read what you've written not understand it, because it's highly technical, misinterpret it then use that strange idea of things they've got all over the place. Like someone that doesn't know what a Foreign Key is but seen it once and sticks them on every column in the DB. Then you'll have to have a fight with them as "it says here on this doc"

I could go on but I suspect what I've written here is quite unpopular so I'll end by saying that documentation is very hard to write correctly you need specialists who know exactly how to describe what's been done in the system to others. You also need to balance the amount of docs you create vs the actual work on creating the thing.

Again on Project Management you described it as "Obviously there are inefficiencies with big companies" that sounds like you've never been in a full 8 hour days worth of meetings getting 0 coding done and just explaining to 10 different managers what needs to be done. Some of these big corporates are so colossally inefficient that people have been quitting on mass during the pandemic to get away from it. It's a serious problem not just to be swept under the rug like oh well that's just what big companies do. I heard someone either on reddit or on here defend a 3 hour long "daily standup" meeting because it was good to know what the devs are doing. Like yeah there are in you meeting for 1/2 of the day.

Now I don't condone 0 project management but companies seriously need to cut it back. Tools like Jira have made working hell for some programmers.

> but complaining about needing to do documentation, or basic project management?

I think you missed the point about documentation and project management taking inordinate amount of time and manpower compared to the output in both quantity and quality.

That's fair, and given the tone I wouldn't be surprised if there were some very exaggerated #s there. But if accurate 1-2 hours a day of coding on average is pretty bad. Meeting etc are necessary but it shouldn't be that bad.

The more years I have spent in my career, I have come to realise that coding and implementation of something is NOT the only productive part of the project. Even though I like to roll up my sleeves and "just get it done already", I have matured to understand that (1) scoping a problem correctly and aligning it to a function of the product, (2) documenting the need and its integration with other parts of the project/company are much harder and more important actions that makes sure that you're implementing the right thing and not wasting/overengineering the feature.

It takes a bit more perspective to understand that no one can know it all or do it all. Contributors other than "coders" and implementors such as Product owner, scrum master, tester, manager play a key role in guiding the implementation. By the nature of those jobs, they are not as quantitatively measurable as an engineer's job.

I think this is a little of column A and a little of column B. Just as there are good and bad developers, there are people who are good and bad at running projects and organizations. The author feels that something is wrong. He knows he is not working anywhere near his full capacity and that the organization created this environment. He also highlights a lack of growth opportunities at some companies. What he doesn't do is highlight solutions or recognize why certain behaviors are key in certain environments.

Toward that end, I would recommend three old and poorly written books with timeless and wonderful ideas: The Goal, Critical Chain, and Managing Corporate Lifecycles.

While these books are all about management and running a company, I think they lend perspective to developers on why certain things happen the way they do. They can also help someone recognize and pick a healthy organization to work in. Just like books on software development, these books augment experience, they don't replace the need for it.

3 years, 20 people, 24K LOC does sound objectively inefficient to me for the project as described.

Another take on it is that in a big company, even incredibly mundane and boring software can scale to a level that is stupendously valuable once it goes into production. Hence the company can completely afford to have an entire team working away writing 3 lines of useful code a day. It is way more important that the code is created in a way that can mesh with the rest of the giant corporate behemoth (so yeah, documentation, meetings, etc etc) than it is that it is done fast.

The guy made "only ennemies" in big companies. Not sure he'd be the most unbiased person to comment on the quality of tech jobs or somebody who can comment on healthy coworker relations.

When the same pattern keeps happening to you wherever you work, its not them, its you. That you had a few good positions in healthy teams does not make you a healthy coworker, the culture was probably just too strong and healthy for you to mess it up.

One of the main reason I have come to to make peace with that, is that these companies are not optimizing for delivery and product quality first.

They are optimizing against risk (of change, of loss of control over the whole process from ideating to selling/shipping).

If you can build the product/service in 2 months with a tight focused team of 3-5 people, in a 100+ engineers company, how do you manage if this 3-5 people leave (whatever the reason): how do you manage to infuse their experience/expertise over the thing they built, to 10/20/30 other people to mitigate then this risk?

You can manage to do so when your company grows, because... you don't have a choice, you started small.

When you've grown already, to mitigate this risk, you have to start to infuse things across many people and layers of people you have, so that when, 3-5 people leave, it's almost barely noticeable an event.

Maybe there's a better set of reasons. But this one made me understand better the whole world of big corporations and especially (big) consulting sofware companies (which are often several ones contracted on the same big projects).

Edit: you may also understand "optimizing for" as "scared to death about".

That also explains the "design by committee" thing and the ugly/desperate UX some corporate apps have.

That would be justifiable if the risk was proportional to the cost. Frequently it just isn't.

As a case in point, if "when, 3-5 people leave, it's almost barely noticeable an event" then you've almost certainly over-compensated for the general case. Why? Because the entire set of people who know anything about a given project simultaneously leaving should be incredibly rare. If that's your benchmark event probability, and your risk mitigation costs are linear in the risk probability (which they probably are, by vague handwavy analogy to finance thinking), then you're constantly bearing costs that aren't justified by the downsides you're likely to encounter unless the specific project in question is company-breakingly critical.

If an entire dev team up and leaving isn't a rare event, you've got deeper problems.

This incredibly rare event has happened at almost every firm I've ever worked at (except small startups), multiple times a year (different teams/products, but sometimes also the same product with its new team)...

Yeah they should fix the actual issue many layers above, but that's not something the guy planning for this can do at huge corporations. You just deal with whatever it throws at you.

Interesting. I think I've seen it once in a 20-year career.

I think rather frequently the impact of such a "rare" event could indeed be company-breakingly critical, depending on which part of the company that team was running. As a thought experiment, if all DBAs left tomorrow and the database fell over the next day, how much time would the next-most-capable person need to figure out the backup policies and scripts, restore the db and bring everything back up? I've personally seen this sink a company outright. It's only anecdotal evidence ofc, but it is still something that happens.

Worse, people leaving a team are not independent events. People leaving a certain team is often highly correlated to other people leaving the same team, because there is some common cause like a toxic manager.

"should be incredibly rare". Not incredibly, it's rare, but it happens (seen it in two small companies, it killed them; saw it in several ESN/consultancy projects, it killed the contract, but was a manageable event in the whole company; saw it in medium software companies, it killed the projects and sometimes pushed for strategy changes).

It happens enough for many (not all) individuals to have noticed across their career (especially when in management, where a big part of their role is already to manage risk).

It happens enough for any single company to be quite traumatized by it when it happened, and to try to avoid it in the future.

Where some companies do it differently is: they don't overreact, they understand that this is a risk management issue and that you can balance it, and/or they don't setup a "general case" for all projets/teams (depending on the type of the project). This requires quite some serenity and perspective.

I disagree.

In most of the large companies I worked for there was zero documentation (+1000 employees, +100 engineers) or very very little or only in a few projects. When people were leaving, someone else was getting hit with a shitty undocumented project, they would spend some time learning it - and that was it. In the worst case a doomed-to-fail-rewrite started and troubled the team for a couple of years.

I think the main issue is that: - People are given tasks from the board of directors (trickling down layers and layers of management), they don't feel like it's their problem - There is little accountability, tracking performance is very hard; tons of companies don't bother, but some of them do (after HR intervention, CTO being in trouble justifying the costs) and they can't find decent metrics to use for performance, so the bosses are basically flying blind / trusting middle managers. - No high growth stocks that will make you rich - Middle managers feeling like they need to prove they're doing something imposing weird and useless rituals: meetings, presentations, etc

These factors allow people to slack off as much as they can and take as long as they can to do anything.

As long as they can come up something for standup, it's all good.

This does not look like disagreement to me, but rather a distinct perspective of the same thing (was it the issue, or the symptom?).

Getting hit with a shitty undocumented or doomed to fail project is part of the problem/risk being managed or not: on some occasion, it can kill the team/project/company, on some other, it can be managed more or less successfully, but still in a way that is _not regular_ against the baseline.

When you get a project handled by a larger team of people apparently doing "not much", 1/2/3 of these leaving will not change the baseline of the project they were working on (or if it does, then comes the pressure to reorganize again to avoid that disruption).

It's "a bit" similar to the 40% lazy ants thing (https://boingboing.net/2017/09/12/living-larders.html).

Here are a few personally lived counter-examples:

1. a unicorn where someone implemented a a CI/CD system that none else can work with nor comprehend

2. a public institution where dozens of people work against the clock to replace the software maintained by a few old farts close to retirement

3. a critical financial institution where secrecy and nepotism made anyone with 30+ years of service into a major failure point.

IMO, the bigger the organisation, the more they are shifting from internal risk management to outsourcing all risk. When the risk is handled by third parties via contractual obligations, life get easy for middle management.

Needless to say, many of those contractual obligations are not worth the paper they are written on. Many organisations survive largely on the good will of the lowest-rank employees.

I've worked at all company sizes from big tech, scale ups, and early stage startups. From my experience, I've learnt the most and done a lot of interesting work when the company size was smaller. Although a lot of people seem to care most about what I did at the big tech company and get surprised when I tell them I spent the whole sprint fixing some line on some sub menu.

It's a sad thing that there is so little money in making scientific software; better make some dumb flashy app if you want to retire early.

Software engineering is a group effort with lots of components other than coding. It is very very seldom a lone operation and all those are tiny products with tiny scope (if results in a viable product at all!). Deciding upon the features, figuring out what is the best to do in a plethora of criteria involving finance, technology, organization takes much longer than the actual coding and involves the communication (spoken, written, presented, etc.), no suprise there.

Management could many times done better of course, managers are as lazy or incompetent as other people, if not more.

Dear author, you're one of those people who are capable of more and need to take an unfortunate step back.

Given there are so many people who flocked and are still flocking to IT based programming jobs because of the promise that "one day you will be the next <insert-billionaire-here>" level push.

I've met people who burn themselves out trying to write hundreds of lines of good code in a day. I've had new colleagues come in, publically slate my code, only to have to retract their comments in private several months later once they actually understood what it's doing.

The author is probably one of the types, that left as seniour architect could have build something better with people around him adding polish and other "perceived value" to a customer. (Perceived value in this case being everything from corporate branding to translations to internal tooling).

Most "complex" problems from the non-IT world don't need a full stack all singing all dancing latest npm, all the RAM in the world and a full Oracle site lisence. Most could be solved by some talented coders (3 or 4 max) doing the grunt of the work with others around them adding perceived value to allow the company to add a zero to the net value of the product, and it could be deployed in-house on a 2nd hand server with redundancy built for <$30k for it's whole lifetime. And that's assuming it's not just an app to sell that requires no hosting.

>if we should display certain data using a particular chart

Why are software devs bothering with that to begin with? It seems like it should be something the user decides, even if they say something like, "I want a sparkline chart but make it real big and applied to all the data". And then I silently think to myself "oh so you want a regular chart but you heard the word sparkline once but don't know what it means. Okay, will do."

edit: to be honest my users are reasonable and that sort of example is rare.

Third week into a role. Managers too busy to meet. One reports that we have no product owner, no audience, and no requirements. The other demands a confident promise to deliver the app by Q3.

I recommend trimming the "MVP" to focus on just one, concrete user need, so that we have a prototype to deliver.

Manager: No, just stub 99% of the REST contract and get it to prod.

With each new software role, I feel I am somehow moving backwards compared to the relatively well positioned earlier roles.

I feel this too. At an earlier role we had a well-architected PHP codebase that we were throwing away and replacing with graphql, scala, and angular. I was a junior dev so they threw me into fixing the "unimportant" legacy PHP system (which just so happened to be the thing making money for the company) instead of the shiny new rewrite. Never been happier in my life.

> I remember while I was working for a big financial firm as a software developer. I kept asking myself why we were doing very little coding. Most of my time was spent attending useless meetings, preparing boring slides, making goofy excel sheets and Gantt-charts and maybe 1–2 hours of coding a day if I was even lucky. The software that I and my team worked on was a basically a javascript web application that monitored and collected details about financial transactions in the company. Believe me when I tell you that I could have worked on the entire software myself in 5 months. The entire solution could not have been more than 24,000 lines of code (including lots of generated code). My team spent nearly 3 years building this software, most of the time spent in meetings, bickering over the pettiest feature like, if we should display certain data using a particular chart and what colour the chart should be.

Theoretically a Product Manager solves this problem for you: they are given the authority to be decisive about the details of a project, its scope, and they sit through all the boring meetings and manage the status update bureaucracy while working with the developers to actually build something.

There's one competent programmer for every 4.2 big thinkers, visionaries and non coding architects, so this is a natural order of things.

TFA uses exaggeration to paint things which are necessary as superfluous bullshit (write a 50-page doc on every feature). When you strip that, you are left with a pretty banal statement: lone coder outside corporate environment can work faster on implementing stuff than one working on a big project in a corporate setting.

Okay, but doesn't everybody know that already?

What is this mythical concept "Business Value" which floats around undefined, unquestioned, in the impassioned rebuttals to this post?

If I can hire one person instead of ten to finish software in one third the time, even if it needs significant tweaking by the end, is that not "valuable" to my business? Please define and expand your terms.

His Dilbert level insights about corporate life are very old... running a business is complex and gets less efficient with size, that is no great wisdom.

Building a code project with one person is great but consider the following issues: 1) Making sure the software is built to specifications 2) What happens if he leaves? 3) What happens if another urgent project arrives 4) Who will do support? 5) Who writes documentation 6) What about integrations with other systems in the business 7) What about IT/DevOps and server maintenance? 8) What about communicating it to other people in the org? I'm sure we can find more.

The generic use of term "Business Value" in this instance means that while development time is indeed a measure of efficiency it is only a small part the overall value that a company needs in a project.

Just to make sure I'll state again, large corporations are indeed not very efficient, I do not argue that, but they are profitable.

Business value is defined by the business in question, and what’s valuable to one business isn’t valuable to all businesses. The point is that the goal is a collective goal and not an individual goal.

If you really can hire fewer people to get the job done, and the value you care about is lowering the costs of employing people, that certainly is valuable, and you should do it.

Business Value is a term you learn to understand very quickly and deeply when you start a business and hire some opinionated programmers who complain loudly about having to talk to others and document what they work on, and proceed to have trouble meeting their deadlines, or create issues that others need to help fix.

I’ve personally watched what happens with programmers who write code without talking to people enough, both individual programmers who seems prolific, and groups of programmers working on different parts of a larger system. When programmers refuse to stay involved in the discussion of what do to, they sometimes invent or imagine their own requirements, and they build things that don’t fit into what the business actually needs. This can be a colossal waste of time and money, even though all programmers involved were happy and felt like things were “efficient”.

The problem with the article is that the author is arguing for personal efficiency, at the expense of group efficiency. It’s funny to write something about software companies being a joke and then argue that it’s annoying to work with other people. The software companies that are a joke are the ones no longer in business.

I've been in software for 20ish years now and I can tell you that beyond couple of years of learning, there isn't anything new to learn in software. Every few years same old patterns get wrapped under a fancy name and people jump into it thinking it's something cool to learn.

Right? Young devs are just learning at the marvels of static typing languages (python, ruby and type script static typing efforts).and then, "server side rendering" (you mean like, PHP?) and whatnot...

Having been programming for 30 years I find most of it pretty funny.

One of the big differences between a startup and a big company is that big companies have to make decisions about what to build. For a smaller company that decisions is already made. It’s the reason for the existence of the smaller company.

And the cost of making the wrong decision can be extremely high and it can be hard to both identify that it is the wrong decision and to reverse it.

With smaller companies if they make the wrong decision they will simply cease to exist, but in a larger company some other product (the one that made the company large in the first place) will cover for it.

This isn’t to excuse inefficient practices, but the idea that 100% efficiency (as defined by coding 100% of the time) or even a very high coding throughput is an unmitigated good is not really valid.

> Believe me when I tell you that I could have worked on the entire software myself in 5 months

Sure. People always over-estimate their abilities, and under-estimate problem complexity. It's easy to say something like the above when you're already looking at the solution.

I get annoyed working with people like the author. "Make me code, don't make me think". I get that writing code is the most fun/rewarding part of the job, but it's not the actual job. Anybody can type, figuring out what to type IS the job.

All software sucks because deadline >>> functionality/usablity/accuracy. No matter how hard management insists that this isn't the case. In fact, the more they insist that it isn't the case, the more you can be sure that it is.

One unfortunately thing is that the industry in general struggles with incrementally improve functionality within a product over time, this goes for product managers, project manager, software developers etc.

This is why everyone wants to make every decision up front, before you have enough knowledge about what you are building, with endless meetings instead of pushing it out and learn that way.

Software developers doesn't like it because that could mean large rewrites because of ripple effects.

Product owners fears that there won't be second chance to do things, thus try to cram in as much as possible early on.

Project managers fears it is going to be more expensive to revisit functionality instead of doing it once.

This is why I primarily prefer and frequently am the lead on backend APIs. There's no BS. I spend 90%+ of my time coding and architecting the system. No bickering, etc.. Here's the API, now use it. It's a great little niche.

Having recently disengaged from full stack/front end, I have to say that I agree with this.

You have to learn to say no to pointless meetings. It's true that there are many stupid people who will try to hold them and they have to be corrected. Usually saying "I won't contribute anything valuable and nor will I gain anything valuable, so it's not the right use of company resources" will suffice. This means that you have to develop your skills so that you are not scared of acting like that (not scared of being fired). It's ok to be fired / leave a company -- the goal is to not be scared that you can't get a better job if they fire you for pushing back about meetings.

I get the frustration, but this reads like Programming Sucks [0] without the wit.

0 - https://www.stilldrinking.org/programming-sucks

Companies are a business and not academic or artistic institutes... while developer wellbeing can contribute its not a goal on its own.

If those 20 employees work on a bullshit project that could be done in a month, but at the end of the day generates tons of revenue its a good business endeavor. Could it be done more efficiently? Sure. Is it a better business venture than a work of art C++ code that was done super quickly but made no profit? Also yes.

He has some good points hidden in there but his developer centric view is so 90's I wonder if he was wearing a jeans jacket writing this.

I think I had more or less the same conversation with a coworker recently, I also have 15+ years experience in building software and I think that software is useless and the point to build a project by itself in 5 months is naive, software developers have a value if the thing they’re building serve a purpose, and the purpose needs to be defined through meeting people with the domain

To me this post has junior dev perspective but also the coworker I had the conversation with is in his 40s and I’m starting to think there is some generational thing going on here

>> we were always busy but seldom productive

that. My experience as well. Not on FAANGs but on quite a few multinationals.

>> You will argue with your colleagues and supervisor on every decision you make

and that. Politics are through the roof and driving out the good productive engineers. The people that have little to offer on the tech side though thrive in this environment creating a vicious toxic cycle.

A single developer, armed with a correct and final specification, can build software far faster than a team. However, specifications are constantly changing, and are never complete, so the number of developers you need becomes infinite. FAANG have deep pockets, so they can push their efficiency from 99% to 99.9% by hiring another ten thousand programmers.

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

> I remember we would choose to work overtime due our addiction to the problem we were solving

Oof, sounds like the author is the joke.

Why? From his description it sounds like he enjoyed it and that's probably the best kind of work.

I've spent more time on tooling for myself than i got out of it in saved time and learned a ton without pay. Alternatively i'd have been paying a match of a videogame that i'd have forgotten about by and probably regretted now.

These past days I spent a lot of time doing research into and designing an own keyboard at home. Something similar exists but is imo overpriced yet i'm not even saving money given all i've spent on a soldering iron, etc But i'm enjoying myself just creating something that i've gotten invested in.

Meanwhile at work I feel like a damn clerk. Making minor changes, arguing, pushing little bits of overhead out of the way and working slowly on something i consider an inherently inefficient design bound to require a complete rewrite at some point for reasons out of our control.

I wish i could go back to those occasional few problems I cared about to work just that bit more to get it working. In neither scenario I really cared about the overarching company but if there was never ever anything to catch my drive like that i'd have changed jobs by now.

> Why? From his description it sounds like he enjoyed it and that's probably the best kind of work.

The work will still be there for him the next day, there's no need to work overtime on it.

Sometimes entrepreneurs start a company as a joke hobby while working in a coding pressure-cooker. Then a decade later end up growing up with clients in a completely different sales field. For sure, it is easier to complain, than to take responsibility. =)

Wasn't Agile meant to address exactly the inanity of meetings described here? Interesting that the author doesn't mention it. But I guess the thirst of middle managers in large corporations for Gantt charts just can't be quenched.

I'm super sceptical of such articles. The hardest part of software development is knowing what to build, and that requires a highly skilled product manager. The latter is a full time job for even small projects with a handful of devs.

programmers think their job is to write code, but their job is to implement solutions. sometimes those solutions involve pushing back and asking the customer to think about their workflow a different way, sometimes those solutions involve tweaking something existing or fixing a small bug, and other times those solutions require writing and fleshing out a whole new module/feature/product. the only way you know what the solution reduces the risk and provides value to your client is by communicating with them.

Working with larger and larger groups of people gets harder and big companies don't have all the solutions - fortunately - because otherwise little companies wouldn't have a chance.

He ain't wrong, in fact he's right. Being a kissless virgin he fails to appreciate the importance of UX/UI decisions. But other than that, yeah

This is why a lot of programmers work after 5:00 PM. You can get more done between five and nine than you can get done all day.

What a great writer. He has a bunch of other insightful essays I really enjoy too. Thanks for the post.

I think the inflation / funny money being injected doesn't help at reducing fake working.

It definitely doesn't.

I worked in the past at a company where Softbank asked for the dev headcount to be increased as a condition of the funding. Lots of teams ended up being responsible for halves of pages, half of a microservice, etc.

my favorite - forcing signing "Code of conduct" that pretty much says you gonna try to be a good person (as if you were not beforehand)

"Tame in me the tempers four, that I may serve thee evermore. Place in me the values nine, that I may feel thy touch divine."

> Many

Most

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.

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

Sorry but you are wrong. Useless documentation, useless tests and useless arguing definitely exist, period, and they are tautologically bad. Maybe you haven't had the experience of working in such an environment where those things happen, but claiming they don't exist and twisting someone's words is absurd. Also, those wild uncharitable and provocative interpretations are also against the HN guidelines.

I'm not claiming they don't exist.

I'm claiming they're not universally bad, and that the claim they're universally bad is absurd - if unsure about the interpretation, please do refer to the initial post - you might want to start applying that charitable interpretation thing.

The author himself didn't claim they're universally bad, nor did anyone else. The only "claim" for that is in your original post, where you misquoted the author on purpose! You can't completely twist someone else's words and then use that as an argument. And I don't see how referring to a post where you're twisting someone's words has anything to do with charitable interpretations.

If you think obvious exaggeration are foundational to the argument instead of a figure of speech nothing further is to be gained here.

Besides I've provided reasoning for the elision and that went completely unaddressed, probably because assigning some absolutism to the argument that wasn't there and dragging me to court on trumped charges seemed easier

The problem is that the removal of what you call "obvious exaggeration" and "figure of speech" completely changes the meaning of the phrase and transforms the author's position from reasonable to unreasonable.

That's called a strawman. Yeah, it's very easy to do and very convenient to knock out, and I hope you had fun doing so, but you didn't really address the author's real position here, as much as you insist that you just removed "figure of speech".

About the "dragging me to court on trumped charges" part, oh, the irony. That's exactly what YOU are doing. :)

so it got all the way to the bottom, digging up "no u" arguments. ok.

I’m always up for a productive discussion, but there are two paragraphs of text before the one you’re childishly replying to, which you dishonestly chose to ignore in order to make a childish personal attack. Just like you chose to ignore the qualifiers written in the article in your original post. Sorry, but you don't get to cry foul and say you're being "dragged to court" when you're caught misquoting and then misrepresenting someone's position with a strawman. Either be honest or accept someone calling you out.

If you're really asking for an arguments: the fact you had to edit the quote should be enough clue that the original statement wasn't as clear cut as you're portraying. The fact people disagreed with you (with downvotes or comments) should also point to that. Maybe take a second to consider that you were uncharitable to the author and they're not as stupid and as extremist as you're painting them.

> you’re childishly replying to, which you dishonestly chose to ignore in order to make a childish personal attack

Jesus who's doing the personal attacks here?

Once again you chose to selectively ignore most of the message and edit it to focus on a part you can use to paint me in the worse possible light. Similar to how you did with your original post. Your only tactic in this discussion is to selectively quote people to make them look worse. You are indeed acting like a child in this discussion.

And, no: that’s not a personal attack, as I’m talking about your acts, not yourself.

Once again I’m up for any discussion, but that won’t matter as you ignore anything that can’t be used to make your interlocutor look stupid. You sir haven’t argued in good faith. You began this whole thing with a bad faith misquote, and when you couldn’t do it anymore you began to cry foul, while at the same time criticizing me for doing so. And that’s the only thing you’ve done so far: acting in bad faith.

> Once again I’m up for any discussion

really? beacuse it appears from the last six or so messages you're only interested in dissecting words, ignoring whatever meaning is therein contained, and you're only available to debate the single topic that you picked, which today appears to be wether making summaries is allowed or not while presenting an argument, and are prepared to just diss and dismiss anything unless it falls exactly in your extremely narrow debate window.

Changing the meaning of a phrase to the point it becomes a strawman is not "making summaries".

Reply on news.ycombinator.com