I can almost guarantee that you’re just at the wrong company.

Some software companies can turn even the simplest tasks into a grueling series of processes, endless meetings, and joint work across a big number of “stakeholders”. These companies will take the joy and productivity out of programming and replace it with a series of rituals and set of language that people use to go through the motions every week so they can collect paychecks.

Start interviewing around. Talk to your network. Find a company that values programming and real productivity but discourages unnecessary meetings and process. You will be much happier. There is no escaping the fact that you’ll have to work on legacy code, document your work, and meet with people some times. However, it doesn’t have to be a miserable process-filled slog.

* Small/medium size companies where you recognize most everyone even if you don't work with them. There are enough people so you don't have to do things you're not qualified for like in the very early days of a startup.

* Steady growth, but not crazy, venture fueled moonshots.

* Selling something that earns enough money to grow the business in a fairly organic way.

I worked in a place like that once and loved it, and did some of my best work there. I wasn't anxious that it would implode like a startup, and there wasn't much bureaucracy.

I think part of the problem that triggers this is in small companies, one engineer codes, a significant portion of the code base and has a strict vision in their mind about how that code should be structured. When new employees come in to bring new ideas, they become personally offended that their baby is no longer their baby. At large companies no one feels like they own 100% of the code, and each change is very collaborative.

That's how you end up with endless process, design by committee, and having a dozen meetings with all "stakeholders" before actually writing any code.

I'd much rather work at a place where individuals or small groups have a strong vision on the code and product and are capable on executing independently on that. It sounds like the OP would too. But I understand it's a personal preference.

I guess that’s why large enterprises hate it, since they’re all about reducing risk.

If they get middling software every time then that’s preferable to the two extremes.

Indeed. No company size is perfect. There are dysfunctions typical for small companies. There are dysfunctions typical for large ones.

But people have preferences; some things they can handle, other things drive them crazy. What drives you crazy may be different from what drives your friends crazy.

Perhaps everyone should try to work once in a large corporation, and once in a startup, to figure out their own preferences.

Or to be kinder. If you are filling your own hole (identified need) you can be more free in your approach. After all only you decide if it's right, finished, a failure or success.

Isn't that dependent on whether you are the person guiding the code though?

What I vastly prefer is the 500-ish size. You can realistically at least know of every other developer (and find those you prefer working with and can learn with), there's more resources than just a 30 person company, and you're just not a tiny insignificant cog in the machine at a 100k mega corp.

Make sure you have solid metrics on your side to record problems with that microservice, document any delays caused my missing features, and eventually even non-technical management should get your point and start to apply pressure.

Usually management doesn't want to participate in these discussions, because they are more careful about retention (and stepping on toes). 1 engineer quitting is a 10% reduction in their workforce.

We must have worked at very different places.

This happens extremely frequently and is in fact entirely normal.

Everyone wants the problem solved, but how the problem is solved leads to frustration.

When MBA culture took over in the 80s it became normal for companies to act like extraction machines. Employee loyalty crashed, with a corresponding increase in churn.

Taking investment money makes it hard to create a humane culture. But smaller private companies do at least have the option to consider it.

Some types of businesses can do it more easily than others. Professional services can probably do it the easiest. A B2C business with a turnkey offering could have a lot of trouble paring back, especially if the product has a physical aspect.

What did they change/do? If I may ask

Eventually, they tried to get us to integrate with more and more of their other products, which introduced a TON of extra "stakeholders" on every single project.

With every extra stakeholder they also had to introduce extra meetings and extra process until even making a small change felt like a massive chore. I went from merging dozens of changes a week to maybe one or two.

Felt pretty claustrophobic after a bit so I ended up leaving to go somewhere smaller.

> integrate with more and more of their other products, which introduced a TON of extra "stakeholders"

That scenario I hadn't heard about before. Good to know about that way for things to fail, too.

If you haven't seen:

"Excess management is costing the U.S. $3T per year (2016)" https://news.ycombinator.com/item?id=34290539

- Paperwork - Extra managers - Lots of "stakeholder management"

After 14 years in a workforce, my happiest moments were in software SMB (joined at 10 people and left at around 100).

Never felt like work. We were just building something cool together as a team on the same page.

Turned profitable after Series A and never raised again.

Later down the road I realised that these are the real unicorns once I actually landed in terrible jobs or corporates and how disengaged everyone is in the legacy organisations. Was genuinely shocked that these companies don't go out of business.

