I try to remind myself every day how much rougher it was before I got a dev job. The financial hopelessness. Living in junky apartments with roommates as a married couple. Commuting 4 hours one way 2-3 days a week for part time jobs with no security or benefits. Trying to live off $20-30k a year in California. And still feeling lucky to have any work at all.
I try to remember this while sitting at zoom meetings and feeling exhausted. But the memory is fading...
i remember one time i was on vacation in costa rica and on a zip line tour. guy asks me where im from what i do. he said "oh man that's the dream, you just sit in a chair in the air conditioning all day? you don't know how lucky you have it!" and this dude runs zip line tours in costa rica.
grass is always greener
This stuff has been very salient to me the last couple of years. I had a friend who was in a physically abusive relationship, and she was often comparing my behavior, feelings, and thoughts about my job to what she was going through. It's definitely not the same, I don't want to trivialize anything, but in some circumstances a workplace just becomes sort of [emotionally] abusive, extremely dysfunctional, and starts to have tangible harms for spouses, family, etc. in terms of lost time, income, career opportunities, etc. I wrestled a lot with questions like "is it better to not have a job than an abusive dysfunctional one, when it's hurting my family at some level too?"
This isn't the same as putting up with some awareness that what you're doing is existentially empty at some level (which has its own set of issues), but balancing costs and benefits of jobs sometimes is trickier than it seems initially. I think maybe it's the same as the grass-is-always greener you mention, although I think that can go pretty far.
I would almost argue that having a physically tough day makes me feel sore and tired, but _accomplished_ at the end of the day. Having a mentally tough day doesn't confer any sort of sense of accomplishment, it's just a draining feeling.
Also consider the "happy" ending to Office Space--the protagonist ended up much more satisfied doing a physical construction job in the end.
The point is that no matter what you are doing there will be bosses you hate and annoying parts of the job.
When I'm having this conversation, I usually reply with something along the lines "yes, but imagine that most of your job in that air-conditioned office is doing math tests". It's not a perfect analogy, but it's a pretty valid one in terms of mental fatigue.
We (mostly) make enough money to do pretty well, might as well use it to enable ourselves to enjoy _something_ in life. For a while it was improv for me, now it's more powerlifting, but literally anything you can enjoy that's not work.
I banked the experience and learnings and moved to a company which wasn’t in the fatal decline stage of development.
I could not have said this better myself. Yes, we are paid extremely well, but the soul-crushing grind of building stupid web apps for companies that don't even need them really takes a toll eventually.
I think of Candide from time to time. Who can say if this is the paradisaical garden and alternatives could be much, much worse. Either way it's human nature to be restless. Maybe we can't all have the better job. This turns my attention to side projects, but I think as it pertains to tech, I don't have that much interest.
Plenty of jobs that involve moving around real stuff in real life rarely feel meaningless (though, again, they may have other problems, especially wear & tear on one's body).
But you know what? I still remember the feeling that you had at the end of the day, seeing stacks upon stacks of these bales, nicely filling the warehouse, how satisfying this was.
I don't remember the last time I felt like that when programming.
Nothing tech related I've done over ~20 years of being paid to do tech shit has been half as good. Buuuut that job paid barely over minimum wage and had no benefits. So. Here I am.
[EDIT] Oh, and not a single screen all damn day! Old-school cash register and paper records.
I suppose it's easier said than done, but the healthiest thing I did for myself in the transition to WFH during the pandemic was to set up and maintain appropriate boundaries between myself and work.
I'm done at 3:30. If you contact me after 3:30 I'm either ignoring the message until I'm "at work" the next morning, or I'm writing my time up as billable hours.
I've never been questioned on it, and the idea of muting my phone or leaving it in another room provides a mental break that helps with everything
Turn off that chat thing when you need to focus. Skip meetings where you neither will learn nor can contribute a unique perspectives. Turn the machine off when the workday is over to deal with the WFH blurriness. Push back on murky requirements.
Yes, it's hard, and it's scary. And I fully ack that in some companies, this would be career-limiting moves. If that's the case, you need to decide how much you want to work for them vs. going somewhere that actually lets you work as a dev.
This is a hugely important thing to learn.
Fact is, it's extremely unlikely a business is going to fire you for pushing back on something you can demonstrate is ridiculous. And engineers should be financially prepared to leave or be fired by employers being unreasonable with their requirements.
The biggest problem remains enough people being willing to put up with these insane demands that the requirements continue to get bigger. I haven't seen much fighting back until the "great resignation", and even that I'd consider mild.
The thing about working home alone is difficult. I highly believe that hard deadlines and fixed meeting times destroy the whole concept.
I wake up when I feel to, and do whatever needs to be done and I feel more often motivated to actually do work then I did ever before.
In reality, Scrum went from "empower engineers" to "allow managers to micromanage their employees even more, but we call it Agile so you can't push back against it because then you're challenging the orthodoxy."
* We track velocity as the key capacity planning metric. We don't use it for performance or anything else (e.g. we don't care if it creeps or if two different teams have two different velocities).
* We then break down all of our work and estimate it. This gives us a scope.
* From there, we have a conversation with our PM. Here's the timelines you want to hit. Given the data, we need X. Do you want to cut scope or extend timelines?
-----
Lastly, we focus a lot on making decisions that maximize velocity over a medium-term (typically 4 to 12 weeks). There is little value in pushing hard in one sprint if it's going to have an opposite reaction in the next sprint.
There's no reason why anyone should need to be "certified" for a methodology to be applied. There isn't even a reason why SCUM methodology should be applied as a sort of universally applicable process.
The funniest thing about SCUM is that every diagram someone makes of it looks nearly identical to the straw man that is "Waterfall."
https://en.wikipedia.org/wiki/Scrum_(software_development)#/...
I mean, tell me that you couldn't change some of the jargon on that diagram and fool just about everyone into thinking it describes Waterfall.
The only thing potentially differentiating between SCUM and Waterfall is that the former has (in theory) a smaller iteration window and has liaisons between development and management. But the latter argument is nonsense because generally non-agile teams still self-organize into having liaisons and middle-managers.
And as you pointed out, the answer to why SCUM fails always comes down to not doing it "correctly". If no one can do it correctly, that's because it sucks. I've seen agile principles applied in different ways successfully, but I've never seen SCUM actually work any better than no formal methodology at all.
Scrum is only a capacity planning tool. Within a certain context, track velocity. When new work comes in, estimate it then compare to velocity. If you don't have the timelines you want, then you need to consider changing scope.