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.