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.
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
But humor me with an explanation, please...
There's a reason I don't work there anymore.
I don't care what the theoretical outcome is when the practical one is always this.
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.
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
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.
AFAIK, it does nothing to help here. But a solid leadership does help.
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.
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.
>> 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.
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.
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
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
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.
Recognizing that and accommodating it is a sign of maturity for both an engineer and a manager.
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".
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.
> I think that many developers who say they dislike Agile really mean they dislike Scrum.
True say.
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.
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.
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.
If you've never watched Simple Made Easy I really recommend it: https://www.youtube.com/watch?v=LKtk3HCgTa8
> [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.
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
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.
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"
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.
If you don’t know or can’t reach consensus what your goals and principles are, no process will make your org functional.
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.... :/
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.
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.
Agile lets you manage expectations and set boundaries by scheduling a finite amount of work into a bounded amount of time.
If you don't like SAFe then please be specific. Which parts of it don't work if actually followed as documented?
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.
A good personal open source project is worth more when interviewing than anything else really. Can't fake that in an interview.
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.
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.