I am now trying to collate the list of companies which fit the criteria above but it's really hard.

Because it’s a statement about men or because of the implied possibility they could be unhappy in their marriage?

Also, why is it horrible?

It appears this world has become manically trigger-happy to label something as -ist or -istic, when it contains even only a hint of something someone could possibly understand the wrong way.

It would be curious to examine in a psychological study if this reinforced behavior has developed more due to a subtle social reward system for the “labelers”, or due to a punishment system for the “non-labelers”.

So now you can't make a quip about wives unless you also make a quip about husbands (or else generalize it to "persons") though even these are now too restrictive for some. Heaven help you if you dare observe that there are differences between men and women, complementary differences no less, that lead to humorous tensions between them and peculiarities particular to each that surface within their shared lives.

Shall we raise a toast to ourselves, savaged men (and women!)? Humor is dead. And we have killed it.

Welcome to Western society, you're privileged and you should be guilty and ashamed.

How did we get here?

I think there is probably a happy medium of wokeness that can be reached via measured discussion between respectful adults. I think in real life (at least in my experience) people are willing to have those discussions, and are much less polarized and divisive than the internet/cancel culture might have you believe.

The expression "privilege" itself makes people feel attacked and get defensive. If you say the same exact sentence replacing "privilege" for the definition and it greatly changes how people react to what you say

The source of unhappiness for women seems to be the reverse. A husband that’s not doing all the things she nags about automatically.

I think priorities are just fundamentally different somehow.

To understand it better it is worth noting that it is a bastardization of this misquote commonly attributed to Socrates: “By all means marry; if you get a good wife, you’ll become happy; if you get a bad one, you’ll become a philosopher.”

