On a mature project in a small team, the only tickets left were hard bugs that nobody wanted. The kind of bugs where you can invest days and have nothing really to show for it except crossing out some suspicions. Or maybe incorrectly crossing one out and then going on a wild goose chase until you circle back to it in a week, flustered.
You're expected to commit all of your mental energy to these tickets day after day, and then once you finally triumph and solve the bug after coffee or amphetamine binges, you turn in the code, close the ticket, and you're expected to immediately work on the next ticket.
You don't get a real break. But you can mentally rest at the start of the next ticket since nobody expects instant results. But now it's been a couple days and people are asking you what you've been doing so far—you must be blocked, right?—but you've barely started and you're pressured to invent small lies and excuses about why you're behind, each one risking yet another slip of the mask.
And when you need some time off the most, it's when you're the most behind of all and people have begun to notice, so taking the time off doesn't even seem like an option.
> The kind of bugs where you can invest days and have nothing really to show for it except crossing out some suspicions.
Me, with zero C/C++ experience, being asked to figure out why the newer version of the Linux kernel is randomly crash-panicking after getting cross-compiled for a custom hardware box.
("He's familiar with the the build-system scripts, so he can see what changed.")
-----
I spent weeks of testing slightly different code-versions, different compile settings, different kconfig options, knocking out particular drivers, waiting for recompiles and walking back and forth to reboot the machine, and generally puzzling over extremely obscure and shifting error traces... And guess what? The new kernel was fine.
What was not fine were some long-standing hexadecimal arguments to the hypervisor, which had been memory-corrupting a spot in all kernels we'd ever loaded. It just happened to be that the newer compiles shifted bytes around so that something very important was in the blast zone.
Anyway, that's how 3 weeks of frustrating work can turn into a 2-character change.
Personally these can be the best bugs though because you have an opportunity to learn something new (your work environment is everything though). Compare that to a ticket in an older codebase with hard multi-cause bugs that are just painful to debug and leave you with nothing but a deeper understanding of something that is slipping into irrelevance by the day.
In my experience, administrative process that was previously done by a bunch of administrative assistants and then "computerized" around the year 2000.
The original stakeholders are long gone, the system is too valuable to be replaced and each quirk handles specific cases that are not documented anywhere. Bonus point if it's in a semi-dead language like VBScript. Please fix.
I once ran into a bug that only happened in a specific version of the linux kernel when combined with a specific version of the java JDK, worse 2-3 weeks of troubleshooting of my life.
We found an issue in the kernel bug tracking that seems to explain it, but we never confirmed for sure. Fortunately updating either of those things fixed the issue. This was of course also hard because this was back in the golden days of vmware managed by client's IT team, so getting them to update things on a VM was hell as well.
I hope that people who suffer from exhaustion and a lack of breaks are setting realistic expectations for themselves, and not simply assuming that they need to push themselves to (or past) their limit. It is a rare manager who encourages you to work less, but it is (in my experience) a common manager who understands that breaks and self care are important. They just need to be reminded sometimes. You can push back, and a healthy organization will respect you for it.
Crazy enough, I'm from the management school that believes the work is only the tool to develop the person and pay the bills. I will always sacrifice the work for the worker. It's sad that the majority of managers see this in reverse.
> I will always sacrifice the work for the worker.
The attitude I see most often is: "the worker is replaceable and therefore expendable, but the work will always be there until someone takes care of it so burn through as many workers as it takes to get it done"
I like to call this zero sum management, and the parent to your post is a good example of positive sum management.
As long as the business is making money, the prospect of it continuing to make money in the near and medium term future is not in jeopardy, and the actors involved are rational, capable and trustworthy, you should always favor the worker over the work.
IME, zero sum management is an emergent symptom of a poorly performing business (maybe if we make everybody work 150% harder we’ll hit our targets this quarter), insecure executives (who don’t understand the work they manage), or poor hiring/firing practices (the only way to let somebody go is by overloading them and rewarding it with a poor performance review, or you’re hiring people who aren’t capable or don’t care).
If you’re a manager forced to make zero sum decisions and don’t feel empowered to change the root of that problem, you should probably consider leaving — good environments grow people instead of expending people.
>IME, zero sum management is an emergent symptom of a poorly performing business (maybe if we make everybody work 150% harder we’ll hit our targets this quarter), insecure executives (who don’t understand the work they manage), or poor hiring/firing practices (the only way to let somebody go is by overloading them and rewarding it with a poor performance review, or you’re hiring people who aren’t capable or don’t care).
This breaks down when you have one player in the arena acting like a snake that tries to devour everyone else(eg. Elon Musk). He has the gift of attracting an endless horde of people to burn through and then tosses them aside once they are no longer useful to him(so many examples in his recent bio). The result is that they move faster than the competition and the others eventually get eaten alive. Normally word would get out that its not safe to work for such a character but SpaceX and Tesla are among the most desired employers that engineering graduates seek to work for. Tesla received 3.6 million job applications in 2022.
Some persons are extraordinarily good at discovering big+solvable problems, and at continuously convincing other people that it’s worth burning themselves out in pursuit of it.
I think it’s worth pointing out that some projects are worth that level of devotion, and visibly so in real-time.
But we can’t make a project worth that level of enthusiasm and attention just by demanding people to act like it is (the siren song that leads to the earlier-discussed culture spirals). Often-well-meaning people will put the cart before the horse, but no amount of quacking will turn you into a duck, etc.
On balance, it’s healthy to be skeptical of people demanding devotion to some process or objective that’s not rooted in first principles you can agree with.
It wouldn’t surprise me too much if a meaningful proportion of the 3.6m applications per year are filed by people who find the first principles behind Tesla’s culture worthy of their devotion.
But yeah, the number of companies or projects that would benefit from that style of approach is quite small. 20% is the ceiling, 10% feels closer to the truth.
Some people really like killing those kind of bugs. I know people who would move from project to project, at the end of each, killing the show stoppers. I've done that myself.
But what I'm describing there is an environment where:
1. Developers are treated with respect
2. Different skill sets and different motivations of those developers are recognized
Actually what you're describing is completely different. Because if you're expected to only be working on those long, abstract, difficult tickets, none of the pressure to deliver features/bugfixes piles up as in the GP comment. But when you've got features on deadlines, there's not enough freedom to skip meetings and chug coffee all day without turning in any code.
Expectation management is a huge driver of quality of life.
Knowing how to carve out your niche and not be expected to delvier feature after feature without a break is part of "managing upwards", which is another important life skill to gain.
"carving your niche" involves either through a lot of experience (power) or to be known in the industry (clout). The latter isn't all based on raw skill so you just hope you don't burn out before you get to such a point.
A lot of those long, abstract, difficult bugs become blocking/ship preventing issues, so...no pressure. And alas, many (most?) developers suck at debugging, so if you're any good at it, you get everyone else's broken code to fix. sigh
>> you turn in the code, close the ticket, and you're expected to immediately work on the next ticket.
Yes. That's me. And then I crash.
I used to call in sick when I go from heroically solving something unsolvable to start work on a new ticket. Then O thought, this is not sustainable. My boss is all over me for all of my sick time.
So then I started to just say to my manager, hey, Mgr, amma gonna flex this whole Monday. Don't call me. Don't frakkin even think about me. Back on Tuesday, we cool?
Turns out, we were cool.
Whenever someone requires from you to be a hero, don't. Or be that guy, then take a Monday off.
This. Software engineering can be a mentally draining task, and just like with physically draining tasks your body needs time to recover its strength. Nobody would expect an athlete to last very long doing back to back events without recovery time between them - they'd end up injured. Your brain is similar.
Recognizing that and accommodating it is a sign of maturity for both an engineer and a manager.
> What kind of runner can run as fast as they possibly can from the very start of a
race?
> [Audience reply: Sprinter]
> Right, only somebody who runs really short races, okay?
> [Audience laughter]
> But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint.
don't you just have normal time off on top of sick days?
But if you're in a flexible enough situation where you can just call up your boss like that, that's great. That's what "unlimited time off" should theoretically have been before the well was poisoned. Trust that workers can manage their own mental health but not abuse it to be gone 30% of the year.
Who left bugs like that on the board until so late in development? Unless they're just "tricky / nice to haves" that everybody knows might not be tractable (taking the pressure off you), that's some "odd" management. No wonder you burnt out.
Working at a place like this now and I saw at least one previous workplace go from a healthy engineering org to something like this when they brought in new engineering leaders who all wanted to make their mark quickly.
The problem is often systemic and a symptom of an engineering team not really having control over their own roadmap. You see it when an engineering team isn't agreeing to take on work, but rather being told what to work on by people outside of the team. Sometimes it's isolated to a single team, but sometimes it can be a whole org or company. It's caused by bad expectations around the amount of work that can be done and unclear priorities. How many people it affects depends on what level the bad expectations are being set at.
In practice, this is how I've seen it play out. There are 10 developers worth of work that needs to be done by X date, but we only have a team of 8. No one has made it clear what the prioritization is or if they have, that priority isn't universally accepted or changes day to day. If everything is equally important, the tough work that may not have noticeable results is often what gets pushed into the backlog over and over. To people who see engineers as the "build new features" people, it's hard to regularly justify "I can't build feature X because I have to solve bug Y" and then a week later say "I still have no idea what's causing this issue".
It's easy to say, well just get everyone to agree on priority and what a reasonable amount of work is, but that's far, far easier said than done.
Man you have terrified me about my current situation. I'm currently on a team that is managing an extremely mature internal Angular project. The small team of two devs are just doing tickets like what you describe yet the management has no problem with this and does not hound us over why we haven't committed anything in days or a week+.
This is due to their lack of technical knowledge and they have accepted this reality because the outcomes that they want do end up happening so they dont rock the boat(or know how to since they can't discern technical stuff).
I know its a great spot to be in short term but Ive been scared because long term I will be in a big hole when the next role comes along and its more like what you describe and I haven't grown to match the role. I've considered leaving once the market improves but I don't think I can fathom giving up what I have either. Alternatively I have considered staying until I eventually get downsized but that could be years. I don't know.... :/
If you are worried about your career prospects built a portifolio with what you want to work in the future. If your mental state with the project doesn't allow you to work in arcane bugs full-time, reserve some time for personal learning and portifolio building, but keep working full-time.
A good personal open source project is worth more when interviewing than anything else really. Can't fake that in an interview.
I have been slowly doing this but in my experience, I have never had anyone care about my open source projects and the real problem is not raw coding skill, its being able to work in a large team and follow all modern processes that you'd pickup in modern teams. I am trying to learn and adopt these processes on my team (my coworker is onboard) but its a slog.
For example we compile locally, then manually move the compiled code over to the server instead of using something like docker. Part of this is the restrictions we have over our environment, part of this is inertia.
Fortunately I haven't given up trying to move to that paradigm but sometimes I actually dont want to be on a modern team. Its like I have plateaued to a comfortable state that I know wont always be there but I wish it did. I hope what I am explaining makes sense.
Agile itself was a response to this problem, and was invented by engineers who wanted more control of their work. It's become a whip for management but when it's done right it can be pretty freeing.
> taking the time off doesn't even seem like an option
You don't get what you don't ask for. If you're asking and you feel like you're being overworked and reasonable requests for breaks are denied too much, work on finding somewhere more reasonable. Sure, easier said than done, but worth it to at least try in the long run.
Now, of course, everybody is going to start moaning, "But I have all this speed. I'm agile. I'm fast. You know, this easy stuff is making my life good because I have a lot of speed."
What kind of runner can run as fast as they possibly can from the very start of a race?
[Audience reply: Sprinter]
Right, only somebody who runs really short races, okay?
[Audience laughter]
But of course, we are programmers, and we are smarter than runners, apparently, because we know how to fix that problem, right? We just fire the starting pistol every hundred yards and call it a new sprint.
Agile isn't meant to imply speed in the sense of LoC/s, though right? The speed in Agile is about getting customer feedback sooner rather than later (so maybe a kind of latency?). I don't think sprints are mentioned in the Agile manifesto or related materials.
And even within frameworks like Scrum, I don't think that "sprint" was ever intended to mean that programmers are supposed to be in permanent crunch mode.
Why call it a sprint if it's not supposed to be anything sprinting? We can literally call it anything we want, so why not pick a better metaphor?
I think that many developers who say they dislike Agile really mean they dislike Scrum. I mean, a rugby scrum is pretty violent, and sprinting non-stop is a good way of dying of exhaustion.
Come to think of it, some managers do seem to want the workplace to be a ruthless battleground with worker pitted against worker in a relentless flat-out sprint to seen as a "high performer".
If I recall right, Sprint originated from Extreme Programming, a predecessor to current agile methods.
In XP, there was very much the idea of spending time to prepare for a sprint. Get requirements and preconditions worked out, clear out possible distractions.. Then you'd use a 1 - 2 week long sprint (aka actual crunch time) to knock out 80 - 90% of a feature with everyone on the team under high pressure and positive, constructive stress. And then you'd have some time after the sprint to work with low pressure, clean up technical debt, consolidate and build up for the next sprint.
And honestly, that's a pretty effective way to work if you plan and gear up for it.
There's nothing ideological about SAFe. It's simply a collection of best practices which work reasonably well in most organizations. You can pick and choose which pieces to adopt and which to ignore. Like any methodology, it can't compensate for toxic management, technical incompetence, or lack of product market fit.
If you don't like SAFe then please be specific. Which parts of it don't work if actually followed as documented?
I literally linked an article going through why SAFe is MBA garbage that misunderstands why agile was created in the first place but if that's not specific enough for you then I'm not sure what you're looking for.
Perception. Interpretation. Either way, "sprint" is intended to imply short burst, definite endpoint that can be seen. A Burndown is about measured capacity. The only actual speed that matters is time to failure, i.e. "fail fast".
Does it? At one of my former jobs management would regularly pressure engineers into doing late nights at sprint end (every other week) if we were "behind". Then if we finished things a day into the next sprint, the PM would backdate the completion to make it look like we had hit the previous sprint, since sprint completion percentage was an OKR and people's bonuses and promotions depended on it. Then since we hit the sprint, obviously our velocity had to go up for the next one, even though we were starting a day late from scrambling to "finish" the last one.
The expectation that engineers work overtime to hit arbitrary metrics can’t be fixed by a process like scrum or waterfall though. Process can’t replace competent management.
Agile causes a lot of those problems. GP just described all the elements of agile, "pick up next ticket as a on as one is closed", "blockers", daily status updates, etc.
Agile done right solves these problems. I have yet to see Agile done right, even once. And I've done XP since ~2003 and Scrum since 2006. It is now clear to me that Agile does not solve these problems: a solid leadership team solves these problems, and sometimes solid leadership teams use Agile (whether formally like Scrum, or informally, like just good communication). But Agile is the canary in the coal mine: it reveals very quickly if you have a solid leadership team or not.
To me, "agile" in these discussions only apportions blame, it's orthogonal to the quality of software.
When it's an agile project, either devs will choose to do the right thing, or too many developers will work on new features, whether because it gives them more visibility or because they like working on features more. And when it's not agile, either you have a product/team manager that understands the importance of not drowning in tech debt, or you have a manager that constantly prioritizes features over quality.
Neither approach guarantees that the right choices will be made, just that in Agile, the developers mostly have themselves to blame.
don't get me wrong agile is an improvement in the sense that iterating on small deliverables is better than a single giant waterfall process, no disagreement there
but yeah if your tool never delivers in the alleged benefits, ever, anywhere, then it's not good enough to say the problem is the people
tools are welded by people
if your tool doesn't take that into account and assumes and requires its users to be perfect, well, then it's not a very good tool
It's funny that Agile is always something else. It cannot be criticized because then your are doing it wrong. It's like a theory which is not falsifiable.
no it doesn't lol it literally causes them? i'm no waterfall advocate but at least with waterfall there's a clear beginning, middle and end to a software project with intuitive places for work, rest and celebration
meanwhile doing maintenance on an existing system in an agile environment, esp with kanban, is very often literally what the poster is describing, an endless slog through tickets that aren't particularly noteworthy and thus don't really merit much consideration or celebration when done etc
Scaled Agile Framework (SAFe) has a regular program increment cadence of every 8-12 weeks. This provides intuitive places for work, rest, and celebration.
On a mature project in a small team, the only tickets left were hard bugs that nobody wanted. The kind of bugs where you can invest days and have nothing really to show for it except crossing out some suspicions. Or maybe incorrectly crossing one out and then going on a wild goose chase until you circle back to it in a week, flustered.
You're expected to commit all of your mental energy to these tickets day after day, and then once you finally triumph and solve the bug after coffee or amphetamine binges, you turn in the code, close the ticket, and you're expected to immediately work on the next ticket.
You don't get a real break. But you can mentally rest at the start of the next ticket since nobody expects instant results. But now it's been a couple days and people are asking you what you've been doing so far—you must be blocked, right?—but you've barely started and you're pressured to invent small lies and excuses about why you're behind, each one risking yet another slip of the mask.
And when you need some time off the most, it's when you're the most behind of all and people have begun to notice, so taking the time off doesn't even seem like an option.