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

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.

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.

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.

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.

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.

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

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

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.

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

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.

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

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.

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

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.

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.

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.

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

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.

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

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

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

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

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.

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

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.

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.

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?

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

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

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

It's technically incorrect but common English.

We don't need no education

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

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.

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

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.

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

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?

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.

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.

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.

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.

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.

Baffing, cognitively?

Or is this a value judgment?

Have you observed human nature particularly in the last ten years w.r.t. echo chambers?

Wow. This looks like a quick and harsh over-generalization. This sounds like a pretty deep-seated lack of understanding.

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.

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.

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.

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?

Bind their avaiable budget to their success.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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?

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

But basically: outrage increases readership increases Medium author payout

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?

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

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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

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

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

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