As detailed in this ( https://qr.ae/pvP31C ) answer on Quora, Socrates never said (or was never recorded to say it, he didn't write down his philosophy) this exact thing. But there is a recorded dialogue that is plausible as the source of the simplified quote.

While less clear from what kraig911 said or from the original dialogue, the commonly spread (meme) version of the quote, which I pasted above, makes the misogynism clear. I hope further explaining that is not necessary.

It is important to note that Ancient Grece was very gender unequal, so a misogynistic quote in that social context is not something surprising, even for one of the brightest minds. That is just how society was in those times, and those philosophers did not get the benefit of hindsight we have today.

Besides, as stated above, Socrates didn't actually say that misquote. He was commenting about the challenges of his relationship with his wife. From that dialogue, it is even implied it was a conscious decision he made.

The misquote is especially dreadful because it is a generalization over the entire feminine gender. I am now quite curious when exactly in history did the misquote take its commonly known form.

I am quite surprised that of all the people commenting, no one attempted to go to the source of that meme. Instead, everyone just espoused their viewpoint. I wish HN to be a place of knowledge seeking, not a place of culture war.

Edit: looking into this a little deeper, Spencer McDaniel, the one who wrote the Quora answer linked above, has an entire blog about ancient times and expands on the issue of misquotes: http://talesoftimesforgotten.com/2019/07/16/fake-and-misattr...

1. Can only be married to a woman, sometimes a pre-arranged woman

2. Has religious or cultural norms keeping it that way

3. Improving the marriage is the woman’s territory

This is probably a realistic aphorism for a larger group of people than those who can call it misogynistic.

Had that been said in person, even with someone we only recently met, we’d have “known” what it was meant to mean and that it was just a figure of speech to support their main point. Online, people will read every word selected and choose to vilify you for using a pronoun or some other random extreme literal take on your word choices without really considering what your intent or meaning or that you is (often there’s not much, it just happens to be the choice of words they made while typing on a tiny device and trying to be concise). It’s also not considered that online we’re intermixing generationally, culturally, economically, and so many ways. When a 50 year old person says something like the word “retarded” it may feel normal and they are ignorant of the fact that anyone under ~30 knows not to even say that word, it’s the “r” word. Then you have the other “n” word that everyone knows is unspoken except it’s found and heard everywhere because some people can and do say it steadily.

As an example, I frequent a local subreddit for my city. Something that regularly comes up is crime and homeless and such. If you have anything to post there. Someone else will invariably reply with yes but redlining, Jim Crowe, disenfranchised citizens, etc. Those are all base general knowledge and historical facts for sure. I think everyone is well aware of them. But, it’s difficult to have any discourse when the audience expects a full historical account of why the situation exists before solutions can be discussed. It’s pretty tiring and I’ve basically stopped chiming in on those kinds of things.

TLDR: communication is hard and text only is really hard.

> It would be curious to examine in a psychological study if this reinforced behavior has developed more due to a subtle social reward system for the “labelers”, or due to a punishment system for the “non-labelers”.

This is intriguing by the way.

doesnt sound like any -ism to me

Yes it does.

Did it do it right?

Nowhere it is implied that an unhappy marriage for a men is due to women in the marriage, if I had to guess, unhappiness in marriage for men is tied to having kids.

Anyway, focusing on the fact that it says "men" instead of focusing on the fact that it says "unhappiness" says a lot about the priorities people have nowadays.

It's like reading "The Fox and the Grapes" and focusing on the fact that there's a talking fox trying to eat grapes.

Additionally, consider that you are the one bringing the nagging wife trope into this: it's merely one of many possibile explanations and unhappy marriage.

Saying "I was in an unhappy marriage and it made me a great philosopher" would be fine. It's the generalization which is an issue here.

The mature way to approach the problem is to work together to resolve the issues -- or if that isn't possible, terminate the relationship. You can't just make yourself the victim and say it's all the other's fault.

It's not; it's the result of a vocal and aggressive mob - people are taking care to not draw the attention of the mob.

All of that isn't actual agile. It's Fauxgile and has nothing to do with what agile is about, which is about removing impediments to productivity, removing meetings (why were there standups? Because they shouldn't exist in the first place, and if you absolutely positively can't avoid them then at least make them as short as possible by making everyone as uncomfortable as they should be) and laser-focusing on actual productivity.

> (If agile is done well though it can be amazing but that's another topic to me)

Yes. I would phrase it as: if agile is actually done.

Sorry, but anybody who thinks Agile is about velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc. has been sold a bill of goods. Now that's not to say that those things don't have (some) value. But they aren't "the thing" about Agile. Not even close.

Spot on. You and parent have hit the two points that matter:

1. Agile is about removing impediments to productivity

2. velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc are all, in some way, impediments to productivity (even if they do have some value).

I think the real reason you cannot have real agile is because businesses don't run in a way that is compatible with agile, so over time all processes within a business will evolve to match how the business itself functions.

Except it's not even really about productivity, it's about outcomes. The productivity is only important insofar as it achieves the outcomes. The ideal agile process would have the team on the golf course or in the spa but still changing the world (any suggestions on achieving this, gratefully accepted, as always).

Sadly, I think you are correct. It's very hard, at best, to make "the business" operate in a way that's truly compatible with the agile approach on the tech side. :-(

I won't say it's impossible, but it's definitely not easy.

For me the value in Agile is what we end up NOT doing - we never get to that shit because in the end it's not that important. So we never waste time doing it.

So really, you're never "doing Agile". You're "doing $X" where $X can be Scrum, XP, Crystal, AgileUP, SAFe, or whatever. At most companies what you get, in my experience, is a bastardized version of Scrum cobbled together by somebody who has never actually developed software, took a couple of Scrum classes (maybe), paid too much money for some "help" from some "Agile coaches", and is hoping some of the resulting shit will stick to the wall.

FWIW, I've actually had the pleasure of working at company that did Scrum and really did it well, and it was honestly a great experience. Actual Scrum, as documented in the Scrum Guide, isn't bad. The problem is when people take base Scrum and start tacking on additional shit (see: "agile coaches" and "agile consultants") and wind up with a bureaucratic / kafka-esque tarpit of interminable meetings, ceremonies, and artifacts. In other words, pretty much exactly what the Agile Manifesto stood against in the first place.

Which is different to saying anyone trained to be an engineer will be able to get stuff done. But getting stuff done was always a recnognised requirement of an engineer; i.e. by definition they should be getting stuff done.

[0] https://agilemanifesto.org/principles.html

https://scrumguides.org/scrum-guide.html

Ctrl+F "JIRA" - 0 results

Ctrl+F "velocity" - 0 results

Ctrl+F "on-call" - 0 results

Ctrl+F "manager" - 0 results

Selected quotes:

> Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

> During the Sprint: No changes are made that would endanger the Sprint Goal;

> The Daily Scrum is a 15-minute event

A short version is that you have a small team of intelligent people who are given sufficient autonomy. They split time into intervals called "sprints", each sprint is 2-4 weeks long. (If you have no experience with Scrum, start with 2 weeks. When you get used to it, the team can decide the correct length.)

At the beginning of the sprint, the developers and the representative of the customer agree what gets done. During the sprint, the developers do it. Every day there is a short meeting in the morning, when developers say "I completed this; I am going to work on this; I am blocked by this", nothing more.

At the end of the sprint, developers show the implemented changes to the representative of the customer. Then the developers talk among themselves about what was good during this sprint, what was bad, and what they want to do differently the next time.

The important thing (ignored at almost all companies pretending to do Scrum) is that in this ideal world, managers do not exist. Developers manage themselves. In the daily meetings, developers report their progress to each other. What needs to be done, is decided by the representative of the customer (literally a person from a different company, or from a different department if this is an internal project). How it gets done, that is decided by the developers. When developers talk about what was good and bad, and what needs to be done differently, they actually have the power to do it differently the next time. Developers assign the work between themselves, and make estimates how long something would take.

Shortly: the developers are treated as adults, and their responsibility to the customer is defined on a biweekly or monthly basis.

Just stick to the principles of focusing on the product customer value over the processes themselves, with recurring reflection over how your process is working, as per the agile manifesto.

If your company hasn't done this before, Scrum is a good starting point, but it is by no means a goal nor the final destination. This is where most companies fail.

I did leave and the company did crumble shortly afterwards. The main reason wasn’t related to processes, though. It was already too late when the faux-agile was introduced.

Constant reflection and drive towards faster feedback. XP or if I squint Scrum can be a starting point, but you gotta adapt to the individuals on the team and the characteristics of the type of problem you are solving.

Read the Agile Manifesto. That’s what Agile is. All else is either: - (good) trying to implement the Agile Manifesto, or - (bad) trying to make current process appear like Agile.

“Fauxagile” *is* agile, because thats what the majority of places in reality do.

“Agile” needs a complete rebrand.

Who gets to do things that they have experience in all the time? Not me at lest. And what manual do you read ? There's almost never anyone who understands it all quite apart from having written "a manual".

Some of the principles are actively harmful, like welcoming changing requirements late in the process.

"Individuals and interactions over processes and tools"

OK, not terrible, but why not "interactions and tools over individuals and processes"? De-emphasize individual's egos and ritualized processes, focus on the things that get work done and communication between entities.

"Working software over comprehensive documentation"

Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.

"Customer collaboration over contract negotiation"

Fine. You'll still need a contract, but it's definitely important have a collaborative rather than adversarial relationship with customers.

"Responding to change over following a plan"

Tends to make sense when gathering requirements, turns into a horrible idea later on in a project. Also fails utterly when working with something like a factory (making a hardware product with embedded software). If your entire view of software is web apps, this one seems like a good idea. If you're making something with a manufacturing deadline, it's a recipe for disaster.

So that’s the why. You can ask for elaboration, or disagree with the results, but the opinion of the signers of the Agile Manifesto, based on their experience, is that to prefer the former over the latter, while acknowledging that the latter principles have value, they tend to succeed (and enjoy their work more) when deciding between the two (there are always trade offs) to give greater weight to the more lightweight, practical, and less rigid values — hence the use of the word “agile”.

> Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.

Another problem:

It makes onboarding new engineers difficult. Without any documentation on what each API endpoint does, or the purpose of every repo, getting an understanding of how the system works ends up requiring scanning through code manually or taking a lot of time from other engineers asking questions.

It's especially bad when microservices are given non-descriptive names like Galactus or Omega Star.

The point is that documentation by itself doesn't deliver any value, and there are diminishing returns with amount and detail level of documentation.

Agile doesn't say you shouldn't document, it says you shouldn't spend more time documenting your API endpoints than Implementing them.

You can get there with a big document for a program that doesn't work

You can't get anywhere with a program that works and no document. You might get sales, but that's someone else's job

I certainly would have preferred just a big document instead of the code I was given on my current role

The distinction is more about how granular you need things. Do you need to negotiate every piece of business-logic and get signoffs on mockups up-front, and in the case of paying customer, rather than internal stakeholder potentially including placing them into a legal SOW? Or can you just agree to a bullet-list of high level functionality, and then establish a working arrangement to receive feedback and refinement. Build and MVP and get some use, then make it better. Likely the initial understanding of the requirements was flawed anyway, so being reactive to the change, with buy-in from the customer will be a better plan for success. But yeah, this might not work with physical products.

This means something a little different. It wasn't talking about "end-user" documentation. Rather, it meant "product specifications." Do you need to design the system upfront in UML before you start writing code? You may still need something like a whiteboard sketch or something similar, but that wouldn't be "comprehensive."

A lot of the points in the manifesto turn out to be slightly redundant. Comprehensive documentation, as entered into a tool, is wasted time when what you need to do is spend time with the customer developing their ideas into good software.

TLDR: Businesses purchase development effort in terms of contracts, and the contract is almost always "You will deliver $X for $Y amount, in $Z months or less". Agile is the opposite of that as far as business is concerned - "We will pay $A per hour until our money runs out or we are satisfied with what we get".

I've never understood this one, to be honest. Business runs on contracts; in any interaction with the outside world (suppliers, customers, employees, etc) the businesses contract is what makes or breaks that interaction.

In 999 out of 1000 cases, no contract == no interaction.

I mean, look at it this way: when you ask a crew to paint your house, you specify the colors upfront. You don't iterate with them on after every room, or every wall.

You certainly will not engage with any crew who wants to paint your house using the guidance of the Agile Manifesto, because then you'd have little to no upfront indication of the cost, you might have a house not gully painted (because you're paying per hour for their time, and once your money runs out they stop working).

Agile works great for teams internal to the business - the money never runs out unless the business shuts down. But for external developers, the business cannot engage without a contract, and that contract will be "You will deliver $X for $Y in $Z months", and not "We will pay you $A hourly until we are satisfied with the result".

The practical result is that the agile way and the business way are entirely opposites of each other. This explains why dev teams within companies constantly complain "This isn't Agile!" ... because business is trying to enforce some sort of "Deliver $X within $Z months" and the agile team is working with "We'll collaborate until the stakeholders are satisfied"

"Oh, we hit our schedules and costs 100% of the time", she said.

I was incredulous, so I pressed her on the point.

"Well, compared to the contracted schedules and costs, we run 200% over on average by the time we deliver. But what happens is that customers quickly figure out that what they contracted for isn't anything like what they actually need. And every time a requirement changes, we add time and money. A lot of time and money. More than enough to make up for any actual overruns. So we always hit our schedules and costs exactly, by the time we're done."

In short, "We will deliver $X for $Y amount, in $Z months or less" is a total scam.

...

> In short, "We will deliver $X for $Y amount, in $Z months or less" is a total scam.

How is that a scam? "We will deliver $X in $Y months for $Z money" is easily predictable by the client when the client wants to change $X.

If the client doesn't change $X, the client can understand what they will pay and when they will get it.

When the client changes $X to $X+a, they still understand that delivery will be "$x+a in $Y+b months for $Z+c money". In fact, the original contract they signed made it clear to them what the cost and time was for changing requirements.

More to the point, when they want to make a change, they can balance the need for the change against the cost and time. Even better, because they know these things upfront, someone at the client will have to approve the cost and delivery time for the new requirements. That person is not going to give the supplier a blank cheque.

It's a good deal better than "We deliver working parts until you are satisfied or until you run out of money. We cannot tell you in advance how much this will cost and how long it will take."

I mean, if experienced developers are unable to get their software development supplier to deliver with only a small margin of money/time overruns, what hops is there for the procurement person at any company?

Since external customers and non-swe stakeholders expect binding contracts and even waterfall, I would consider it essential to learn how to interface agile processes with the said contract-driven stakeholders. Telling them that we are trying our best just doesn’t work.

What's the alternative? Never have contracted-for software? Only accept contractors who are prepared to do Agile?

How does the procurer then put out bids, without having requirements up front?

How do they evaluate bids from various suppliers without knowing what the final bill is? How do they shortlist the three "best" bids with no costing information? How do they even know if they can afford it?

How are the suppliers supposed to submit bids without knowing what they are going to bill for?

How does audit make sure that the process was fair?

Once you start supplying/developing software for companies that are large enough to have a procurement department, you better believe that the process all runs on paper[1].

[1] Or the digital equivalent.

This isn't a useful analogy - more often, it's like asking a crew how much it would cost and how long it would take to paint your house, except the house isn't built yet, you're not sure what you're going to use it for (or whether you'll actually use it as a house rather than a B&B), plus you reserve the right to change colors at any point in the process.

Internal teams! My work these days is directly with people paying for the thing. That's why Agile gives me the shivers.

In reality people change their minds - especially when they see the software - so there's a lot to be said for building it incrementally and showing it to them.

The fact that contracts don't suit this behavior might explain why contracts are such an awful way to get software and why they so often go wrong.

> In reality people change their minds - especially when they see the software - so there's a lot to be said for building it incrementally and showing it to them.

Doesn't matter - the people paying for the software are not the ones that are going to be using it, so showing it to them is pointless (they just want their bullet points/requirements checked off).

Showing the software to the users is equally pointless, because they don't have the authority to request changes (any change is a bill that has to be approved).

See my other reply to you: https://news.ycombinator.com/threads?id=lelanthran#34381865

> The fact that contracts don't suit this behavior might explain why contracts are such an awful way to get software and why they so often go wrong.

Maybe, but unless you have an alternative that addresses the problems in not having contracts, there's little point in telling other people that they don't understand the problem.

This was written in a time when documentation/spec was often written before the software, without taking into account the difficulties of implementing it.

Agile seems to imply that software comes before documentation in terms of priorities.

Which country implements pure capitalism? What would that even look like? 0 tax? having to pay private police companies? ....

Agile was the best of times, Agile was the worst of times, Agile was the age of wisdom, Agile was the age of foolishness, Agile was the epoch of belief, Agile was the epoch of incredulity, Agile was the season of light, Agile was the season of darkness, Agile was the spring of hope, Agile was the winter of despair. -- Paraphrasing Charles Dickens

I don't think you're wrong, but I should point out that Agile started out as a rebellion against "meetings, rituals, and meta-work and not actual productivity". As somebody who got involved in one of the Agile tributaries before the term "Agile" was coined, I'd say the actual problem is older and deeper.

I look forward to another rebellion, but would-be revolutionaries should make sure they don't fall into the same trap, or you too will see your new terms and bold ideas corrupted to the point of meaninglessness.

On top of that, like most popular languages and technologies it isn't really good enough for people who care, but it's good enough for people who don't and also happens to please "biz" people.

Agile was created to beat exactly those things that you are mentioning. Then Agile became big, enterprise became aware of it and smothered it with their rituals, processes and bureaucracy. And now we're back where we started again.

It’s just a buzzword for practices that people would be doing better otherwise without all the bureaucracy. Pretty sure one of the original authors of the manifesto declared it dead too, but I’m not going to google it because honestly the agile manifesto is not a religious text to me and I think the whole industry grew out of a single fairly common sense idea that got utterly co-opted by snake oil salesmen.

Like DevOps.

And all of these people are completely gated off from interacting with the people actually building applications by a byzantine process involving ServiceNow tickets, MS Teams messages, eldritch incantations to Elder gods, ritual sacrifices, and the phrase "The goat doesn't need to be very big, but it does need to be alive."

Cthulhu is a lot easier to please.

Waterfall had its own endless set of meetings and downsides. I'm not sure agile changed that at all in the large, regardless of how "well" agile was implemented. Some teams did have project management that "shielded" teams, but that can happen under agile too, depending upon how it is structured.

I've found that in many cases, that generally makes return on investment hard to keep track of, and I think that most companies want profit. Balance is the key though and balancing what you describe as bad with fast shipping, I think is the best of both worlds

I'm not sure I understand what this means, can someone clarify for me?

Explaining the meaning of a bad meme is not interesting but if you are still asking what it is supposed to mean then here goes:

The first half is obvious because it is a tautology. It states that "An X is an X."

The second half implies that unhappiness pushes one to become a philosopher because they start thinking about how they became unhappy. Why? Who knows. Most unhappy people do not become philosophers, but some might. Also, not all philosophers are unhappy. Also, gender and being married or not have nothing to do with becoming a philosopher.

You are correct that it's confusing why the implication should go without saying. It's because it doesn't. It's a simplified rewording and further generalization of a misattributed misquote meme that is itself a generalization and mischaracterization of a dialogue line of a philosopher describing his own situation and his own choices.

As for why happiness is less productive then unhappiness, there is this gem of an explainer: https://www.youtube.com/watch?v=yWkq7btSQvs

I see, thank you for the explanation.

That's definitely not how I view philosophy or the motivations of those who think deeply about such things, hence my confusion.

https://news.ycombinator.com/item?id=34380697