> I have come to a realization that I don't really enjoy Software Engineering(& the processes that it comes with) but I do love programming & solving problems.
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’ve worked at 3-4 small companies (less than 30 employees) and I’ve never been happy. There is always 1 person that makes my life miserable (constantly rejecting my ideas, ego is larger than their experience level, etc). I’ve worked at a 100, and two 1,000 engineer count companies and I never met any “coding princesses” in those roles.
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.
> 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 read something about how a lot of 'super group' bands kind of don't do anything truly great because of this type of dynamic. They all know they're good, they know the others are good, and they all have a bit of an ego and don't want to stomp on the others, so they all tend to "go along with it" without getting too pushy. That leads to good, but not great music.
Enterprise software isn't middling, it's usually only barely functional and falls just short of what it should do (i.e. it's shit). Everyone is just so pathologically used to it they think it can't be better. Probably due to the allergy to risk that you mentioned. Ironically risk is eliminated, but in doing so you've just ensured you have consistent problems that can never get better.
I think part of the idea was that in an actual band that has been a band for a while, they usually find a way of working together that includes "difficult conversations" and saying no, and sometimes listening to one person's vision rather than tiptoeing around egos.
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.
Small groups of 1+ with a vision isn't really software engineering though. You aren't building to solve someone else's problem and it's that which is engineering. Turning up to the beach with bricks and cement on a whim with mates to create a small damn because it's your vision?
Well that's kind of build it and (hope) they will come.
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.
"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"
Isn't that dependent on whether you are the person guiding the code though?
Honestly, not necessarily--there are often many ways to solve a given software problem. If someone else has a vision for the software and a plan to achieve it as a team, as long as I can see that it is looks like a viable alternative I'm generally happy to go along with it. Far better than flapping in the breeze with nobody providing clear guidance or input, in my opinion!
> I’ve worked at 3-4 small companies (less than 30 employees)
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.
It really depends what team you're on! My little corner of megacorp is fast, pretty lean, and I definitely feel like I am able to make an impact on our product (which is a smaller product in the company). I feel much better here than at some of the mid size companies where I felt there was a low ceiling on growth opportunities.
Oh, I've definitely met princesses at large companies, though you are spot on about the ownership issues. The problem really isn't the size of the company but how siloed the code is.
Yeah, one of the 1000-person companies had a dev whole-own a critical microservice. Changing it was always a battle, because the owner was very critical of anyone touching 'his' service. Large companies aren't immune, but due to eng specs and collaboration baked into development, its less likely for this to happen.
It looks management was a problem too, as "wholly owned" is a double-edged sword, especially if it's a microservice.
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.
Problems were resolved and everyone was professional, but there certainly was more friction than necessary.
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.
Are you ideas normally implementable in the next month or something far-fetched?
Try to come up with ideas that are low hanging fruits, easy to do but have a high value.
I don't think any company/management in their right mind would constantly reject "good" ideas that ultimately result in more revenue.
The ideas I see being rejected are either too far out there or some "dev utopia"-kind of ideas that don't bring in more cash, just burn effort.
Yeah I could see that. The place in question where I worked was developing some new products, so we didn't have that kind of situation where someone was gatekeeping or otherwise being unpleasant.
I worked in a place like that and it was awesome. Unfortunately we were so good at what we did across the board that we got bought by another company to integrate into their larger offering. It made a lot of sense from a business perspective but the tech team in our office was made redundant and so my time there came to an end. I think this is the inevitable conclusion to good, small companies. Since it actually works they will eventually get swallowed by a larger fish who rightly identifies them as a tasty morsel.
Is it really that hard for owners to resist the alure of a buyout? I dunno, I always like to think that I’d continue doing the good thing that I’ve got going.
The two aren't unrelated. In the distant past companies had professional and personal development programs. Some even had a commitment to try to avoid layoffs.
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.
Yes and the same works for founders. If they expect, they will hate it after buyout, they will probably resist.
But what if new opportunity is ok, gets you 30% more money, but your departure makes your current company very sad and perhaps worse place for everyone to work at?
I wouldn't expect a lot of support for the idea of staying if you ask the internet for an opinion.
Sometimes you're kind of forced into it: if your growth starts taking off faster than you thought, you may be in need of more capital just to stay in business. At that point you have a choice: slam the brakes (turn down customers), borrow (risky), raise (dilutes you), or sell out. If you can find a solid working relationship within the acquirer's company, all is good...
There is actually nothing wrong with turning down business. No need to grow faster than you can handle. A company in the situation you describe is doing something very right, so maintaining that seems like a good strategy.
There is nothing wrong with it, but it's hard to do skillfully, especially in the chaos generated by rapid growth, and you may not realize the need until you're already trapped by your existing commitments. Good relationships in the company can fall apart in the decision-making, too (e.g. if someone's personal/career growth path is cut off by the decision to stop pursing something that's been built towards for years.)
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.
For an entrepreneur who set out to fix a problem in the world, it can feel very wrong not to give customers the solution that you know you can give them, for mere capital reasons.
I was going to say the same thing. Worked at a mid-sized startup, great culture, amazing coworkers that I'm still friends with today. We did great work and got bought out by a large company who had promised not to mess with our culture too much. That didn't last very long haha
It was a very slow creep of changes. For the first year, they really didn't change much (except gutted our health insurance plan and got rid of "unlimited" vacation).
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.
The company we were acquired by is massive ($2bil annual revenue, 7.5k employees). If you live in the US, I can guarantee that you've used their products before but don't know the name of the company. They basically just go around acquiring other companies and absorbing them into their other products. I'm talking like 10+ acquisitions a year (at least for the last few years).
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.
Might be the exception but I’m at a company with tens of thousand of people and we don’t have many rituals, if you want to solve a problem you go and do it. But you do have to own your solution.
1000x times this. It's a weird thing our profession. There's a horrible but apt (misogynistic even) saying. Happily married men are happy husbands - Unhappily married men are great philosophers. I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity (If agile is done well though it can be amazing but that's another topic to me)
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”.
It is currently culturally fashionable to construe things in this manner, so unsurprising. It is humorless and lacks common sense. Reasonably intelligent people understand context. They do not flatten all of reality and reduce everything to their favorite pet paradigm, projecting uncharitably all sorts of weird baggage onto the most innocuous of statements.
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.
Common sense is dead. Certain groups of people lack self and/or social awareness to notice that they've replaced religion with ideology. For example, we criticize religion for shaming many parts of our sexuality "Welcome to church, you're a sexual being and you should be ashamed". Now that's been replaced with "You're a man, you should feel guilty because you're from the oppressor group." etc.
Welcome to Western society, you're privileged and you should be guilty and ashamed.
OK I do think there is an issue with wokeness in society. But, I also think there is a problem with anti-wokeness that can be seen here with people chomping at the bit at the first (poorly attributed) use of "misogyny". Women aren't even mentioned, and the only way I see them/misogyny even entering the equation is if you make the rather odd pair of assumptions that an unhappily married man must: 1) be married to a woman, and 2) be unhappy exclusively as a result of his wife. You could attribute it to the result of the woke hivemind's effects, but you could also very much not! It's effectively an unintentional strawman...
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
That's a good point. There's absolutely no reason to feel bad about being privileged. You should be happy! Perhaps spread some of that happiness around, make the world a happier place. Everyone wins.
There's a slight implication because it only covers men that women are the source of unhappiness (e.g. the nagging wife trope), but I agree it's trivial and likely unintentional. Agree with sibling, just as applicable as "happy married people are happy partners, unhappily married people are great philosophers".
I'm surprised you've never heard of a woman being unhappy because her husband wants her to do/be one thing, and she wants to do/be another. "Nagging" isn't always the stereotypical annoyance.
You're clearly passionate about something here, but it's not totally clear what it is or why. It might be interesting to read what you have to say, but you need to chill, organize your thoughts, and stop calling other posters idiots for disagreeing with you. Right now it feels like we're catching half of an angry shower argument against someone who's not here.
I can tell, because I've made posts like this before, and I always regretted it later. Have your angry argument in a journal or text file (Lately I've really liked Markdown with source control). Then revisit it later, and add in the side you're arguing against. Then revise it so that you're actually making a clear point, and remove all the personal insults. Then post it here, because I want to read it. But until then, I have no idea WTF you're on about or why you're so defensive of a very-long-dead philosopher.
What? I found their post informative and yours extremely patronising. They're not defensive about Aristotle, they are pointing that the quote seems to be misinterpreted because it's about relationships between men and woman.
> But most of all, dear friends, that quote is 2,300 years old! Was Aristotle misogynistic?
Yep
> In his work Politics (1254b13–14), Aristotle states "as regards the sexes, the male is by nature superior and the female inferior, the male ruler and the female subject".
> While Aristotle reduced women's roles in society, and promoted the idea that women should receive less food and nourishment than males, he also criticised the results: a woman, he thought, was then more compassionate, more opinionated, more apt to scold and to strike. He stated that women are more prone to despondency, more void of shame or self-respect, more false of speech, more deceptive, and of having a better memory.
_________
> apparently nobody has ever read the great philosophers.
The introductory paragraph makes it seem like the extent of your claim is he noticed the same behavioral trend as most psychology surveys:
> Among women's differences from men were that they were, in his view, more impulsive, more compassionate, more complaining, and more deceptive. He gave the same weight to women's happiness as to men's, and in his Rhetoric stated that society could not be happy unless women were happy too.
I think you’re really stretching the word “misogyny” when you’re using it for people who accurately describe reality and view male and female well-being as equally important for society.
You are a misogynist. This is literally the first sentence. Your post is shamefully misleading.
> Aristotle saw women as subject to men, but as higher than slaves, and lacking authority; he believed the husband should exert political rule over the wife.
Yawn — you name calling because you think a cherry picked quote about family dynamics defines an entire philosopher’s view is the bad faith I’ve come to expect from people of your persuasion.
Your post is more misleading than mine: you’re hanging your entire opinion on a de-contextualized cherry-picked line and using that to ignore other parts of the philosopher’s work.
Go on, scream about how everyone who disagrees with you is an istaphobe — nobody cares.
I broadly agree with your point, but then you decided to search for quotes that apparently support your argument, and you picked... Schopenhauer, in a discussion about misogyny and marriage, which is pretty hilarious.
I'm sorry, it really isn't a big deal and I don't think anyone would be triggered or offended by the quote! And of course historical context matters. The poster was just proffering a friendly reminder that to push society forward it's helpful to consider these things.
It's just like changing our default branches from master to main, honestly probably not a huge deal to any rationale person, but the cost is negligible so why not?
It's possible to be empathetic and considerate, making minor adjustments (and also not judging those who innocently don't) without being the "woke" police!
> he poster was just proffering a friendly reminder that to push society forward it's helpful to consider these things
It is totally not.
As Ricky Gervais put it beautifully, like it or not, if you categorize the people of the past with the standards of today, you are preparing the people of the (near) future to categorize you about what you say today.
Now imagine that people think of Aristotle as a misogynist, like if it is actually important, he died 2,300 years ago after all and nobody studies Aristotle because "and now let's read about that guy who hated women, because it's something important to learn: women are trash", but
By the 1930s, a new kind of human zoo appeared in America, nude shows masquerading as education. These included the Zoro Garden Nudist Colony at the Pacific International Exposition in San Diego, California (1935–36) and the Sally Rand Nude Ranch at the Golden Gate International Exposition in San Francisco (1939). The former was supposedly a real nudist colony, which used hired performers instead of actual nudists. The latter featured nude women performing in western attire. The Golden Gate fair also featured a "Greenwich Village" show, described in the Official Guide Book as "Model artists' colony and revue theatre."
Sorry if I stand with Aristotle, despite him being a man of his times, and not with 20th century human zoo.
edit: to put it simply, should we talk to German people or everytime they try to say something we should shut them up reminding them that they did the holocaust?
When I disagree with someone from the US, can I use "you are the only people in history to have dropped two atomic bombs on civilians, you are wrong by design!"?
Why Aristotle is problematic, but nobody says "he was a Trump but a lot more intelligent than Trump and actually, now that I think about it, he never said <<grab them by the pussy>>, so Aristotle was less misogynist than Trump"?
Aristotle has never been POTUS.
I understand pushing society forward, so why blame people who have died thousands of years ago for things they are not responsible of today?
Does someone really think that quoting that sentence from Aristotle will plant the seed of misogyny in people's mind?
Is this really the kind of trust we have in each other's intelligence?
I believe people can read the context loud and clear.
He was a misogynist. That’s a fact. Yes, the standards have changed. It doesn’t mean we need to throw out everything he said, but sticking your head in the sand and ignoring a basic quality of his thought because… I’d not know why honestly? It’s threatening? thats not the way forward.
That is wildly untrue. The research on whether men or women are more satisfied in their marriages shows that they have about the same levels of satisfaction.
Not really sure why the demographics of philosophers effects the impact of the statement. Most philosophers are white, would it have been more impactful if the statement had brought race into it?
If you could bring race into it somehow then yes the statement might seem more based in historical precedence, rather than some idealistic fantasy world of hyper diversity, assuming most unhappily married men are also white.
I don't really get why any of that matters though. Can't you just appreciate the sentiment regardless of how it is phrased? Seems like your trying to make it political when it just isn't.
Idk man sounds like they’re just taking a phrase and phrasing it slightly differently so that it applies to more people. You’re the one who was offended by that
That's not what he said, and I doubt it's what he meant. Many people who disagree with me are not dipshits, but the ones who are seem to take positive joy in being disagreeable.
It’s bland, safe, and lifeless. The statement has no bite.
The original statement will be read by men and some men will connect to it right away, because rather than envision some abstract person, they are made to immediately picture a man, and in that image they may recognize themselves, like looking at a mirror.
> The original statement will be read by men and some men will connect to it right away, because rather than envision some abstract person, they are made to immediately picture a man, and in that image they may recognize themselves, like looking at a mirror.
Sorry, are you saying that the audience of the statement is on purpose only men? If so, how could you possibly support any claim that it's not misogynistic?
I really want to take your argument as a reason why it's 100% ok to phrase it exclusionary, but then I get a response like this https://news.ycombinator.com/item?id=34376163 and am reminded how that general tone will keep women away from our industry rather than attract them.
> that general tone will keep women away from our industry rather than attract them.
I don't "tones" have anything to do with it; in the 80s, Law, Accounting and Medicine[1] was absolutely dominated by men. If you think that introverted nerds are sexist, they have nothing on how doctors, lawyers and accountants were, nor how sexist the purchasers of those services were (often assuming that the men would be more competent).
And yet, today those professions have as many (if not more) females than males.
It's a stretch to think that general tone of an industry was responsible for females leaving the profession filled with introverted IT nerds and moving to high-powered and high-status executive professions.
[1] Other than nurses, in which men are still only a rounding error.
A long time ago this industry was built on women, the first programmers were women. It was a female dominated field. So what happened? The women stopped giving a fuck and the men took over.
The industry has plenty of attractive qualities for any sex: Good money, good jobs. These far outweigh the occasional toxic male who is easily put down these days. If women aren’t signing up, then maybe they just don’t care about computers as badly as people want them to.
Is that not part of why this industry has a problem?
In isolation, it is innocuous, and has the caveat emptor. Though, if you get slapped with, you can't be a great philosopher (for what are happily or unhappily married women other than just spouses), you can't be police, fire fighter, coder, CEO.. it's just another slap in a series if many that occur daily. So, the idea is stop with the isolated examples, and perhaps the bombardment will lessen
Leaning into society's stereotypes is one way to bend to people's implicit demands to change your writing (and quite possibly thinking).
But sure, if the metric you're optimizing is raw views and smiles and laughs, then probably the way to go is leaning into stereotypes. There's a reason those views and smiles and laughs are called "cheap".
If we are counting only heterosexual and 2 people marriages, wouldn't the number of people stuck in unhappy marriages be exactly 50% men and 50% women?
The [perceived] consequences of ending a marriage seem to provide more of a disincentive to men, so they are more likely to persist in a marriage that they feel they would be unable to leave (and then have to support multiple households, etc.). The fact that women (in the USA) are more than twice as likely to initiate a divorce seems to bear this out.
"Women divorce men more often than the other way around; this seems to bear out that men are more dissatisfied in marriage" seems like a stretch to me.
At any rate, it reminds me of the classic physics joke:
> An experimental physicist comes running excitedly to a theorist's office, waving a graph taken off his latest experiment. "Hmmm", says the theorist, "that's exactly where you'd expect to see that peak. Here is the reason." A long logical explanation follows. In the middle of it, the experimentalist says "Wait a minute", studies the chart for a second and says "Oops, this is upside down." He fixes it. "Hmmm," says the theorist, "you'd expect to see a dip in exactly that position. Here is the reason..."
That's an interesting thesis, but it wasn't one that I was putting forward; rather I was saying that the reality of divorce for men tends to be such that they are significantly less likely to seek divorce when their marriage is unhappy compared to women at a similar level of unhappiness.
I see there are many people commenting on the ethical value of that saying.
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.
There’s a lot of things like this that I blame mostly on the growth of what we’re doing here. We’re communicating in a low fidelity text only fashion and doing it without any knowledge of who each other are and how our word choices will be received. We definitely don’t know who is lurking or reading or may take offense once I hit the reply button on this form.
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.
There has to be some sort of “Streisand Effect” phenomenon that can be applied to interpersonal communications, where by mentioning a thing in conversation that you hope not to entertain, it gets entertained as a consequence of it being mentioned.
> 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”.
To me it's misogynistic because when I heard it first it's implied that my happiness is tied to a woman. Since I'm happily married and very much in love I know that without her I'd probably end up being a philosopher pondering problems without answers to run away from the trauma of losing her. I've been through it before :)
For sake of mental gymnastics I'll humor you. It's misogynistic because it's rooted in I presume in my culture that women generally don't sit and ponder problems, or resort to alcohol, drugs and crime as bad as men when things go bad. Women generally move on. So that belies a certain belief that women are the cause of all problems - And that is misogynistic.
The statement does not imply those assumptions, and even if it did, it would not be misogyny. The fact there is so much discussion about this is the 'issue' here and it's toxic.
> To me it's misogynistic because when I heard it first it's implied that my happiness is tied to a woman.
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.
I think there is a strong punishment system for the non-labelers. People that feel strongly about this stuff are really rabid, and seem to spend all their time calling people out on perceived slights.
There are plenty of layers at which it's misogynistic, but the most obvious one perhaps is that it wholly centers around the man in the relationship. Why must the wife be the source of the husband's unhappiness ("nagging wife" trope)? Why does he get to be the great philosopher if they're both unhappy?
You can say "it's just a saying, it would be equally true with the roles reversed" -- but then, why aren't they?
Sure, on the misogyny scale, it's pretty mild, but sayings like this that implicitly reinforce the male-centered world we live in are in some ways the most insidious.
The standard you've laid out proposes that any statement about a man's experience in a relationship is by definition misogynistic, because it's centers the man (and, of course, erases women). Do you stand by that?
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.
The difference is the original statement was not about a specific man's experience; it was a generalization about married men's experiences as a whole.
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.
In an unhappy marriage the other person is normally the source of unhappiness. Not always of course (I knew a guy who got divorced because he felt he'd missed out on having more relationships).
Sure, if you only look at the minutae. At a high level, a relationship is a bond between two people, so it's unfair to lay all the blame solely at the feet of the other person. You've probably done things that make your partner unhappy as well.
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.
> agile has killed the happiness...meetings...rituals...meta-work...not actual productivity.
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.
Can't upvote this enough times. Time and time again you see this: people say "I hate agile because of X, Y and Z" where X, Y, and Z - at best - are orthogonal to the idea of Agile, and at worst (and perhaps even "ordinarily") are complete anathema to the spirit of Agile.
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.
> 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.
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).
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.
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.
Yes, the business leadership almost always put an impossible waterfall approach ontop - they don't adapt to change at all well and are not really leading.
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.
/u/lr4444lr and /u/ajmurmann nailed it. "Agile" is just what the Agile Manifesto says. Strictly speaking, "Agile" in and of itself isn't even a methodology - it's just a set of principles, to which a number of concrete methodologies claim some association. They differ in the degree to which they faithfully represent the spirit of the manifesto.
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.
Difference between doing Agile and being agile is the same as education.
You can have engineers who are educated well and you can have engineers who get stuff done, well without a high level of ‘education’.
If you have an engineer the whole point of them being able to claim the title is they are educated and expert in their field. Without knowledge and expertise in a field you aren't going to get any engineering done.
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.
You’re talking about training, not education. A masters in engineering will be an experience in software architecture. An engineering role under one of these management styles will be an experience in training.
It's a methodology that makes software more resilient to the changing needs of the business. Anything that violates the 12 canonical principles[0] should be thrown out - and this has to be determined by each org. individually.
> 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.
You speak with a client. They say what they want. You build it they test it, and state objections and or request more features. You discuss and then build the agreed thing. And then you do this loop untill you ship
The whole idea is that there is no strictly formal version of the process. It can't be answered with a package. The process itself is agile, ammendable, fluid, mutable, improvable. You do what works for you.
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.
Some companies will just request a ready-made agile process from a certified agile overlord. The process will hinder productivity since only reporting parts and rituals are implemented, and all improvements suggested by individuals participating are dismissed since they are “against the agile process”.
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.
Agile is to Lenin as Agile processes are to Stalin.
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.
Agile is made up. The vast majority of places “do it wrong”. Coaches come in and make things even worse, with even less understanding. Saying “they are doing it wrong” and having nothing change isn’t doing anything, and it’s not really a great point. (Not specifically calling you out I just hear this all the time)
“Fauxagile” *is* agile, because thats what the majority of places in reality do.
Rebranding wouldn't help. The same people doing Fauxagile will be doing FauxX after. The underlying issues of why Fauxagile exists don't get removed because of rebranding
Agile just means making it up as you go when you have people who don't have the knowledge or experience to define first exactly what is required. If more programmers became managers and could work with the stakeholders, most specifically the clients that are ultimately paying their salaries then there would be fewer problems with waterfall. My experience is that if programmers would read the design document written by people who are knowledgeable instead of wanting to build it on the fly there would be no need for agile (assuming experienced people are writing the design documents. After ~1998-2000 it seems like marketing and sales were the ones that ended up doing that despite having no education or experience in designing software interfaces let alone programming). But that's just my experience, and I learned early on the first thing you do is read the manual and if it doesn't answer all the questions then ask and re-write the manual yourself before doing any budgeting or coding. Instead we got agile, which turned into make it up as you go through constant sprints/iterations and meetings as you design and build it rather than on paper. As comic Dave Smith said, if you say it works on paper but doesn't in practice then it doesn't work on paper either.
Usually you know the least at the start so your plans at that point are rubbish.
So you keep refining your plans .....
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".
Productive teams understand that any "way of working" is just a means to an end, and that good teams find a way to work that suits them (and their situation).
"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”.
Note that the AM doesn't say not to create documentation, or use processes and tools, etc. It just says to favor the alternatives with the implication that you have to exercise some judgment and discretion on deciding what to do when. The AM in and of itself isn't a methodology and it isn't terribly prescriptive. It's a high level description of a general notion of how to approach things, which can be (and should be) tailored to your circumstances.
> "Working software over comprehensive documentation"
> 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.
> "Customer collaboration over contract negotiation"
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.
> Working software over comprehensive documentation
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."
Keep in mind the agile manifesto authors were consultants, working as consultants, and the manifesto is largely in the context of software consultancy.
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.
> "Customer collaboration over contract negotiation"
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"
A good friend of mine worked for HP Consulting, which at the time was using heavyweight waterfall method. Out of curiosity, I asked her how well they hit their schedules and costs.
"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.
> 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.
...
> 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?
This is a great piece. My software engineering training just held the assumption that the world runs on agile processes by now. Waterfall-like processes were a historical reference and a failure.
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.
It's why contracted-for software is so awful - contractors do absolutely anything to meet the conditions and then they're gone and not responsible anymore.
> It's why contracted-for software is so awful - contractors do absolutely anything to meet the conditions and then they're gone and not responsible anymore.
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].
> 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.
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.
It's like you reached inside my head, pulled out my crudely formulated thoughts and feelings on why it struck me as ill-advised, and refined and explained everything perfectly.
Internal teams! My work these days is directly with people paying for the thing. That's why Agile gives me the shivers.
It's unfortunate that you haven't understood any of the problems of writing software or buying on contract despite having it laid out for you.
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.
> It's unfortunate that you haven't understood any of the problems of writing software or buying on contract despite having it laid out for you.
> 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).
> 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.
> Tends to make very frustrating-to-use software, because it's never fully working and has minimal documentation.
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.
Well, you probably like paid time off (as American companies like to call it) and that's a socialist thing. Potentially you might enjoy free healthcare if you could get it - at least you get free policing and defense.
Which country implements pure capitalism? What would that even look like? 0 tax? having to pay private police companies? ....
It has been tried, though, and it works fine in e.g. Chiapas. Granted, that's not an industrialized and mostly urban society, but not everything has to be one.
Socialism has a somewhat agreed upon base set of principles and comes in a thousand different flavors, but at the end of the day every large scale attempt has ended up with an authoritarian state and either failed or converted to Capitalism. So whenever you say Socialism is a failure, you end up hearing "Well THAT wasn't really Socialism!" Same with Agile.
> Yes. I would phrase it as: if agile is actually done.
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 like Agile, but I hate “Agile” (that is, how Agile is interpreted and implemented by the management of the companies I’ve worked at).
I worked at Allstate years ago, and was on the team that piloted Agile (Scrum). It was done by the book, and I thought it was awesome. We had a quick scrum meeting each day, and the retros and plannings were only on Wednesdays. Sprints ended on Wednesdays.
Most companies have their sprints start or end on Monday or Friday, but those are COMMON days for people to take PTO, nevermind national holidays are usually on those days.
That was the first company i worked at which was Agile, and I haven’t been to a company since that did it as effectively. Ironic that it was Allstate. Just about everything else about the company absolutely sucked.
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.
Indeed. Most of the commentary I've seen from people who were around is that scrum isn't agile but just an impotent compromise made by people who thought business could never actually handle an actually agile (as in flexible) work methodology. I think they're mostly right; Scrum really isn't very flexible.
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.
> I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity
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.
At higher management levels people are trying to "achieve" some goals and of course "agile" means that you are constantly evaluating what to achieve and discarding some of it while perhaps adding new things. There's less agility higher up because I think it takes too long for any of those goals to be proven stupid (or proven smart) so it's waterfall ontop and agile underneath and that's obviously a clash.
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.
It's a fair point. The whole DevOps thing is so ludicrous. I've seen companies that don't just have a "DevOps team" (which is absurd in and of itself) but multiple DevOps Teams, and I'm pretty sure there are some DevOps Teams that have embedded DevOps Teams that in turn have more embedded DevOps Teams.
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."
It's actually quite funny because "agile" basically means (in English) "quick to react", which should imply not much process at all (and when properly implemented, usually is).
> I really feel agile has killed the happiness of our industry
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 enjoyed it working well. It was much better than being project managed. A great deal of the time it let us toss out stupid requirements - they just sat at the bottom of the infinite backlog because they weren't needed yet.
Would the opposite of what you describe here be : program all the time and ship things as fast as possible?
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
Feel like I would’ve said something like this at the beginning of my career.. you’re gonna go thru it, you’ll see. None of what you’re saying makes a lick of sense.
My point was that the saying itself is wrong and a bad meme (the ethics of it were secondary to my argument) and I linked to where it originated to show that it wasn't even a thing in the first place.
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.
>I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity (If agile is done well though it can be amazing but that's another topic to me)
All that stuff you hate isnt unique to software. It's just capitalism.
Before I was in this industry most other things aren't ritualistic in their delivery. In retail, in healthcare, in hospitality, in television - it was very much quality/event driven. A thing was done it can't continuously improved upon. Software (at least relative to me) is like working on a dish as a chef that is never complete. A patient that never is healed etc. It's because so much about ritualistic definition of the task over and over. In mission critical scenarios I do feel waterfall is better. Agile is something where a small team can actually make something over time, lots of time but it's become a thing where meetings (and their number) are measured as part of the success of a project. Not the actual delivery.
If anything, the modern management structure more closely resembles a mini-communist state than a capitalist system.
Each department's revenue goes into a shared pool, which is distributed amongst the company in annual planning cycles by an unelected board of representatives. Who gets what is as much a function of meritocratic principles like department revenue as it is of who happens to have senior leadership's ear that year (how many times have executives been convinced X is the future, we need more X, with no concrete performance to back that up?).
There are some larger, more sophisticated companies that break this mold, but more the exception than the rule, I think.
All that stuff is actually _even worse_ under alternative economic systems. Spend a few hours talking with someone -- anyone -- who comes from a Communist country and ask them about this.
The poster most likely thinks that communism/socialism are utopia producing methodologies that have never been tried for real and all evils are because capitalism.
ITT: we observe the sheer amount of ignorance & naivety that rears its ugly head when stemlords attempt to discuss any sort of social issue / concept. It's crazy how one would interpret you pointing out the slight misogynistic undertones of the phrase you quoted as "making things political". I'm not going to mention any popular figure by name as that would be quite inflammatory, but it's not wonder certain individuals can disguise terrible opinions as the "facts & logic" based take & especially dupe men who are in a stem field. Really reinforces the stereotype of male engineers/scientists who think their field's knowledge somehow universally applies to the less "technical" sciences such as social sciences.
> I can almost guarantee that you’re just at the wrong company.
Even if this is true (which it most likely is), there's no guarantee the company you move to (in your quest of finding "the right company") won't either a) also be the wrong company again right off the bat or b) become the wrong company again.
I've kind of just given up. I've accepted I'm basically a "technical plumber". Take data from this system/vendor in this format, convert it to another, make low six figures, have benefits, try to focus on life outside of work.
I'm in the same boat, and I just want to say: we should try to be grateful. For the vast majority of people, what matters in life is what is outside of work, and maybe it's because I grew up in an impoverished rural area but earning low six figures to do a fairly simple job for a few decades and not breaking our bodies doing a physical trade, working remotely..
I think about my ancestors a lot, toiling in fields and fighting in horrific wars
> in your quest of finding "the right company"...basically just a technical plumber
I've come to a sort of depressing realization, 30 years into this career: the kind of companies that _will hire me_ are usually not the "right" company. I'm not even a plucky bootcamp self-motivator, I'm a state-school CS grad who's never worked for Google, Facebook or Amazon. The hiring processes that don't filter me out are the sorts of employment processes that demand hour-by-hour status updates in the form of up-front-estimate timesheets and 24/7 on-call. Oh, well, I might actually make enough money to retire some day.
I have the same issue. I hate leetcode, am a good communicator and want to always connect what I build to the value it delivers to customers. But the companies that care about this the most are startups, and I've had some really bad experiences.
Yeah, the older I get, the more I'm able to see how companies could be so much better, so much more effective. But that's not something executives really want most of the time. So I think what will eventually drive me to retire is not getting tired of making things, but an inability to put up with the gap between what's possible and what's actually going on.
Yeah, that's been a hard lesson for me to learn. When the nominal purpose differs greatly from the POSIWID purpose, I find it very frustrating. Very human, of course, and if that were all it was I could work with it. But at least in American business culture we musn't talk about POSIWID purposes. It'd be so much easier for me if we could just say, "Ok, grandboss, we recognize the most important thing for you here is you looking amazing to your boss so you can climb the ladder. But we'd all like to also get some work done for our users, so how can we make everybody happy?"
Three years ago I was stuck at a huge fortune 100 with all the ceremonies, business language, and paycheck collectors. I started to shop around. I found an amazing place, a company that was a software company not not a company that happened to write some software.
The interviews went amazing, everything was Star Trek utopian future amazing, it was like the fantasy I had about where I wanted to work had manifested. I got a job offer, and took it immediately.
The first day of work, no one on my team was there to let me in, so I hung out in the lobby for several hours waiting for anyone brave enough to get me to the badge people so I could open the door on my own. By five months in, I'd not had a manager check in yet, no one on the team would talk to me, and I realized I was a professional bench warmer. I'd been bamboozled, body-snatched from my boring, process-jammed, low-progress IT job.
Fortunately the fortune 100 took me back. I hadn't burned any bridges on my way out, and my seat was still warm. My cube was still there, my gear all waiting for me to just log right back in 6 months later like I was simply on a long break.
Three years later I'm still here. I'm terrified to go looking again cause I can't have my heart broken twice so soon. I have no idea how to interview well enough to detect a trap. I think my age has a lot to do with it (I'm in my mid 40s and I average about 7 years per company so I don't experiment a lot with this).
I think that your strategy is the same as mine and that you should be rewarded for sticking with it, because there's success in it even if you're not constantly being entertained by solving the big interesting problems. Running a little personal infrastructure to learn the next big platform/language/thing is always a great hobby for people who can do a little more work outside of work, and just having interests that don't earn you anything at all are the most rewarding for finding brief moments of happiness.
Ageism does occur in this industry, but I've mostly heard it around associating various levels with age or years of experience. For instance, at a financial product company I worked for I saw a man who went on to become a Googler get cut from our interview because he "had too much experience to be a senior". For context, most of his background had been in contracting and he'd only recently really invested himself in DS&A knowledge (the kind larger firms look for). The kind of companies he had worked for put his skills cumulatively around Senior but he'd been in the industry a long time.
There's "innocent sounding" explanation for the managers decision to cut the interview, but they're all tainted with some form of ageism.
> so I hung out in the lobby for several hours waiting for anyone brave enough to get me to the badge people
Did you consider asking someone going in or out to help you get a badge or to put you into contact with the right person?
Sounds like you passively waited for someone to come and help you, which might be fine for a short while, but eventually it's better to take action.
I've never heard of a "professional bench warmer" in software development. It's not as if devs get injured regularly and need replacements. Why do you think they'd hire you just to not give you anything to do?
It happens for all sorts of reasons. Often managers are seen as important not because of what they produce, but how big their teams and budgets are. In that circumstance, hiring people is important, but getting anything useful out of them is secondary.
Or it could be pure chaos. Years ago I joined a startup that was scaling rapidly. The interview process was exciting, the people seemed great, and the compensation was very appealing. So I go in on my first day, eager to get to work. After sitting in the lobby a while, I'm told that they aren't ready for me, and could I come back?
The next day I come in, and they again say they aren't ready, they're very very sorry, and that I should come back tomorrow. So I do.
The third day I figure, great, now I'm going to get to work. But once again, nobody's ready for me. No desk, no computer, no nothing. They weakly suggest that maybe I could find a corner somewhere and read manuals?
I politely tell them that I think this isn't a match, GTFO, and never come back. They go out of business a few years later.
>> I've never heard of a "professional bench warmer" in software development.
I think this is real.
My friend who is serial Project Manager (he works for big corps here in Poland and changes job almost every year for last 15 years) actually uses the term "on bench" for programers that do not have projects assigned to them and he claims that he quite often hires people before project is confirmed, so from time to time some people are left hanging without free chairs when music stops.
I can confirm that - "on bench" was a real term used in a software house I worked for in Poland. I think it becomes a necessity when your company doesn't have a product on its own but delivers projects for other companies. Depending on the needs of your clients, the projects may be short 3 months stints or longer years long cooperations. In an environment like that firstly you want to be able to start working as soon as the contract is signed, so you must have some staff available all the time, and secondly you don't want to wreck the morale by letting your staffing level fluctuate with the workload. Hence some people are "on bench", waiting for a project to come, doing internal work or upskilling. This company was the best one from the ones I worked for in my career BTW
Being in the bench is not unusual for Consultancy companies, where there is no necessarily alignment between finishing with a client and starting with the next one. Or even starting directly on a client when you join them.
Many big government consulting companies will have a constant pool of employees that have nothing to work on for a few reasons: they have a job but are waiting on a clearance to start work, they were hired for/working on something that didn't pan out so they are waiting for a new job, or they've got a job but the project hasn't been given a green light to start working it yet. These workers may be able to find some low level work to keep busy or they have some training budget that can be spent on bootcamps but sometimes there is just nothing for them to do other than just spend all day looking at the internal job board and canvassing program managers for work. The last situation is the worst to be in, you only get to bill overhead for so long until you get laid off. The good part is at least you're getting paid while applying to other companies in the evenings. Unless you know there's a position waiting for you, its best to spend as much training money as you can and find a new company before the lay off comes.
My company likes to do the complete opposite. There is always endless work to do because we only hire if there's an immediate need for someone. The upside is that you're always going to be busy and lay offs are very rare. The downside is that we are perpetually understaffed.
I'm sorry you've been burned and it's not easier for you to take these risks.
I average about 2 years, and each company has been progressively better than the last.
Don't let a bad job hop stop you. To me it's the only way to really progress your career.
I've done a huge variety of projects, experienced a ton of different management styles, and of course also never stagnated compensation wise.
Leetcode kind of sucks, but it's possible to build up enough confidence to ace it.
Particularly start by focusing on one area until you see all the basic patterns. For me, I was rather weak with trees.
Job hoping seems to be the only reliable way to increase your comp. I was promoted at Intel and got 11% as a raise. Then I bounced and gained another 40%.
From there I doubled entirely. Please do consider your value, plus selfishly you'll help keep the software engineering market competitive if you do.
I'm still kinda confused - did you have no work to do at all? Or you just were expecting some collaborative team work that's not there? I agree lack of communication seems extreme, but if you are working that's not exactly bench warming.
Google in Sunnyvale was like this. We had lunch together but the office was eerily quiet. People would catch themselves talking, apologize, then go to a meeting room if they wanted to continue. Low key hated it and I'm not a social person and prefer quiet while working.
Seriously, if I could do all of my work without people trying to talk my ear off all day and let me keep my work life and social life truly separate, that sounds ideal to me.
"Oh the tech was textbook perfect but I didn't like that nobody wanted to stand around and bullshit all day"
This happened frequently in the dot-com era. There was tons of over hiring to inflate the budget and get more VC money. I remember one company I worked for raised $8 million (a pretty good size A round for late 90's), then immediately dumping $1 million into office renovations for a second location down the street.
That office needed to be full. We'd hire guys who could barely spell HTML. The next round was $20 million or so. More hiring. It was like monkeys banging on keyboards. There were no code reviews, no process, nothing like that. We hired some of the most clueless management you could possibly imagine.
The product itself was half baked and ill-conceived. But we just kept on hiring. Eventually 2001 came and there were mass layoffs. I was not among them, but I left on my own about a year later. Eventually there was a fire sale and everything was sold for pennies on the dollar.
Not enough process can be a pain too. "Just do this for us" without specific requirements, and then the thing you've built is never good enough and needs to be continually refined anyway or it's never used. Those environments are also soul crushing, just in a different way from the ones with too much process.
I consider “Getting the requirements to be versioned on Confluence instead of with a large sequence of excel files” to be one of my big achievements. And I hate Confluence with a passion.
Agreed, this sounds like OP is in the wrong job. To me, there are two types of companies as an engineer. There are companies that like engineers to focus solely on product. This is the kind of company you'll hear "don't reinvent the wheel" a lot at because their understanding of their core skills probably doesn't branch that deep into engineering. Then there's companies where engineering is core to the product. Some folks hate these kinds of companies, but I tend to enjoy them because even the niche networking stack is related to product delivery somehow.
Product-focused companies also, in my experience, tend to put a lot more emphasis on ritual precision. Agile isn't just a means of organizing, it becomes the way you get things done. These companies also tend to have some culty vibes to them, but again, could just be my experience. At engineering focused companies I've "done Agile" but the emphasis was mainly on giving me tools, systems, and incentives to self-organize more than the rituals themselves. These kind of companies are actually where I learned to love testing a lot more than I used to, but that was because someone took the time to shape how I wrote code so that it was easy to test.
eg I like having tests, and I like writing them, because they make my life better. But the contrast between the effort level to write tests in ruby or python vs go... I hate go, I hate the lack of good mock support, and I dislike writing tests at work because I hate go.
I agree and I would suggest trying small companies or very early stage startups (with less than 10 Software developers). You get to program a lo, but not all goods though. A lot of context change and you have to also think about product and design, so it’s not just programming. Also the risk of the company not existing in a year. But, for me, it’s perfect.
This 1000x. For a larger project, I asked and got approval for a POC. When I submitted the POC with feature flag for review, I was told by the same management that it wasn't "production worthy". Never burned out faster in my 20+ year career.
I dunno, I think OP may be right. I was in the same boat: I thought I hated programming, then one day I realized I just hated the industry wrapper around it. I recognize some of that process stuff can be valuable, but it's hard to disentangle the good stuff from the trash. Much of it is cargo cult, article-driven thinking that does nobody any good. A few years ago I switched to design, and now I just program in my spare time for fun. And it is fun when you do it right.
What are these unicorn companies? I've worked at 7 companies (and interviewed at many more) and never seen anything close to this mythical "company that values programming and real productivity". I feel like they must be exceptionally rare.
The term unicorn in this context makes it hard to understand what you're asking, as unicorn companies are usually defined to be corporations with i believe a billion in revenue. This often comes with the usual downsides.
Smallish companies often leave a lot more freedom for their developers, but you'll most likely also be missing a lot of things you've gotten used to (highly automated CI/CD, teams "responsible" for each part of the system etc)
They're referring to the mythical animal, using a metaphor to express that such a company is mythical or non-existent. Coincidentally, this is same metaphor that the person who coined the term "unicorn company" was using.
Given that private companies with over $1B in revenue actually exist while examples of "[companies] that values programming and real productivity" are yet to be forthcoming, the parent post is using the metaphor correctly and the finance world is not.
I’ve worked at about 10 companies and half of them didn’t have the soul sucking processes (though all of them did have process).
The correlation I see is big companies have processes that kill productivity, though I did work for a big company that was able to avoid it for a long time (new leadership did end up killing productivity right before I left).
And for what it’s worth there was no correlation with “agile”. I’ve seen good and bad agile.
I forget what job it was I was interviewing for but I remember being stunned at the open lack of process they had in place for trying to bother unifying all these teams to be on the same platform framework etc and instead deliberately let sub teams work with tooling that worked for them and didn't create a lot of overhead trying to coordinate and sync and share a common codebase. Every place prior to that day I had only heard of people going for long stretches to impose a company wide uniformity in tooling. All the costs associated with getting everyone on the same page was always taken as a worthy cost to pay and that future date in the promise land would have made it all worth it.
The folks in this other company just flat out said not worth it, just get your stuff done, ideal development scenarios and perfect harmony and alignment have too much hidden costs to bother with.
It's naturally a pro and con scenario but it was pretty refreshing to hear of folks so unconstrained by this self imposed constraint every other shop had imposed on themselves.
I have seen two extremes of this. The one side is forced conformity, and the other side was complete chaos. To the point where each project was written in its own language. Imagine changing teams to help on a project and step 1 is to learn a new language and deploy methods.
I feel like there is a golden middle where the team has decided on maybe 3 languages, one typed, one scripted, one cutting edge. And a few different deploy scenarios, and you can pick amongst them.
I work at a company that's trying to come out of the other side of this kind of approach. Let me tell you, it might feel good while you're doing it but in 5 years time it will be a hot mess of unmaintainable garbage! There are hidden costs in trying to align as you go, but there are potentially company ending costs in not.
You're right that there is no promised land, but the quest to reach it prevents you regressing into hell.
> I can almost guarantee that you’re just at the wrong company.
The trick is finding a company that's not wrong.
Early-stage startups typically qualify, but they're also typically short-lived; they usually either go under or else grow into the same sort of "wrong company" one's trying to avoid.
A small business that's been around awhile, with a stable customer base and no ambitions for growth, is probably ideal - but good luck getting such a company to hire you. You might have better luck picking up multiple such companies as an independent consultant.
A different ideal (or so I've found) would be a company that's large but dysfunctional, or to be an "analyst" or somesuch in a department that's sufficiently large and autonomous to get away with having "shadow IT" (and a lax enough corporate IT department to not interfere).
> 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.
god - this is so true at my last company. Any attempts to decrease meetings, remove unnecessary process are met with heavy resistance. Getting shit done was nearly impossible. People had no responsibility for their work. Only wanted "stories" and "subtasks" assigned to them. Doesn't matter if the story was trash/useless/no-op, they just wanted it to pump their numbers because the quarter is ending. I shouldn't have tried so hard to make changes. They probably ended up getting reverted by the next person or manager.
Pro tip: if the company you joined tends to hire new people then retain them. Then fucking run. During the first "all hands" in that company, nearly 80% of people that worked in the organization were hired in the past 1 year or so. It ticked "red flags" at the time but I ignored it because honestly I needed the money at the time (just graduated college)
I'm confused. Aren't all companies that got a round of funding ~1 yr ago going to have a large cohort of <1 yr tenure employees? What connects this to death-by-process?
High churn company. Grind them out, throw them away when they’re not performing anymore, and replace them with a new batch of fresh meat to wear down. Standard playbook for an alarming number of (VC funded) companies.
I am here to say that both "too much" and "too little" process are shitty. I have been at companies with too much process (medical devices) and companies with WAY to little process, and both places are an absolute nightmare. What you want is a process that ensures features are spec'ed out properly, testing is performed, deployment is smooth, and etc., with a lot less or zero of the "put your hours into the Jira ticket" type bullshit.
Tastes differ, as do circumstances, but the last place I want to work is one where things are spec'd out "properly". For me one of the great sources of joy in making software is jointly discovering needs by exploring the problem space. I've done whole companies with nothing more than index cards, napkin-quality sketches, and very close team relationships. I love it.
I'm talking about product design, not technical design. But I don't think specifications help in the long term there, either. I think the way you get designs that are understood by both old-timers and newcomers is continuous improvement of the code through refactoring and cleanup.
> I can almost guarantee that you’re just at the wrong company.
You're at the wrong company if you're unhappy regardless of the size.
I've worked at a very small company which was miserable because the owner didn't have a clue and was only interested in the bottom line to the point of letting the software and the systems atrophy.
I've worked at Megabank, and it was also miserable. Actually writing code probably ended up being a sum total of 3-4 hours a week. At best. Too many meetings. Absurd change control system. Crazy processes and sign off.
And then there have been a few mid-sized companies - 20-200, and they've been the most fun. Get on with coding and even whilst managing a small team.
These processes exist for a reason, even if nobody knows what it is. Over time companies that did these things survived, maybe nowadays it is vestigial, but the burden of proof is on new successful companies that don't have these practices.
I think it's more marketing and profiteering based on correlation over causation.
Almost every process these days is bought in by a new managerial hire, or after attending an event, where a talk or book that shows X companies that are very successful all followed the Y practice, and so 'we should too' as it's obviously the path to success. Rarely is there reflection on whether the process is working, and blame is laid at the feet of the workers.
Despite many recollections and experiences retold about how processes may not work, they are silenced by the advocates of such processes who will show how successful they were (and also just happen to make their living by advocating rather than actually being on the ground).
It might even be very different in the same company. I changed teams in my large company and the number of recurring meetings around process dropped from 8 to 0, no more daily, no sprint planning etc - we just talk about the feature then do it and we don’t need a lot of process since communication works well anyway.
Seconded. And might I suggest a smaller company. Smaller companies (like startups) are about about solving the problems at hand quickly. As companies grow there is a larger risk that any one mistake can lose the company money, which will generally continue to flow if they do nothing, and so they intentionally put in a lot of road blocks.
sometimes its not the wrong company but just the wrong team or even individual coworkers (I guess if you're in a company that has multiple teams).
We had a new hire join a few years ago and every time they had a work task that they hadn't done before they'd make multiple meetings about their particular part of it, asking for advice in meetings instead of informal conversation, asking others to fill in documentation etc that might have been reasonable once or twice but essentially created a work by committee approach...to their work. It was exhausting and I let my manager know I was going to start declining their meetings semi regularly.
When people started declining the volume of such requests and tasks suddenly dropped.
But depending on how intractable your team or org, is, finding a new job may be easier.
I dislike working just as a "software engineer" in a team where my part in decision making on the product progression isn't very significant. I like programming and tinkering with everything in the computer science domain because it's so very thrilling and rewarding.
I love meeting with the right people, documenting my work, and working with legacy code. Especially meetings, nothing more invigorating than building something with a team.
That said, as some have already mentioned, all of this is typically ruined somehow at nearly every company.
"wrong companies" is it. Perhaps it is love software engineering AND coding but hate big software companies?
Also with "some software companies can turn even the simplest..." You may have forgotten to add "and add metrics to these rituals as performance goals"!
A company that values programming over its business won't stay around long (see the recent front page submission called something like "your stack is not your product"). Sales is what covers payroll.
However a company that values programming over managing will prosper more than a company that values managing more than programming. Just enough management that everybody knows they're working on the right thing is best for all (including the managers).
Process for its own sake (I'm looking particularly at cargo-culting "agile" astronauts) sucks the life out of everybody involved.
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.