You can't change the past, but you can recalibrate your expectations and medidate on what went wrong. Here are some thoughts, and I will be very harsh:
1. Your co-workers may be amazing, but they were never your friends. You ran a business and rented their years to help them build a nest egg, of which you would claim the majority share had it hatched. Alas, the business failed and thus, you no longer add value to each other's lives. Move on.
2. There's what you love, and there's what you do. It's best to keep some distance: because no one cares about what you love. VCs are vultures and this is well known, but they are also reflecting the reality of the market. In the market you're just a vendor. Think about all the food stands that you have walked past in your life, within each stand is an immigrant family who slave away for decades hoping for a better life. Have you ever thought about them and gave them time/money for their suffering? No, you only cared them inso far as they can cook for you. This is how others saw you.
3. Big companies, and indeed most big institutions is made by a silent majority of the defeated. Many have experienced what you have said and have long made their peace. They found joy elsewhere, and found distance between themselves and their work.
4. Find self worth and self-love outside of your role in the machine, there's the product you produce to trade time for money, and then there's you. They are different things. Imagine Instagram influencers who post pictures of themselves but feel depressed when they don't get enough likes. This is you right now, you're looking for external validation from how big your integer is in some database. You have to look elsewhere.
My point is that human psychology did not evolve in the context of our current world and will have enormous difficulty dealing with its bad sides. Although the specifics will vary, the number of people in the poster's position is undoubtedly enormous, with the vast majority too tired or ashamed of discussing it or just blaming themselves. This being the case, it would be nice to have serious study of it and resources to address it more effectively. Not to criticize any poster, but it is unfortunate than seeking advice from the web is currently the best one can do.
1) The reality is you need to find validation and fulfilment outside of work, because in our current society you are just a drone.
2) Don't be depressed because it seems like this is how it's always been. It hasn't. Our work culture is broken. People never used to be so far removed from their work. Trying to combine work and life is a natural thing, because people used to be tied up in it. Working the land, being close to home, running a family business, belonging to a small town of people you all known, having the social safety net of many people that are close to you and your family, being an independent contributor in the town's economy, etc. etc. This is how things were a few hundred years ago. Yes, there was less high tech gadgetry. There were corrupt officials, plagues, bad people. There will always be some element of this.
I really get the sense that so much of the first world's unhappiness right now is due to compartmentalising (the containerising if you like) of our lives. The solution to burnout at work is to create greater separation between work and home. But the problem itself is that we even need to do this. People can't live to enjoy what they do any more. You need to trade the majority of your waking hours for money you need to live. And when you do live, you're dreading returning to work and feeling burnout anyway. How depressing.
This is why the working-from-home trend that I hope COVID will kick-off is going to be a good thing. While we may still be working for the same companies, having a tighter integration between work and home is actually good for our mental health. Issues will be resolved faster. Nobody wants to be constantly angry in their own home. So if you're angry all the time while WFH, maybe you'll be more likely to look elsewhere. Taking breaks from work while at home is so much more refreshing. I can't think of anything more depressing that spending my lunch break in a work cafe with people I don't want to talk to, being flooded with fluorescent light, and thinking about how the rest of my working life will be spent in places like this.
Let’s not overglamorize rural poverty. This life came with 20–40% infant mortality and a very high rate of maternal death in childbirth (play 5+ rounds of not-quite-russian-roulette and the odds get pretty grim). Starvation and disease were ubiquitous. Many people suffered some now-trivial injury and ended up as lifelong cripples. The work was literally backbreaking and elderly people’s (i.e. >50 years old) bodies were just wrecked after a career of hard manual labor, assuming they lived that long at all. People’s indoor time was spent in small dark rooms with an open hearth worse than the worst second-hand cigarette smoke you can possibly find, and unbelievably uncomfortable beds. In the best case food was mediocre (mostly bread or porridge or similar) and everyone was slightly malnourished, especially in the winter. People generally just shat outside near their houses and hoped the dogs would take care of it. If they wanted water (for drinking, bathing, ...) they’d have to carry it on their heads/backs from the nearest well or stream; water is very heavy.
People had to make literally everything in an extremely labor-intensive way from scratch: clothes, food, housing, furniture, toys, tools, etc. Raising sheep (or finding some other fiber) and then carding the wool, spinning the wool, weaving every piece of fabric on a hand loom, sewing fabric into clothes takes unbelievable amounts of human time. Making a small hut by hand takes weeks if not months of work (and the result is usually drafty, leaky, and not very comfortable). Making bread by hand including growing the grain and grinding it is nearly a full time job for everyone in the society.
If for whatever reason you were different from the expected norms (or just got unlucky and crossed the wrong gossipy neighbor) the rumors about you would mercilessly destroy your social life, and possibly result in exile or death if neighbors decided you were (e.g.) a witch.
The local nobles took every liberty with peasants: robbery, beatings as sport, rape, murder. The roads between towns were plagued with bandits.
There’s a reason that the world has now experienced several centuries of dramatic migration away from rural peasant farming and toward horribly exploitative urban factory labor.
It's kind of annoying how every time someone discusses aspects of society that may have regressed from the past, somebody chimes in to remind us that technology has advanced so life is better today. Well obviously, what's your point? Nobody's claiming we should get rid of 21st century technology and start living like medieval peasants.
But the previous commenter was explicitly talking about the supposed golden time of rural life a few centuries ago. In practice it was a hard and stressful life both physically and socially.
The summary of the downsides of peasant life was:
> Yes, there was less high tech gadgetry. There were corrupt officials, plagues, bad people. There will always be some element of this.
This is a dramatic understatement, to say the least.
> in our current society you are just a drone. [...] Don't be depressed because it seems like this is how it's always been. It hasn't.
Rural peasants have been treated much more like “just drones” for the past 8 (?) millennia since large-scale civilization built on agriculture than any modern office worker. (Hunter–gatherer societies are different in many ways, though also often precarious.)
Rural peasants do not lack for work anxiety. Or anxiety in their interpersonal relationships. In rural peasant societies many people feel alienated. Domestic abuse is rampant. And so on.
There are many beautiful and nostalgic things about historical rural life. But we shouldn’t get carried away.
No they weren't, like I said in my last comment, they were talking about the negative effects of the modern overcompartmentalization of work. It's not hard to see that there are certain benefits to working for oneself in one's own home vs. being a cog on an assembly line in some factory.
I imagine they were talking about farmers, not peasants. By the way the average medieval peasant had more time off than the average American worker since the work was seasonal. The takeaway there isn't "let's return to medieval technology and start living like medieval peasants again", it's "maybe there's something wrong with our society if despite the enormous technological advances from the past, certain elements of society like autonomy over one's time have regressed, controlling for technology".
Again, the original commenter was not arguing that we should all start living like the Amish. It's a failure of reading comprehension if that's how you interpreted it.
How is this rosy-eyed?
I think many people today use the idea that even though some things are miserable today it ok, because they've been miserable always. It's a sad, self-defeating coping mechanism, a lame justification for how things are.
It's possible for some things to have been better in the past, much like some other things may be better in the present. Progress like regress is unilateral.
are pretty much at the top of “things that really stress us when we don’t have them.
I mean, everything else is icing on the cake. Not too long ago, people didn’t know whether they would starve to death during the next winter, their wife would die from childbirth or some local bogeyman would just burn down your house and enslave your family.
People quickly forget many of the hardships their own great grandparents faced.
Source: my parents are anthropologists and I spent a substantial amount of time as a child in the 1990s visiting an indigenous peasant village, sleeping in a dirt-floored hut with a hearth fire nearby, with no electricity and water carried on people’s heads from half a mile away, high infant mortality, belief that diseases are caused by witches (vs. germs), etc.
Their illegalization and displacement by supermarkets has been at least partly a deliberate political choice, and I don’t think it’s an inevitable part of modern life.
(Working as a vendor in a market stall is not necessarily a great career though.)
There are farmers market around my area and my impression is that, if anything, people selling there can be more dishonest than the big chain stores - i.e. they will try selling a batch of bad apples, because they're not wealthy and they just need the money. Whereas big chains have quality standards and will just throw away bad food.
I mean, @Theorentis is correct, in a way, about what's good about less-industrialized societies. Though it was more true of medieval serfs and classical societies than it was of "a few hundred years ago". But also @jacobulus is correct about the down-sides.
And when you say "pre-WWII", that makes me think of 1850-1950, which I suggest is, overall, literally worst-of-both-worlds. There's virtually no decent medicine until 1928, but industrialization and capitalism are in full jackbooted swing. You get all the psycho-social disadvantages of modernity, with virtually none of the benefits.
The feudal system is often given a bad wrap, but after reading "The Servile State" (a critique of modern capitalism) I actually think we have much to learn from it that we have lost.
It persisted because there was not sufficient economic surplus or a sufficiently broad distribution of economic/social power to break the control of the armed thugs running things, except sometimes by other groups of armed thugs.
> The local nobles took every liberty with peasants: robbery, beatings as sport, rape, murder. The roads between towns were plagued with bandits.
You are cherry-picking examples that are in no way representative of the life of most humans.
Plenty of evidence shows otherwise.
Rural peasants were and are typically a foot shorter than people living in wealthy industrialized countries today (or people in hunter–gatherer tribes for that matter). Almost all of their calories come from staple starches, which they supplement as best they can. Periods of extreme hunger are common enough that most peasants experienced them at least a few times over a lifetime. What kind of good nutrition do you think people have/had?
Life expectancy was under 40 years old. Even life expectancy after age 5 was pretty short.
It was an incredible experience. Everyone was very passionate. The company grew in revenue 1000%.
Which lead to disagreements between the founders, which inevitably lead to the one guy pushing that culture to quit and it all went downhill from there.
I’m obviously massively oversimplifying here and there were more factors, but the feeling of belonging was very real. And I know it was not just me as we have ex-colleagues gatherings from time to time and the sentiment is shared.
I mean real cults short-circuit normal human tribal behavior for their own survival. And we usually consider it bad as the stuff the cult demands usually go against the society at large.
But in my case it was a rather productive and a moderately lucrative enterprise for all involved. Its just that instead of “oh honey your off to work see ya in 8hours” it was more “oh say hi to this and that for me” kinda thing. Just more human all around.
Anyway to answer your question - yeah we do stay in touch with some, not all of course.
Got a little essay on that:
I go to work for 1 reason: compensation. I expect to get paid, and get the benefits agreed upon when I agreed to work here. I will be friendly to those I work with, so that I don't hate to come in to work every day.
Does that mean they have the right to meet my SO or friends or things/people/hobbies outside of work? Absolutely not. If I choose to do so, that's on me.
Work != outside of work. That's a hard boundary.
Alternatively, it extends the reach of companies further into the home environment, and may exacerbate the existing trend for people not to switch off, which in turn makes it harder to achieve a good life-work balance. Imagine having a pressurised call-centre type role from home. Some people may feel greater pressure to appear 'corporate' in the home environment, others might not mind their kids or cats interrupting a Zoom meeting. Not everyone can create a suitable WFH environment in a nice spare room.
Whether this actually happens depends on corporate culture, the personalities and goals of the managers and employees, whether a crunch is on, and many other factors. But I'm not convinced that a tighter integration between work and home is necessarily always going to be a positive, from a mental health perspective.
I can only hope this "fake macho work persona" bubble-burst carries forward into post-covid.
I always wonder where and when exactly when people say things like that. Because whatever period I look at, there were wast groups of people who did not lived like this happy ideal.
This overwhelming sense of anonymity is in my opinion typical for US suburbs and US mega shopping malls.
Most other countries have smaller and more intimate town squares, optimized for waking rather than driving.
Not to spoil too much but those people working land were cripples as well. Hunter gatherers had perfect life because unlike peasants they could enjoy their life instead of returning to the work in field.
Now think about how hunter gatherers were exposed to risk. What kind of stress they had everyday. Look at current animals how they live. It is some kind of freaking horror.
You an see I am not a fan of Harrari's book because it is "earlier it was so much better" without any real stuff in it.
This is the best way to put it!
It's all make believe and facade. As naive as this sounds, we have to separate our work time and personal time. I don't know if that means we should have dual personalities akin to having different themes/profiles on phones, or we should have a clear separation of activities, but without one, is what leads to OPs path, and I have been there.
Division of labor is a tragedy. In the long run, it destroys the soul.
Having experienced some kind of a burnout and depression myself, one of the reasons for seeking out help on the web might be the need to find that help from like-minded people, not just someone with some generic wisdom.
People are quick to recommend professional help, and they aren't wrong. But a person with burnout, depression or other internal turmoil may be in dire need (or at least desire) for camaraderie from people who he considers like-minded. I knew I was. It may be very difficult to find that from mental health professionals, and of course that may not even be a therapist's task. It still leaves a hole to fill.
Humans adapt, that’s why we became what we are. Not sure I have the desire to “live with 100
people in a village I don’t like” encoded in my DNA.
I don’t want to downplay any anxiety or frustration, but I believe every generation had it/felt it the same way. We push and work ourselves up until we reach the level if anxiety we cannot longer cope with.
Objectively speaking: Who would prefer going back 250 years in history? No way on earth. Not even as a king.
Yup, there are still some anarcho-primitivists who think technology was a bad deal for us humans overall, and that living in a tribal setting of hunters-gatherers is best. The infamous "unabomber manifesto" was broadly advocating for this worldview, albeit with a very negative, nihilistic twist to it as one might expect. Kinda ironic to point that out when you look at OP's nearly-utopian attitude to tech, of course.
A wiser realization is that it's those in established power and the rich who are actively or willfully ignorantly sabotaging the planet and condemning billions of people to relatively more poverty, misery, disease, and death.
A million people nonviolently showing up to the seats of power, arresting crooked politicians and their enablers, and fine-tuning what cannot be fixed (by any POTUS, SCOTUS, or COTUS) from within (separation between church and wealth and state, public campaign financing, clean elections observed with exit polls and international observers, de-emphasized celebrity political promotion perhaps by lottery [as the ancient Greeks] rather than mainstream media popularity contest) are the necessary first steps before fixing anything else.
Most of the time, the alternatives aren't any better. That's why some people are apathetic.
Doesn't really bode well for any future mass action.
If the 10% was distributed differently, in the intent of maximum damage instead of minimum damage, and if they had a clear goal of overthrow, the ruling class would be fucked and the stock market would be at 0.
Of course, having a "strike" where everyone is willing to go back to work and only non-essential people are striking will not do much of anything as far as power relations. That much is obvious to anyone.
And you don't need 100% turnout for an election to work; you only need a nearly unbiased sample.
In practice however, the national guard will start shooting beforethen (see: Haymarket square massacre, Battle of Blair Mountain), so you better stock up on weapons just in case.
If we value the ability to experience consciousness ourselves, then surely the fact that 7 billion people exist is valuable in and of itself?
For that matter, the whole point of the primitivist argument is that humans have been quite happy about living in extreme physical deprivation for most of their history. It's only when the social milieu is totally FUBAR that "poverty" as we know it becomes a cause of deep unhappiness and dysfunction. Also as the OP shows, people can also be quite unhappy with their life despite living in a highly developed country and enjoying quite a bit of material wealth.
Citation desperately needed.
Specifically talks about how Hong Kong protestors have almost no formal hierarchical structures (to avoid the Chinese state arresting the leaders), yet remain highly functional and effective.
I agree that any group of people will eventually have some form of conflict but I don't agree that a hierarchical structure is the only way to resolve said conflict. You could just as easily apply any of the methods of governance that humanity has devised to resolve a conflict so I don't think the method of governance is crucial to the resolution of conflict. I think that getting both parties to agree to a satisfactory resolution is what is critical. That can be done with force as in a hierarchy where an external party enforces a resolution on both conflicting parties or it could be done without outside intervention, this obviously happens all the time in a variety of situations.
Ideally, every conflict should be able to be resolved directly by the people involved without additional harm being caused. Maybe there is a way through education or other tools that we can build that would allow people to resolve any conflict in such a manner? Maybe prevention is the best remedy and there exists a way to defuse conflict before it reaches a level that cannot be easily resolved. My point is that resorting to authority or force is not the only solution.
"We all know what is best for us, but I'm not going to actually say what I think we should do."
While nature vs nurture is fun to speculate on, when raised in criticism of another's work it is usually only speculation and otherwise unproductive. Also often ignored is that they are somewhat conflated insofar as people's nature creates environments that then (not independently) nurture.
Challenging something that's universally challenged seems comprehensible to me.
When did this happen? A female chimpanzee will grow up in a tribe of 30 to 150 and then at adolescence move to another tribe of 30 to 150, and occasionally, after a tribal war, end up in another tribe of 30 to 150. Each tribe was typically surrounded by 1 to 5 other tribes of 30 to 150, and of course the chimpanzees had to keep track of their enemies, just as any species that engages in territory and warfare will have to keep track of what territory is held by who. So the average chimp has to keep track of several hundred other chimps, as well as tigers, gazelles, monkeys, etc. It's a complex situation.
When you say humans track 30 to 100 people, do you mean 10 million years ago? Because you can't mean homo sapiens? I personally know more than 12,000 people:
Also, you misread the original comment when they wrote "their whole lives" -- they are asserting people never know more than that 30 to 100 people, an assertion which is absurd.
What are you talking about? Just because you have to know someone to keep track of them doesn't mean everyone you encounter you can track or care about.
A plausible just-so story, but still only that.
They're not time travelers from the past. They're our contemporaries, who are every bit as 'modern' as us. They just made a different set of choices along their historical arc.
> ...there's no real reason to suppose that humans at the most primitive state of society were living any differently.
At the same time there's also no real reason to suppose that primitive humans were living any similarly.
We just don't know. Any attempt to frame this differently is just ideology.
If these people never went through the social evolutions the rest of the world underwent, they are indeed travelers from the past.
Logical error. That they didn't go through the same social evolutions that we went through doesn't mean they didn't go through any social evolutions at all.
(And indeed they must have; even keeping their societies static takes conscious effort, in the same vein that conservative reactionaries today aren't at all the same people, ethically and sociologically, as the simpler ancestors they try to emulate.)
Unhappy about <MODERN SITUATION> ? Well, in the stone age <MODERN SITUATION> wouldn't have happened, therefore, genes/anatomy not adapted and blah blah.
Addicted to <MODERN HABIT> ? Well, cro-magnons found it hard to <SATISFY NEED> and genes/biology adapted to move us to <SATISFY NEED>. So now that we have solved the problem, you still have these genes that get you addicted to <MODERN HABIT>...
It was an interesting thought the first few times that I encountered it. Now it feels like a cheap way to sound clever. "Oh, this guy has an evolutionary basis for his opinions, he must know so much about history biology and genetics too"
I propose we slowly let this cliche fall out of fashion.
> Think about all the food stands that you have walked past in your life, within each stand is an immigrant family who slave away for decades hoping for a better life. Have you ever thought about them and gave them time/money for their suffering?
I know what you mean and know what you're getting at. But I feel compelled to point out this particular example isn't quite the same. I never sought the immigrant family out, then told them that my motivation is to support amazing cooks rooted in authentic traditions. I just bought the food.
VCs will lie, literally. They explicitly say they will act in a particular way in a specific situation, and then, protected by nuanced 300 page contracts, will do the exact opposite of what they said they'll do. Assuming you accept that lying to people is unethical, people act transactionally with immigrant vendors, but not unethically in the same way.
Now see it from the VC's perspective, the game attracts all kinds of hustlers who'd lie to investors without a second thought as well. My friend and I were talking about what business culture is like in a certain area of the world, and he said: they oversell everything, so take everything they say and divide it by two, and start from there. So part of it is also a pre-emptive mechanism based on a history of such behaviors from others.
None of this make things "ok", but I'm just sharing an anecdote from the other side.
I think a lot of the problem is not necessarily what the VC's do when it comes to situations, but that they lie, to themselves, to others, or both, about what they will do and at a fundamental level who they are. There's a world of difference between telling someone you're their friend and will protect them and nothing will go wrong when you know there's a good chance it will, and telling (or being) a friend but being up front that your job means you will act a certain way in specific situations, and that may be against the interests of others.
This happens in business, and it happens in personal life. I respect people that are consistent and represent themselves accurately, even if I don't like them or agree with them. People that misrepresent themselves are relying on an information asymmetry that they're creating to give themselves an advantage. This clearly works in many instances, but it also a "burnt-bridges" strategy that only works because of the relative anonymity that modern society provides. In some ways, this could be solved by more information about these people and how they function (which is how the free market works, best with more and more accurate info), but that's hard to accomplish because of their relative power.
In other words, everyone should be looking in the mirror.
> You blame everyone but yourself for becoming "soulless". Your very use of this word reveals a great lack of soul. You misuse it to describe working like a machine, an automaton. The nurse who is working like a machine to save lives at great risk to her own has the most wonderful, beautiful soul. What makes you soulless is that you're only thinking about yourself and "new products" (ways to make money) without any hint of a conscience troubled by the decisions made and actions taken in pursuit of those profits, and what that says about who you are. Or maybe the depression was a conscience trying hard to speak out, but it got snuffed by drugs rather than getting heard.
Why would you be at all surprised that VCs lie?
And of course, it's not like you have to get VC involved in order to run a successful business. You can self-bootstrap, which lets you focus 110% on efficiency and doing more with less. No BS involved.
But good God was my job (big company, lots of politics and bad management... the usual) absolutely soul crushing. I thought that I'd be able to make my peace with it in lieu of everything else which was near perfect, but the more time dragged on, the more it crushed me and sucked joy out of the other areas of my life. I will never forget the sense of existential dread that would overcome me every Sunday evening and the relief on Friday evenings.
Fortunately I was able to leave and take up an opportunity at a small startup in the ML/consulting space. It's entirely bootstrapped, so no VC people fucking everything up, and the management are incredibly nice and decent humans, and several of them I count as close friends. I love the work that I do, and I am almost always learning new things. I've been working here for 4 years, and I have never yet experienced that existential dread on a Sunday evening. Work is just another part of my life that I enjoy now, and it is incredible how happy and fulfilled I am with my life. My wife has fortunately experienced the same with the move and change in jobs.
I get hit up by recruiters for the big tech companies all the time and there simply is no reason why I would ever consider working at any of those companies to be another cog in the wheel. No amount of money can ever make up for what I have now.
So I would strongly encourage anyone who is in the situation described by OP or me above to try their best to switch jobs if possible. I can't fathom going through my whole adult life as unhappy as I was at my first job and I wouldn't wish it on even my worst enemy.
That being said, I think places like ziprecruiter / indeed will still have job postings from smaller companies. The challenge, as you mentioned, is trying to figure out the good ones from the sketchy/shitty ones. Small companies can also be challenging if the management isn't great and they have bad culture. So I would definitely place a lot of weight on that if I were interviewing at smaller companies.
I'm debating if I should take the job, assuming I pass the interview, to set foot in industry or keep searching continue working on a potentially monetizable passion project.
1. You have good academic credentials
2. You are trained in a "hot" field (my Ph.D. was in Physics but I've always loved software engineering and ML, but that was a very hard transition for me to pull off)
3. Getting a year or two under your belt is probably better than a large gap in your career if things continue to go south on the employment front. I suspect a decent number of ML/Datascience people are going to be laid off if they haven't already because they end up being more expensive and it isn't as easy to quantify their net impact / benefit to a company.
Just focus on how you can use your time at any job right now to improve your skills and round out your profile so you are a more attractive candidate for the kinds of jobs you'd like to target in a few years.
Also, if things bounce back in the next year, demand is still going to be high and you should be able to find a better job and switch relatively easily.
Like everything else, we need to find balance. I like my job and think that in general I do good work. But I am not my work and my work is not me. It's a part of me, to be sure, and I feel connected to it, but work is a relatively small part of my identity.
I think though that "meaningful work" is different from deeper meaning in life. Confusing the two causes suffering. I have worked at an adtech company with really good people. I helped start a nonprofit publication in Brooklyn full of college friends, artists and academics- which ended up being the sleaziest group of backstabbing grubs imaginable.
I have a manager right now whom I respect. He (CTO) gives good project guidance and makes clear decisions based on rational business reasons... I like him but have no illusions that he would fire me in a second if it were in the interests of the company. Keeping this in the back of my mind helps me modulate my response when I am frustrated or really almost any emotion to the excess.
Its possible to do very meaningful work without being friends. You can even be friendly and go out and drink together from time to time ... but always remember what you are there for.
You can find meaningful experiences out of work. They can even be "worklike". I am an EMT on weekends and I end up thinking about it during the week. The relationships at the corps are important but in the back of my mind I can understand that this activity is not exactly work. It could be but at the moment it is not. I am a systems engineer.
There is a lot to unpack in this. I strongly agree with you that work is about as central to our identity as can be.
I've been miserable at NYC tech companies with unlimited vacation and catered lunches... And a crappy attitude was at least 50% of that misery. (2 months of covid-19 and I find myself missing the commute at times)
When I was in school I worked for the university for free tuition. I was a groundskeeper and mowed and planted. I was outside. I occasionally drove a dumptruck to get loads of gravel or dirt. I worked with a guy who dropped out of highschool and played heavy metal in our truck as we drove around campus. When it rained we would hide out and play chess. He was an interesting dude full of contradictions.
I hated the job because I felt humiliated as a student working a menial job on campus. In hindsight I can see how important a job it was. It enabled me to get through school and afford a place to live. There were fun moments and good experiences (driving a full dumptruck down route18 is its own thrill...)
I was limited mostly by my attitude and a posture - who I thought I was. Dreaming about being somewhere else and avoiding people I knew.
I still catch myself engaging in that kind of behavior.
We do need to relate to each other as humans though work. This requires lots of re-calibration.
I realize the audience here is probably mostly younger folks but 10 years doing anything is not that much time IMO.
I think a 3rd or 4th burnout at 30 years of service is a lot harder to recover from, but I’m biased from my own experience.
Yet...Here i am.
I got to kick back a bit and the job was more about delivering accurately and not delivering volume. I spent the first 3 years in that position recovering from prior burnout while still working. I got bored, so I quit and started a business. I worked myself for years right into the ground, burned out again. I took a few months off and relaxed. I ended up geting bored again before I fully recovered and went back to work.
I changed career tracks and switched technologies figuring this would give me a challenge and excitement. A new profession, systems, and rules of engagement. I was truly excited at first and I worked hard. Then I burned out again, before having recovered from prior burnout. This time it isn't due to lack of work/life balance, its due to lack of technological and social satisfaction.
At first I thought it was a bout of imposter syndrome as it's a new career but as time went on I realized it's more about the industry, the direction it's going, and the effects of people getting into STEM for money and not because they're technologists. It's a lot of younger folks who boast about their adderall abuse, get excited to give presentations, and other stuff that I'm really not interested in.
I'm stuck in burnout #3 now. It’s easier to burn out after the first one. I don't have the ability to make a risky move at the moment, I have people who depend on me. I don't know what my next move is now but as you age and your responsibility grows your options shrink. I think I might ride out the virus and look for a new job in the hopes a new environment will give me a push to keep going.
This is common but not a universal experience. I do have much more responsibility now, but also a lot more options; unlike in our youth, we have no unsecured debt, don't live paycheck to paycheck, and have savings, which gives me the ability to plan ahead.
My two cents: I find joy doing challenging work on products that are useful to a bunch of people without needing to be "the next big thing". But what I find more joy in is my life outside of work, in spending time with and taking care of my extended family (including my close friends). The most success I've had with this so far has been at a big tech company. This is for a number of reasons: the product I work on is more likely to be useful to lots of people that way (because a lot of the marketing work has been done already), which also makes the work challenging (because scale brings challenges), and compensation and work-life balance are good so I can spend a lot of low-stress time focusing on family. I personally find the most joy working on things that mostly make money through charging people money for services because it feels like the most honest way for my salary to be paid, but I'm not sure how much that relates to this, it might just be a personal preference. Reading your post, I wondered whether you misinterpreted your big-tech coworkers. They might not have been checked out, they might have just been doing their work while having other interests that were more important to them. That is my interpretation of the people I work with (and of myself). I think it can look pretty lame to excited young people, but it's actually the opposite; what's lame is being super into working rather than other better things.
But as a follow-on, something I've been thinking about recently is whether I can take the useful skills I've built through a career in tech and apply them elsewhere, supported by the savings I've been able to build up. I'm not sure what that looks like, but being able to gather, process, analyze, and operationalize data seems important for lots of things, and that's something I know how to do (and I'm not alone here, software is largely about processing data). But I don't know what the most useful thing is to do with those skills; right now what seems important and in demand is epidemiology, but it's probably too late to become useful to this moment. Probably something in the broad sustainability space is more forward-looking. I'm still looking around.
I guess the two points I'm trying to make are: 1. You may be able to find joy by having more modest expectations, and 2. There may be other useful things to do with the skills you built, you should keep your eyes open for them.
Hope this helps a bit, cheers!
moral of the story: 99% of people still don't understand the nature of software. very few people--like rich hickey (clojure), or fpb (mythical man-month)--seem to get it. tech is mainstream and most people are missing historical context and experience.
(the goals of capitalism are typically at odds with building systems of the highest quality--and understandably so.)
the only creative spark in computing i have to sooth myself anymore is reading lisp or unix books from the 80s and 90s, because the content is so thoughtful (given the culture and smaller community at the time). the internet has become ruined by advertising and bloatware, and the culture has largely been ruined by bad habits and misunderstanding, imo.
You mentioned Lisp. I just retired last year, and just turned 69. I only use Lisp now (three planned projects for the macOS store, one almost done, and all my writing is concentrated on Lisp) and am dropping other programming languages that I used to also love, including Lisp languages that are not Common Lisp.
I also agree that the Internet is not what it could be but I still find value by finding a few people who I really enjoy, follow their writing and podcasts, and ignore 99.999% of everything else. I also find that reading books is much more rewarding that browsing the web.
I can’t shoot the shit and talk strace or gdb with any of them.
> My first burnout was pure depletion of energy. I was young, passionate, and believed in doing the best work I could. I was addicted to work and pushed myself to deliver. I did, and built a career. I left after almost a decade at that company [...]
(However, I never found a way to leave "Tech" for another profession--especially once I achieved a certain salary range, and others depended on me.)
> I can’t shoot the shit and talk strace or gdb with any of them.
Know the feeling exactly...
This is it. As engineers, we want to build the best can. As managers of a business, we want to product the most profit we can. As marketers, the more income that comes in, the better off we are.
Chose 2 of the 3. Marketing almost always wins one of those slots.
If someone could produce a solid infrastructure to get rid of ads and all that nonsense, but still get a product out in front of everyone, I think that might be the holy grail.
(I hope that if you figure this out - you might give me a .5% royalty) when your successful.
##Usenet is alive too. If you set slrn killing all
##spam, a lot of newsgroups are still bearable.
There is something else going here (or so it was for me). It's not the physical/mental exhaustion as is typically what defines 'burnout'. It's the depressing realization that most people around you are deluded piles of shit, even if they are 'nice' individuals.
> Your co-workers may be amazing, but they were never your friends.
Anecdotally, I've met some of my best friends by working with them. I have many friends that I haven't met through work, but when you spend the bulk of your day with people you form bonds - and friendships - with them. It's sort of human nature.
> There's what you love, and there's what you do. It's best to keep some distance: because no one cares about what you love.
What you love and what you do don't _have_ to be different. And some people _do_ care about what you love. Most don't, sure. And at most larger companies you _are_ just a cog in the wheel. But that doesn't mean folks shouldn't strive to find meaningful work that they love to do. It may not pay as well monetarily, but it pays in other ways.
> No, you only cared them inso far as they can cook for you. This is how others saw you.
I don't seek out the immigrant family, but I'm friendly and cordial with them. I chat with them and treat them as equals. I pay them fairly for what they provide me. I don't try to squeeze every last cent out of them or negotiate my meal from them, or make them feel like less of a person. And in return they provide the same. Maybe I'm naive, sure. But if so, at least I'm not an asshole.
> Big companies, and indeed most big institutions is made by a silent majority of the defeated.
This is mostly true. I agree. It's unfortunate. But big institutions aren't the only options.
> You have to look elsewhere.
You don't have to. You can, and in some cases you should. But it's not the only option. There ARE people who aren't wholly obsessed with making money at all costs. Unfortunately, in the US at least, a lot of people don't have that attitude and _are_ obsessed with making money at all costs. And our society (at least in the US) has been built in ways that praise that sort of attitude. But there are plenty of people who aren't like that. It's hard to find them sometimes, depending on what sort of circles you run in and the sort of people you surround yourself with - but they are out there.
An activity can have meaning in and of itself, and it's up to you whether you infuse something with meaning or not.
To me this is one of the themes of "Zen and the Art of Motorcycle maintenance".
Concerning valuing code you write for others, do you value finishing a crossword puzzle or a game of cards? Those activities are of no use other than the joy of doing them. Programming can be the same way, and I believe whether it is like that has a lot to do with your inner state and how you approach it, regardless of whether you're doing it for a company or not.
Well, actually (and I'm deliberately using my sock puppet account to say this as this is one of the things one should just do and not brag about):
For some of us, many of us, but not most of us I'm afraid, we buy stuff not necessarily because we need it or even want it but partially because of who is selling it.
Every time the kids come to sell the newspaper on the weekend I buy it, read two pages that I coild have read online and leave it on the table in case my wife wants to read it. She doesn't so it ends in trash.
Meanwhile I've been part of teaching one kid the value of honest work. My brother-in-law paid for his first Mac using money he earned from selling newspapers in the weekends. He is an amazing producer now and has been working both as a singke man production team with a local TV station where he lives, at international conferences and sometimes with at least one if not two national TV stations.
Maybe I'm giving another brilliant kid a chance now? Based on the fact that they show up every weekend there might be some potential :-)
This could have been a Scandinavian thing, but I know kt exists in the US too. I think I heard about it in an audio book named something along the lines of "400 things cops know" or something:
<something along the lines of>
> As a police officer if you walk by a lemonade stand or (something else I can't remember) you should buy! Even if you aren't thirsty!
Personally, even as a grown up I've had customers telling me in no uncertain terms to raise my prices, and I've heard my boss (or technically, the operations manager, two steps above my boss) telling me again to tell a vendor from a less fortunate country that the contract was fine but the operations manager refused to pay the ridiculously low price they quoted.
Do you think therapists get tired of dealing with people who are just unhappy with their job in a bubble?
Do I think that your therapist would judge you for your problems? Absolutely not, if they are even an OK therapist. They are professionals, and are not trying to be your friend.
Another thing. The first therapist I went to sucked. She had me doing worksheets and other stuff that just didn’t work for me. I ended up switching (my wife made me switch) to a new therapist and it was a huge difference. If you do end up trying therapy, remember that this is a professional situation. You wouldn’t go to the same bad sandwich shop for lunch every day. If your therapist isn’t working for you, and you have given them a honest try, just switch therapists.
Ultimately, therapy was a leap of faith that I’m glad I took.
Being unhappy for any reason matters. I discovered I was unhappy for much more valid reasons than I ever imagined and taking that leap to therapy was quite life changing. The key thing was that my burnout had legitimate causes that weren't really my fault or a weakness or flaw in myself (at least not that I could easily control), and I learned a huge amount about how I needed to move forward.
I really don't think I would have done it, ever, without therapy.
I had one in my city before and he was great too, but he knew a colleague might have more relevant experience. I was doubtful about the distance aspect, but it's been totally fine since day one. It's definitely worth considering.
Underrated piece of advice. Keep the way you make money and your passions separate. You love photography? Great, do it on weekends. If you become a pro you'll end up photographing weddings and hating your life and the thing you thought you loved.
Any advice to someone new in the industry to avoid burnout?
Always leave them wanting more.
(disclaimer: I've been in the industry for over 40 years... these days I avoid burnout by counting the dollars until I retire)
That's great writing.
Isn't that cultural? Cause I find I care a lot more about what people love than what they "do". Ask someone what they do [for a living], and you say "oh that's cool" and conversation is at a standstill again. Ask someone what they love and you'll get a whole different kind of conversation.
Work is not everything in your life. Work is important for sure, but there are other sources of joy in life. I can't help but think that Americans miss so much in life because of their obsession with work, money, and social status. Hence such posts on HN.
I think a lot of people are generalizing the comment to people in all positions. I've befriended many people I worked with over the years, but I was not the one paying them, giving or denying them opportunities. I also really loved what I did, but I was not the one making sure it had exchange value on the market. Friendship, "passion", etc are really luxuries the OP wanted in this position, but really could not afford in large quantities.
Burnout for me is caused by too much bureaucracy, too many meetings, and incompatible programming philosophies. Only twice in my long career have I left a job due to an insufferable coworker.
This really hits home for me. I'm at my most miserable when working with people who value doing things fast more than doing them well. I suspect those people are also at their most miserable when working with me. I see them as creating work that I'll have to do eventually to clean up their mess, and I suspect they see me as an insufferable gatekeeper.
Or do you dislike cleaning it up? In this case, why do you do it? Noblesse Oblige?
Asking because I love refactoring. I also love pushing features fast. But I absolutely dread having to do "perfect code" in the first try. I keep trying to push this idea (inspired by Mythical-Man-Month) here in HN that a perfect team would have people "working fast and breaking things" with people working behind them that love refactoring everything cleaning it up.
Of course not. I may enjoy cleaning up my own messes, but not one that someone else has foisted upon me. The problem with teams like this is that the fast-movers are long gone by the time the impact of their expediency is being felt. They benefit from the accolades of a launch while shirking the responsibility of operating a product.
> In this case, why do you do it?
Because the product sucks and needs to be improved, but it is an unimprovable mess because everything was done expediently instead of well, some of which needs to be fixed in order to move forward. A lot of the hard work at this point is in figuring out the best pragmatic balance of what to fix vs. what to leave alone. A little forethought could have saved a lot of post-facto toil.
I do like iteration, doing things in small iterative chunks. But that is not the same as putting out a huge mess and hoping someone comes along who enjoys cleaning it up.
Yes, :100: :100:
I have seen this happen so many times. It's a vicious cycle of horribleness. The same people always seem to get the new development also because they were "so successful with the last launch" and the people maintaining it are perceived as slow and ineffectual because it takes so long to iterate (ironically because of the person who looks like a rock star).
I feel very lucky in my career that I don't have to put up with this anymore. If I could go back in time I would just tell myself to quit and find a more compatible company instead of suffering for years under a self-destructive system that punishes people like me. Since breaking free from that and starting my own projects, I've been very successful.
I don't mean to imply that I always write perfect code, or even great code, because surely I don't. I do expect some things to be throwaway that end up staying around. But doing something correct rather than fast in general is a much better long term strategy. Vary as necessary (but only when necessary).
I HATE cleaning up people's messy code. It's 10x easier to do it right the first time. Messy code to me is most messy because it's unclear what is being done. It often comes with insufficient tests, which makes refactoring dangerous.
To me it's a lot like walking into a messy house vs. a clean house. If the house has clutter everywhere, or has a smell from being dirty, then it's not comfortable to be in. If I have to work in it, or clean it, I'd much rather start with a well-organized clean house.
Refactoring is also not fun at all for me. I also LOVE pushing features fast. I don't obsess over "perfect code" but I do obsess over following best practices and stopping for a few minutes to think through a design.
My workflow is:
1. Get it working, minimal effort, PoC
2. Get tests written and passing.
3. Refactor to good code. Perfect is the enemy of good, but it doesn't get committed until it's readable, maintainable, tested, documented.
Sometimes I probably am a little slower than I otherwise could be, but people are often blown away at my ability to iterate and add features quickly. This is because my code is well organized, modular, DRY, and well tested. It takes a little longer the first release, but it more than pays for itself speed-wise as tech debt stays minimum and hackability is high. With over 10 years experience now with this method I'm convinced that it's the only sane way to do things. Anything else is sabotaging your own future.
If I really don't have time to do it right the first time, I know it will be hard to iterate on, it will have bugs in prod, and it will never be pleasant to work in. It takes 10x longer to refactor an existing app to be good code than it does to do it during development when it's all fresh in mind. The best hope is that it has a good spec so it can be re-written from scratch.
I’ve got friends from every job I’ve had in the last 20 years who I still see routinely including some of my best friends.
Overlapping jobs like that indicates you are following a very different career structure than most people, so I’d hesitate to generalise your experience.
So many of my friends and neighbors came here voluntarily- They seem happy, but deep down they must be filled with so much remorse!
Your expectations, and the expectations of others, are your enemy here.
At least, that's what got me out it. I'm still disillusioned with the world but it's manageable if I can realize I'm making a difference to my son and wife every day, and that's what counts for me.
The OP said he is "disillusioned with technology" but I didn't see actual technology being described as the problem with any point. So there's a conflation here happening between technology and "tech" companies. And I can only say the phrase "tech" companies while using sarcasm quotes around "tech", because almost nobody at any of these companies develops actual technology. And that's a big part of the problem.
It doesn't have to work well, or be bug free, or compatible with the previous version, or address any real world need.
No! Instead it has to use fashionable technology and be extremely complicated so other programmers can see how incredibly clever they are!
Almost like they took a random bug from the issue tracker by looking at last nights lotto numbers and then they opened to a random page of Knuth by letting a fan blow on the pages for 5 minutes and said "alright, I'll solve this problem in that way! Surely everyone will acknowledge my genius!"
It may be a slow lumbering buggy pile of brittle barely functional code about to implode, but boy does it look nice!
However, even I can see that a team would get burnt if they built an enterprise software the way I code my personal email client. The problem here is that people forget that building software professionally is an engineering job. Like other forms of engineering, there are processes and good practices to facilitate both functional and non functional aspects of a software and the building process. While the extra burden of version control, testability and extendability takes some of the fun away, I would have reservations working with someone who pushes directly to a release branch, does not write test and hardcode values instead of uaing configuration. It's about balance and realising that job is a job.
However, the CSS was generated. From YAML. The YAML was generated from JSON. the JSON was pulled from mongo. The Mongo was updated through a strictly validated XSLT that had an enumeration of colors. Those colors did not include the button color we needed.
Don't worry! There was an ability to reroute the xml through the use of ruby mixins and then add the attribute by parsing the dom, editing it, then re-ingesting it later downstream so it gets out to mongo right.
oh and there's a cache layer at every point here. so make sure you invalidate it to see the change. every time.
I closed the ticket and did a few more like this for 6 weeks, mostly in ember - they were even crazier.
The product, an interface to some server software, had basic html with markup like this:
Like the most trivial stupidest simple code you can think of. 15 minutes of php, at most.
However, changing it to do something else was never direct. 4, 5, 6 maybe 7 different languages, servers, restrictions, databases, input and output formats ... absolute and total batshit.
I left. Company is worth over $100 million today, looks like I'm the loser I guess.
This isn't about having a dev and release branch, this is about endless layers of abstraction and insanity that make easy things 1,000 times harder and almost impossible.
I thought you were exaggerating to make a joke. Sigh.
> I left. Company is worth over $100 million today, looks like I'm the loser I guess.
Somebody played the lottery and won. 99.9999% played and lost.
You are not a "loser" for not playing the lottery.
As if we'd have 5 or so platforms and a single command to go "presto!" and build on a bunch of devices with a slight button offset change.
I always said "how about, if you want a linux version in qt, you fire up qt creator, drag your mouse around a bit, click a few times, take 20 minutes and that's it. You then literally just walk away because the work is done".
This doesn't mean that you were going to better off without git workflows, code reviews, tests. My experience has been the opposite. It's exactly where there's no good technical leads/technical discussions/code reviews I have seen this kind of mess. Each person goes on and do their own thing with no clear direction or architecture.
At the end of the day, for me, to stay sane in the face of this kind of nonsense(as in bad engineers - unfortunately there are those even at senior positions), so what if the button that could have taken a few minutes to change now takes 6 days if we are paid to do it? As a responsible engineer, you point out the issue perhaps with a proposal for improvement. If they listen, good. If they don't, fuck it. On the other hand, if all I end up doing is changing colors of buttons regularly, each taking a week, then for the sake of my career, just say no and move on - unless of course if the pay is so good that it makes sense to spend a couple years doing it - people have to do far more shitty jobs for less. And spend some of the free time to code like a cowboy :)
That's the whole point. What some people consider to be "good engineering" is a different set of standards, a different set of qualifiers.
Let's go back to 2012. I was yet again doing web stuff.
We had this hodgepodge of jasmine, junit, eslint and selenium and couldn't commit unless it all passed
But the tests broke more then the code itself, because it was <far more complicated then the thing being tested>. So more time was spent on fixing and babysitting the tests then writing the damn software.
Alas, we finally released and it totally completely bombed. Why?
Because those test suites don't care if something "feels" clunky or "looks" wrong ...The machine responded to the interface in machine time, it didn't actually test human time, which was the only thing that mattered. We should have relied on human dogfooding, like the business books say to do. I got arrogantly laughed at for suggesting it, multiple times; that simply wasn't "engineering" to this team.
Now of course tests are valuable, sometimes. But "sometimes", that's the important thing. Understanding when to make that call is actually important. When, where, what, why, and how - not just important for journalists.
But instead, like some 18th century royal court disconnected from reality, we did ceremony. So we wrote tests, most of them bullshit. One of the tests was essentially: "Does this image on the page load from s3?"
At least that one usually passed.
Except when AWS was down or our internet went out: "I guess we can't work today, the does_image_load_from_s3 test is preventing the commit." They were a waste of time and got in the way of actual work. But we HAD to have them, we MUST, right? Nonsense.
I'm convinced the tests were there because "doing it right" was about virtue signaling. So we built a salary defending potempkin village composed of pure thought stuff.
I imagine it all like a catholic mass: Men in robes walk around, ring bells, and use special boxes to wash their hands with special cloths; it's all very important if you go to church, but that's the point, it's praxis and faith: we were coding from plato's cave, creating intricate shadows of reality representing actual work.
Symbols passing as tools: like Dumbo fetishizing the feather and being oh so worried when it falls, everything passed the most sophisticated testing I had ever seen yet the program still crashed in the user's hands almost every time. All that work was mere ceremony.
Understanding how modern computing speeds and vc capital has allowed people to be wrapped up in their own bullshit, call it programming and get away with it, is a major insight into why technology sucks today.
It's not just you, everyone agrees. It's lame now.
I don't mean, dogmatically follow unit tests (actually my statement wasn't predicated on unit tests). If you have a better approach that can validate the software is correct then I'm all ears. If you have a better collaboration tool than git, I'd be happy to try it. With all due respect, what I can't do is take your word for it that you can build software that works (covers all functional and non functional specs), and they continue to work as more code is added, and is worked on by more than one or two developers, and that you can continue to validate and roll out more software over the years even when the original developers aren't around. It's difficult, costly. It can work, it's just not the best way. The industry will evolve and come up with better tools and processes than we have today as we did before yesterday. Only thing I took from the couple examples you gave is that you've had the misfortune of working in some terrible teams. Though I still don't see how you'd be better off without the rest of the usual practices we have today. The guys who couldn't code the tests, I can't imagine them building a non trivial software well either. I'm not defending any one process. I just don't agree that we don't need any process, and that we should just write code that (seems to) works.
This is what this whole thread is about.
If tests are "taking the fun away", like you said, they're shit. Simple as that. Tests are a productivity tool, they're supposed to make your job easier by providing faster feedback. If manual test is faster than automated test, your automated tests are shit. If they're causing developers to write the bare minimum of tests it will only generate a false sense of security. This is even worse than saying "ok we don't have tests, let's be careful and test manually".
It's like that stupid saying that bad documentation is "better than nothing". It's funny how people change their minds when they spend four hours or more on a stupid rabbit hole because of outdated documentation.
On the other hand, one of the best jobs I ever had was maintaining shitty web apps written without source control, tests, documentation, patterns. Thousands of lines of code. Some of them didn't even have source code: I had to decompile the production server DLLs. I don't have any coder friend that got burned out by "bad code". Not having autonomy to improve the bad code, on the other hand, made a lot of them change jobs.
You are describing "CV-driven development", where people want to use heavily marketed technology brands in their CV as a substitute for real skill and experience.
I've found a really nice perspective on this recently: An app can be a home-cooked meal 
It's okay to build things that aren't popular, that don't scale, or that aren't economically viable, for the delight of a few users.
But that's more an analogue of "use your program before you release it".
At least they are 'dogfooding' it and not just letting others eat it I hope :)
If I'm cooking a dish that I've cooked at least three or so times before I generally have a good idea of how things should be going and I can get away with only tasting once or twice at the end.
You can write unit tests and Spring components with 64 character names all day long but by the end of the day you are completely disassociated from your contribution. Rarely is anybody there to thank you, who is grateful you made their life better, or who has some simple joy over what you created. It definitely happens (e.g. a major release) but it's not a regular event. It often doesn't feel like you just made your community a little better by producing something sensible.
I know people who do hobbies like carpentering and they hand out their (amazing) work as gifts. You can see them oozing with fulfillment when they do and going into their hobbyspace is an escape from the world of work-for-a-living.
I have the same attitude with apps as with the books I write: if some people enjoy them and I get to occasionally meet (probably virtually) app users and book readers, then I am very good with that.
re: "going into their hobbyspace is an escape from the world of work-for-a-living": for most people this is really important. For me, I go wilderness hiking every day and have a hobby of cooking so I have several hours a day away from technical interests.
I have nothing to show for my 14 months at [redacted], but I still use the trivial little app I made years ago to redirect my search queries to different sites. It took all of 5 hours to write.
As a graybeard, I've seen multiple generations of "how to do software" and the most recent are the least fun. A lot of this is driven by the agile approach. It's tailor-made for dev burnout: from the endless tight cycles that force people into an infinite loop of productivity with scant satisfaction that comes with "completion", to all of the tools and philosophies designed to juice that endless loop to be successful/workable. CI/CD, Git, TDD, etc. These all impose on the developer's creativity, independence, and enjoyment. They turn devs into cogs--assembly line workers who must not stop the line at any cost.
One example: back in the day there was a nightly build, not a continuous one. And, you checked out a file, worked on it, and checked it back in. If someone else needed it they had to wait. That obviously had its limitations and it seems laughable by today's standards. But, it was reflective of a human pace that considered devs as people vs. optimizable assets. That is, it was workable because the expectations on devs weren't insane. But, now we commit and merge. Think of how much less fun it is to spend your time resolving merge conflicts.
More to the point, the approach itself implies a chaotic pace wherein code that meets the standards of a certain box must be produced at all times. Devs must bear the cost of resolving any conflicts (literally) that arise from this chaotic pace.
Likewise, with CI/CD. And don't get me started on the monkey-work that is TDD. You might argue that it improves code quality. But, it's hard to make the case that it improves job satisfaction. If you move more work from the creative, problem-solving bucket into the busy-work bucket, the result will not be personal fulfillment.
Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs.
I think the bad started for me (long ago) when the Microsoft style management and so-called MS best practices began to conquer the PNW.
In the late 90's a company I was in started driving to an exit. First they hired an ex-MS Group Program Mgr, whatever that means. Next, came tons of PMs pulling one or two devs into their projects/features. Doing it the MS way I guess (at least the MS way back then).
I was a manager, I refused to dole out my team members to PMs -- everything my team did was run through me. I don't even think I let them enter individual devs into their project plans. Just the team.
This worked well for us (my team) because I knew their capabilities, interests, family commitments, likes/dislikes, etc. I could adjust resources as needed to meet the team commitments. We had successes and failures as a team.
PMs who tried put pressure on my devs behind my back would really catch it from me.
My management style wasn't any new idea, it was what we did in the Army. Assign a team a task, then the team leader ensures the task is completed by the team.
It was a good time, we were the only real team in the place as the other managers embraced the MS way of doing things.
At end (right before dotcom bust) the company started doing some Agile-lite with two-week release cycles absent stories, standups, etc. I did like that enough to put it place at the next company I worked at.
I did get burned out though, mostly because I didn't want deal with what the industry had become as the last startup I was at petered out.
I still love programming but not enough to do it in modern shop.
This rings true. It's probably why I have always had a tendency to look sideways at these efforts to turn everyone into a coder. I get it: there's demand, opportunity, etc. But, for me, there's always been a cynical element of devaluing actual coders to it.
The stuff you're talking about regarding your management approach almost seems like a relic from a bygone era at this point. So many companies now allow the process to manage devs. PMs back then frequently over-focused on the work vs. people, but even many of them have been replaced with some version of a scrum master with an even more relentless focus on the never-ending storyboard. They're driving the work over people approach without apology because it's what the process demands.
This is not to say it's 100% the case across all companies. But, there's very much an inhuman element to the process that has manifested to some degree in nearly every place that employs agile.
> Likewise, with CI/CD. And don't get me started on the monkey-work that is TDD. You might argue that it improves code quality. But, it's hard to make the case that it improves job satisfaction. If you move more work from the creative, problem-solving bucket into the busy-work bucket, the result will not be personal fulfillment.
> Does agile increase productivity for companies? Sure. But, it comes at a high cost that's mostly paid by devs.
I agree wholeheartedly with you. I'm by no means suggesting we move back to waterfall, but I am really enjoying the work I'm doing more and more of lately: embedded. Nominally it's a sort of Agile-type workflow (Kanban-ish), but because there's hardware design and manufacturing in the loop, things get planned out early and the multi-month plan doesn't change very much. New algorithm ideas pop up and get scheduled, new ways of doing sensor filtering pop up and get scheduled, but the direction of the wind doesn't change at the start of every "sprint". There are no sprints, just a prioritized/sequenced task list that gets reevaluated periodically.
(Plus, I get to go back to my old days C-hacker roots. The thing builds with a Makefile and spits out a ~32kB binary that gets flashed onto the device.)
I've always thought this was a red herring for scrum people to smack dissenters with. I've never done a strict waterfall with unyielding changes. Before agile, we would do 3 month release cycles. We prioritized what we wanted to get done in the 3 months and what we didn't get finished fell off to the next cycle. This was done in BigCompanyYou'veHeardOf and SmallSoftwareDevelopmentCo.
In my experience, waterfall project plans were never meant to be in stone, they were just a guide to give us an idea of what the project looked like. I've done a 3 year plan too. I'm sure some places implemented it strictly, probably government or heavily bureaucratic institutions.
I started writing out the whole story, but in a nutshell: my formal background is a dual EE/CompSci bachelors, followed by an Masters in CompSci that focused on distributed systems. When I was a kid, I learned to program very young: Basic around 8, C in DOS around 11, C on Linux around 13. I fiddled with electronics some, but didn't really get it. I took the EE part of my schooling specifically because I wanted to learn more about how computers worked "under the hood" so to speak.
From there, I ran a web consultancy for a while, and ended up with a client that had a more math-heavy project. And then another client showed up with a project where a microcontroller made sense, and then another... My business partner was moving across the country, and I was enjoying what I was working on quite a bit more than I was in the web/mobile space, so we decided to part ways. I still do the occasional web/mobile project, but they're generally hardware-related (e.g. the Bluetooth connectivity portion of an IoT-type system). Over the years I've accumulated probably $15-20k worth of equipment and software license, and the customers keep showing up!
We have similar backgrounds in a way. I started coding as a kid too, at age 9. First Basic, then Pascal. Picked up C in my teens. Also tinkered with electronics and was part of an online robotics mailing list that was a lot of fun. It was very hard for me to get parts, living in the middle of nowhere in rural Southern Brazil, but some folks in the mailing list were super cool and shipped me parts from the US. I live in the US now.
I'm a CS major but took electives in embedded systems in college, and those were some of the most enjoyable classes I took. I'm now working on recalling some of that. Ordered some PIC parts and I'm currently taking an edX course on ARM programming.
My only problem right now is, I have no idea how I'd get into that space having a whole career built on server-side software.
If you ever need any new hires... /u/cblum and I would like to have a word
I've always loved the carrel desk. It seems perfectly designed to encourage the state of flow in its occupant.
is it a form of abuse like trying to keep everyone under control? is it a form of psychological conditioning to remind you that you just a resource whose top priority is to be interrupted at any time so knowing that you don't really have any personal space sovereignty or privacy to your own thoughts or creativity but that you must answer and create only for the collective?
I don't feel I have a clear picture on what it's about any insights?
Open offices facilitate that feeling of persistent accessibility and production. No closed doors to slow anyone down, and no notion that you are there to do anything but work every minute of every day. So why on Earth would anyone need privacy?
This is full-on agile ethos. And, for the same reason, agile is also responsible for the reversal of telecommute policies at some companies.
When I call someone and in the background I can hear 20 other people talk, I immediately assume that the person I called is not considered important in his/her company. Because high-level work needs uninterrupted quiet time.
For agile, it's similar. When you stop having different roles, then you implicitly assume that your lead architect and your junior trainee can do the same work, albeit at different speeds. If your architect has useful experience, that's an insult. Or it means that your entire product is simplistic enough to be built purely by trainees.
So both open office and agile effectively reduce your programmers to expendable grunts.
Also (and somewhat contradictory to the above), I expect that, if your colleagues are _too_ easily available, you'll be running to them with a half baked question in your head, only to blurt it out before realising you didn't think it through, and wasting both their time and your own. But before you go knocking on someone's office door to ask a question, you really want to be sure that you know what you want to ask, and that you understand the problem well enough for the answer to make sense to you. Which leads to a better conversation, less time wasted, and better learning.
The crazy extension of this is "free desks" where basically every place is a workstation, and you don't have any space to call your own.
I have similar views on wfh, fwiw. Like 1-2 days a week is fine for me but full time remote is far too isolating IMO.
Fresh out of undergrad, open office layouts feel familiar to the long hours spent sitting at big tables in library basements, so I can see why some people like it initially. After a few years, you will be pining for four walls and a door to get anything done.
> The difference is, with your own space you can do deep work on your own terms. No longer is your train of thought constantly interrupted
What's wrong with headphones for deep work? Or appreciate not everyone has these, but where I work atm we have small 'quiet zone' booths where you can take your laptop if you really want to focus deeply.
As for being interrupted, again maybe it's just a company culture thing. Where I work people are generally pretty respectful if they see you with headphones on intensely focused on something, they'll probably just ping you a message on slack asking when's good to talk. But equally if people have headphones off, open body language- everyone feels happy to strike up conversation and there are no barriers in the way of collaboration.
So to my generation, this bouncing ideas thing is less of a requirement because we're used to doing our own work.
If you look at scientific papers from fifty years ago, most had just a few authors, now many of them list eight or ten.
The team approach seems to be taking over the world. However, I would point out that most truly great work, think Nobel prize, or truly awesome engineering work (K&R, UNIX) has till now mostly been achieved by individuals or by small teams, and that there was a lot of focused individual effort put into them.
I don't mean to sound condescending at all, because the young are going to win out by default, you guys are the future and we are the dinosaurs. You preferences and work habits will become the correct ones (whether they are better or not).
However, I would suggest that you like open plan environments because this preference has been trained into you since early grade school.
What I really hate is filling in form A, which directs you to form B, which you fill in to see whether form C is required. Form B was put in place by a legal team, who don't provide any point of contact, and who are not your friendly local legal team.
Because the process of filling out forms is so time-consuming, your engineering team uses Asana to track it. However, your PMs use an excel spreadsheet, the legal team uses JIRA, your copywriters use a google doc, and the teams that own forms B and C use separate internally created tools. You update your form-filling progress in 6 different places, some of which have bugs and others of which aren't actively monitored, so you also have to use email/slack/skype messages to follow up the right people. Some of the right people are actually the wrong people. Some of the right people reject your proposal because they didn't read it properly. A few of them reject your proposal for reasons that are actually valid, but which you could not possibly have known, because they're based on tribal knowledge which is not documented anywhere.
Filling in the forms and fixing the issues takes literally 3 months and at least 4 group meetings as well as several skype/zoom calls. One day you are finally allowed to write the code. It's 150 lines including tests, across two services, and you're done in two days. Everything that caused your proposal to be rejected would have been found in development. You quietly wonder whether you would have been happier as a bricklayer.
Anyway, I think my comments on CI/CD, Git, etc are being misconstrued. I'm not saying they don't have value. I'm saying they are frequently part of an ethos that leads to developer burnout.
For instance, your CI/CID process is one you must "appease", along with the rest of the bureaucracy. It may not feel as odious (and may even seem a relief, relatively speaking), but it contributes to your total load.
And, Git is fine. In fact, perhaps even perfect for the current culture (in philosophy, if not always in execution). Each developer has his/her own repo, you can work offline, you merge instead of locking check-outs, etc. But, that's the trick: it feels perfect because it allows you to work in the always-on philosophy of agile. Its popularity sprang up because this world of high burn-out, constant productivity demands it.
So, we can see the utility of these things and even appreciate them. But, the model they enable and expectations they create can still ultimately lead devs to burnout.
A lot of the comments in this thread are pretty funny to me. CI systems are awesome when they are working. It is a real pain in the ass not knowing when something is broken or not being able to find out when it broke.
Similarly, writing good tests is really helpful for me. I do this even on my own personal projects.
These things are so helpful to me that these comments are like reading about people who hate source control.
>writing good tests is really helpful for me
I'd wager it's partly generational. If you came up in the agile world, then you likely see the upside but not the down since there's no reference point for the latter. Because, of course it's cool that these CI build processes kick off at commit points (or whatever). And, of course, the near instantaneous feedback that something is broken is more efficient than awaiting a nightly build. OTOH, we were much more cautious about the code we checked in because the stakes were higher and you didn't want to be the heel who broke the build. "Move fast and break things" was not a thing. Instead, "be thoughtful about what you're claiming to be good code" was the ethos.
But, this is not an argument about efficiency or whether these things can be made to work. The argument is about the cost to the developer of all of these things in sum, and the philosophy they serve.
Likewise with TDD. I'm not arguing that tests don't help code quality and I've heard others say they like writing them. YMMV and all that. But, it's more load on the developer and I've definitely seen it overdone.
So, again, without the reference of a "saner" world then you don't likely have the context to fully appreciate these costs. I see them, though, and frequently hear them when people complain about burnout. It's not CI/CD or TDD or whatever that's the problem. It's that these things are frequently used less as tools and more as the instruments of a philosophy that plugs developers in alongside them as just another part of the never-ending pipeline.
Then I started working at a big company with a good engineering culture, I learned about writing tests and related tools, and had a much better experience. Now working without these things feels like driving without a seat belt, or maybe using a grinder without safety glasses (car accidents are too rare to be similar to bugs being introduced...).
I still have fun writing personal projects. It's just better with tests and CI. It sounds like you are pointing at issues with management styles that just happen to exist at the same time as useful tools like this, but I think they are almost if not completely orthogonal.
Not sure I'm getting my actual point across though so, rather than repeat myself, I'll just say the "continuous" part of CI/CD has implications on us as humans that are difficult to fulfill over the long-term. So, maybe really consider that word continuous in this context. We're just not made to be cogs in an automation pipeline that never ends, which is essentially where the philosophy (and its enabling tools) places us.
So, it can feel fine and you can see the merits of the tools, etc. But, none of that precludes the burnout that so many devs ultimately face over time.
A quick test framework that doesn't require too much boilerplate, a Github Actions CI that runs in a few seconds and help me, continuous deliver that has everything figured out for me?
I think those are a net positive.
When it makes my job a living hell? Nope.
A CI that takes 40 minutes to run? A CD that requires manual intervention and has "a line" of builds and you have to babysit your build? Testing that requires multiple lines of boilerplate?
Then I'd rather live without those things.
Now... don't get me started about JIRA and other tools, which are a tool for micromanagement.
This weekend I implemented RS232-powered RGB LED that is controlled attiny85, which reacts to strings sent to that very same RS232. A gross violation of standard, probably, but it works! It definitely added a lot of joy.
I typed “git init” only after I finished the first working version which had a regular One-color LED, and could not yet do blinking :-)
One thing that made the development of it all immensely easier was having a Saleae logic analyzer. Highly recommend it (no affiliation, just a happy customer).
- Implement a CPU and peripherals in an FPGA
- Throw together an OS
- Make a handheld game console
Why? Because it would be fun to remind myself of the "first principals" (not talking physics here) and play around with it.
For now, I'm playing around with Raylib  and Allegro  which are C game libraries.
Do you have a link to your console hardware?
Does not sound like it would keep me sane…
In academia the aim is to get a proof of principal, write a short paper, and move on. If you care about reusable code you are building a foundation for someone else's success, but not necessarily your own.
Neither side is wrong, it's just a different game.
I would say to also work in a domain you care about and like. I don’t like technology for technology sake and never did.
I like solving problems and see technology as a tool to do so. I love the company I work for, the people and the problems we get to solve. I love even more when I solve them without the need to write a single line of code.
When I started my first programming job a couple of years ago I joined a team that demanded 100% code coverage. I hated them so much. I was still learning the ropes at this company and I only saw the unit tests as a barrier to getting my work done and earning my paycheck. My first solution was to create bogus tests that always passed. That was quickly discovered and I was reprimanded. My second solution was to get colleagues who shared my hate for unit tests to approve my PRs before they were reviewed by my team. That too was thwarted.
Then one day I was working with a teammate on a new feature and we discovered a bug. He quickly opened up a test file and wrote a unit test, then he went tried a couple solutions until the test turned green. Then he looked at me and said, "When when you are working in a pile of crap, testing makes you feel more confident about your code." That was my first insight into the value of testing. Eventually I came around and stopped trying to avoid tests. I just did the damn work. Once I established trust with my teammates they began to let the pressure off my PRs and slowly the displeasure of writing tests went away.
You pointed out a few different coding practices that frustrate you. And to be honest, those coding practices are not the gospel and should be deployed only when truly needed. However I think you have a serious problem with what a lot of us call being a good teammate. At the end of the day your goal should be to get the product shipped, once you focus on getting your features out the door, unit testing and pull requests become minor details in that process. At the end of the day those are just a cutesy to your teammates to show them that you are willing to be a responsible and helpful team member. Stop trying to fight everyone so much and maybe you will enjoy your job a little more.
> "Don't make enterprise software. [...] Don't accept pull requests. Simply write software for yourself and have fun doing it."
I've recently started doing that and it's been a breath of fresh air.
I don't really like the stuff I work with, which is services. I think I've become good at it given the feedback I get from my peers every review cycle, but I really don't like it.
I felt burned out for a long time because of that.
Recently I've simply been doing what I'm interested in, in my spare time. That's learning about embedded systems, something I had an interest in in college but never pursued a career. And for fun, tinkering with old stuff that makes me nostalgic. I spent this last weekend coding in Pascal and messing around with FreeDOS :)
Believe it or not "all the edge cases" can still be perceived by the right mind. It's just that we as an industry have done seemingly everything we can to push those folks out, just look at OP as an example
I've supported ten-digits-per-year (non-SAAS) businesses without unit tests or code reviews and oftentimes deploying straight to production. As the sole SWE for my codebase. Supporting hundreds of remote installations with nothing more than SSH tunnels relayed through an ancient, colocated linux box. And the software was very good, didn't ship with many bugs (and when it did they got fixed real quick), and there were never any catastrophic, non-recoverable issues, nor ever any questions on the integrity of the system or my reporting. We were never seriously hacked (to our knowledge). Crazy times... not sure I would do it again, but.... it can be done.
My first dev job we did most of our work in vim sessions on the development server, and more than once I was asked to hotfix live code running in production. Through the grace of God and an abundance of caution nothing ever seriously blew up as a result of all this madness. (Though, ask my boss about the time he tried to move our MySQL instance onto some very early SSDs) Again, it can be done. I'm sure most of the old hats lying around have tons of stories like this.
Most of my job is replacing stuff like you describe. And it's definitely not fine. Nobody knows how it works because that single SWE is gone. It can't scale with the business and it's a huge drag on productivity because nothing can change without a massive testing effort to ensure it's not broken.
In my last job I'd advocate tirelessly for unit tests, code reviews, all that. And it was always denied. Ironic given that the other engineers I worked with were MEs, who had notebooks full of processes describing how they were to work so that engineering issues would be caught. But the software? "I don't care how you do it, just ship the feature"
As an aside, I've always found "nobody knows how it worked because XXXXX is gone" to be kind of funny: the code knows, so go read the code. It'll mean everything takes 100x longer but the knowledge is there.
My approach to that is to not ask, just write the unit tests anyways, ask a peer to code review without management permission, etc.
We are professionals. Part of that responsibility is to know the best practices for our craft and put them into practice.
We also need to be good at getting the requirements from the technical and non-technical people we work with, and being able to show consistent, incremental progress, and a willingness to quickly change direction when the requirements change.
But we do not need to get input or permission for the process we use to produce those results.
There are plenty of SWEs that just don't know any better. I know because I was one of them while writing a lot of software for a business.
I was drawn to software at a time when it seemed like we had control over things. With the advent of the cloud I feel like that control keeps slipping away more and more. Kubernetes is my new nemesis. I seem to be in the minority that perceives it as unnecessarily complex for most tasks. Someone once commented here on HN that the k8s trend made them think people are trying to pretend their code doesn’t run on hardware anymore, and that really resonated with me.
My boss recently introduced Kubernetes to our software deployment.
The first thing he said, though, is if you don't absolutely need Kubernetes, don't use it. It is extremely complicated and finicky and difficult to deploy correctly, and can bite you in subtle ways.
Then he went on to describe, for our problems, how Kubernetes was absolutely necessary to scale without constant manual intervention and configuration and deployment processes consuming our time.
I appreciated that he had thoroughly thought through the problem before adding more complexity.
I do think there are options to achieve all of that - scale without manual intervention, etc. - without Kubernetes though. At least where I work, if I look at the deployment issues we have, those are all the product of bad decisions and lack of action due to higher priorities. There's no reason why there couldn't be more automation. They're building something new on Kubernetes which looks promising (though I really hope that as an app developer I don't have to think of Kubernetes things, which just irk me), but the current platform would work well too if investment was made into automating the parts that aren't automated.
Indeed. Haven't people been doing that since, well, cloud computing?
You don't have to always cover all the edge cases. If you write software for fun, you can often just bake-in assumptions and neglect a lot of edge cases.
Working Effectively with Legacy Code
Book by Michael C. Feathers
There are lots of weird if checks to deal with a vendor that returns bad data over the api every Sunday night. Your new clean code is going to crash and burn in all of these cases.
We need to accept change. Your company eventually will move you to a new project or dismiss you. They need to put your software baby on maintenance and squeeze out the last bucks before they shut it down. Life continues with or without you. If you become pro-active, you'll have a fun ride with it.
Web development could be stupidly simple if we wanted it to be. I feel like it got too easy, and suddenly there were waves of bootcamp grads, and a lot of developers resented that.
I thought we were talking about technology. You gave a recipe for spaghetti.
Engineering has its place. But you can also make art with an engine lathe, and doing just that every now and again can be a balm to the soul.
I have written personal projects both with and without tests and every single time I don't write them I wish I had, usually pretty quickly. The time you save by not writing those first few tests always seems to be lost, and then some, pretty quickly in the extra manual testing that is required.
Pro: You can do whatever you want
Con: You can do whatever you want (including things that will bite you in the ass later)
I've also noticed that AI/ML falls into the exact same pit because many folks there are cowboy coding
There's a careful balance here though right? For most projects your first users or clients are the unit tests. Why not have a future of repeatable client/user tests that insulate from regressions and to be your wingman to navigate future iterations? Also for me, I still review and accept my own pull requests on solo projects, because it is that last step when working on my own where I know I'm at a good point looking at my diffs and the last step in introducing mistakes.
Lets change the story to be about an artist being burnt out of art industry. Suddenly he has to deal with all the grant money, politics of the gallery etc. Feels like he doesn't want to do anything with art anymore.
And somebody in the thread suggests the artist just go to the nature and paint and don't think about any art styles and acceptance of peers and trends and etc. Just give yourself to painting and don't think about anything. Just paint with a coal on stones and loose yourself in it.
And you comment would be something like "There's a balance here though, you still need to paint on canvas with acrylic or something, otherwise you won't be able to validate your art in the future for you to progress etc."
Buuuuut... a lot of the personal projects I've worked on have zero unit tests. Maybe they have a couple of tests around a complicated algorithm, but mostly... no automated testing. What they do have though is a) version control, and b) a fast-iteration platform underneath them. They're also generally well factorered into small chunks.
As an example, I have a package that takes an org-mode file and extracts time entries to drive into time tracking software a client uses. Written in Lisp, zero tests. Every month I fire it up, look at the table of entries it's about to post, and hit "go". Looking at the table of entries provides two sanity checks: first, that I properly logged my hours that month (I'll occasionally forget to clock out for a weekend and rack up a 48 hour time log), and second, that it didn't encounter a bug while doing the processing. As of around September of last year, this program is done, and does its job perfectly every month.
Another example, also in Lisp, is used for making estimates for my clients. I give it a list of tasks with 3-point estimates, it churns through and calculates all the means and standard deviations, generates a file for Pandoc to consume, and spits out a PDF. I use it every couple of months. No tests, all done inside the SBCL repl. I obviously proofread the output PDF before sending it to a client, but that's again to check for bugs and to check for brain farts.
I've worked on great codebases that have giant test suites, and I've worked on terrible codebases that have giant test suites. And likewise for no test suites. While I appreciate the sentiment, I think it's dangerous to talk in absolutes like that. While I agree there is probably some degree of correlation between whether or not a codebase has a unit test suite and whether it's good code, writing unit tests does not intrinsically make the codebase good, and not writing unit tests does not intrinsically make a codebase bad.
In all projects I have worked on, extensive unit tests were not a safety net against regressions, but a safety net against change.
Heh, yeah, that's fair, although I think there's some nuance in terms: accidental changes (to things that were working) is a form of regression in my mind. Depending on how the codebase is structured, changing the tests to match the new desired behaviour might be trivial or might be excruciatingly complicated. These days (mentioned elsewhere in this discussion) I'm working on more embedded stuff, and the only time I'm generally writing unit tests are for things that shouldn't change.
As an example, last year I was working on a custom LoRaWAN stack. As I was building out the various pieces, I was writing tests to verify that the output from generally-pure functions came out as expected. (This packet) + (This key) = (This encrypted packet). Those kinds of tests help a ton for catching stupid mistakes.
I see good value in modern unit tests when you are building some sort of automation engine, rules engine, etc. But I think a lot of people see them as a hammer and everything is a nail.
IMO a lot of places have forgotten the value of manual testing in terms of not only finding bugs but actually understanding how the product is used. Games companies prize iteration speed in terms of how quickly you can test a change in situ because we as game makers need to verify our changes by playing the game. I'm making a multiplayer game right now so I need to make sure what I do works on the server and clients which usually necessitates three copies of the game running together. Then we playtest it with a larger group weekly and playtest with even larger groups less regularly.
My impression of a lot of modern development elsewhere is that as soon as automated tests are green the code gets punted into production which seems utterly bonkers.
BUT I think we should also acknowledge that everything that slows you down in your free time has a reason for existing and most of that is communication or knowledge sharing within a team. Naming conventions, unit tests, and general documentation all exist to help other team members keep up with the pace of changes in the repository. If you're not planning to do something in a team setting or for this to be consumed outside of the work that you do then you don't need these things. But if you want to share with everyone else it's important that you don't totally ignore these things because it will come back to bite you in the long run.
Kinda like the idea for personal. Why spend so much effort to structure projects so others can use when chances are they won't or you don't care if they do. Work is governed by different realities.