> I also believe that being too helpful leaves you vulnerable to predators. Tech companies are full of people who want to extract uncompensated work from software engineers4. This is different from work that arrives via normal channels, and for which you’re compensated by promotions, bonuses (and just your normal salary). I’m talking about work that arrives via backchannels, from people who don’t have the ability or willingness to ensure that work is formally recorded under your name. For instance, a product manager from another organization messaging you to say “you’re so good at querying data, would you mind pulling some statistics for me about X?”, or an engineer from another team asking you to “pair” on a piece of work that will ultimately involve you writing all the code and them quietly submitting the change under their own name.
I’ve had a half-written blog post in this vein for a while now using a fantasy RPG analogy: if you play a character that uses mana in any of these games, you’ll learn fairly quickly that using it all up all the time on trivial battles and running around empty leaves you with none when you genuinely need it.
Your mental energy deployed at work is not so dissimilar: keeping some in the tank gives you the option to deploy it strategically, rather than risking your health (burnout) when something unexpected comes up.
If you join a group in one of these games with a player who is bad at managing their mana, you’ll also find that they’re not such great teammates, either.
One thing I've noticed myself, if you are not sufficiently challenged for a while it can be extremely difficult to surmount the next challenge. Peak "abilities" for me in whatever categories has always been when I had enough work in front of me to just chug away like a machine, and enough trust where I didn't need to stop and constantly explain myself but could just work uninterrupted towards the goal. Skills would grow like wildfire and tasks would be completed sooner than expected.
Unfortunately very few jobs are structured to take advantage of that. So many blockers and distractions from you getting into actual deep work.
> Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts.
Not to be sarcastic but just to offer an observation: in a sufficiently large or bureaucratic organization, preventing an incident from happening can rarely get you any credit or visibility. Such achievement falls into the bucket of "what you're supposed to do". So, those who navigate company dynamics well would rather let the incident happen and then be loud on the follow-up action items. The trick is not to turn an incident into a diaster, so it's a dedicate act.
Also, disaster is a good signal to the higher ups that there are problems in your org. If you keep putting out every fire with heroics, your boss will know (maybe), but his boss's boss's boss will see that your org is doing great and everything is all code green.
If you let a few things burn down, your boss's boss's boss will notice the fire, and things may improve. It's perhaps the easiest way you have of communicating with them.
I learned this early in a conservative org. Preventing things is risky. Just keep the solution ready for when things go wrong because then you'll get approval.
If you want to collapse just run a system at 100% for baseline, there's no slack, there's no capacity to meet new demands, you're just running a permanent failure mode if there's any perturbation in the system.
Except ... the collapse never happens. Once your engineers burn out or age out you just hire fresh meat and the cycle repeats. The issue I have with these types of articles (and books like Peopleware / Slack) is they never provide any actual metrics that may convince the beancounters to try a different approach.
The metaphor that changed my perspective came from the book, "The Power of Full Engagement", paraphrasing "you're behaving as if you're a world-class endurance athlete without an off season - stop it."
There's a lot of wisdom in this. In addition to reserving some capacity for when true high-value work comes along, I think software engineering is not the type of job that you can do well if you're constantly busy. Trying to write some code as quickly as possible seldom yields the best design. This article doesn't get into another important aspect of this, which is how to get away with working at 80% capacity without getting in trouble with your manager. This takes a bit of care around communication and estimation of work. One of the first good pieces of advice that I got from older seasoned developers when I started my first real programming job has stayed with me to this day: take your estimate of how long it will take to do something and double it before communicating to your manager/users. As you get more experienced that ratio can come down to maybe 1.5x instead of 2x, but the principle still applies.
Kent Beck (maybe in Good News Factory but also in talks) that his team would never commit to more than half what they think they can get done. This is a good way to sustainability. And that's the optimization and precedent to set; that we are here for the long term, delivering steadily at a sustainable pace. It's a long game, and over promising only runs down trust, which is your biggest means too getting the space we need as Devs.
Under promise, build trust that we can do what we say, earn the space we need to not burn out.
Honestly the more senior I get (Lead), boundary setting and preserving my attention; not burning out, _is_ the job. Because there are myriad ways to do this to yourself.
Yep, if you want to run a sustainable business you don't look to fire on all cylinders all the time, but that's the rub, almost no owners are looking to run a sustainable business anymore.
Most people either want hypergrowth idiocy or to be bought by the people doing hypergrowth idiocy.
Setting consistent expectations means you can plan, you can actually reasonably budget, you can have predictability in your business dealings - if you are trying to run a good business these are all real features instead of "puts out more code that might or might not make us money, but at least we were pulling all nighters and adding perceived meaning to our lives!"
Sigh. This article is obviously completely correct, but I don't think the people who actually need to read it will care.
Running anything at constant 100% utilization means you are going to be working in crisis mode all of the time. Even in factory labor, the Toyota Way is several decades old now, and it involves making sure everyone has at least a little breathing room to step back and think about what they're doing. And obviously this is even more important for "knowledge workers" or anyone whose output requires any amount of creativity.
High functioning organizations have a good (not too much, but not too little) amount of slack in their work pipelines. Pretty sure there is not a single person with an MBA (or, lol, any consultants) that knows this anymore.
I've been "Doing nothing" at work for a couple of weeks now, and it's freaking me out. Yes, I have asked for tasking, but the guy in charge is ... I just don't know.
Why? The moment you touch the code you become responsible for it. Can't count how many times I fixed something on a goodwill and then became responsible for it.
The testers have the latest build, and have not reported any bugs. I don't even know if the project I am working on is even going to be funded after a few more months. I am just in this sort of limbo that really sucks.
It's a good practice to run at 80% utilization and it helps if you are not being managed by people with an overseer mentality, who demand 100% from you all day, everyday. They are the ones who misinterpret the look of software engineers working in relaxed silent repose as lazy idleness. That's why remote work is the best thing to allow me to keep some utilization in reserve and to keep my sanity.
Doing a little bit of "glue work" can make you indispensable and also a hero to your team if it makes everyone's work life a whole lot better and no one else knows how to do it.
I'd argue 80% is high. This also varies between Devs. The way I learn, think about things, struggle to get started etc, means my 80% is no way near say, another colleagues' level who's simply stronger technically.
Factor in any degree of NT tendency, and one person's 80 is anothers' 120.
This goes beyond work. A self made friend told me "if you are always working when will you have time to make money?" We all need free mental space to think.
This sounds a lot like being on call. If you like that kind of work, why not be an SRE instead? Maybe there also need to be people “on call” for responding to other kinds of events, though?
It also sounds a lot like getting pulled into meetings. People complain about it, but sometimes that’s the job.
I've argued the same for 30+ years. Having some slack is healthy so that teams can be simultaneously proactive and reactive to issues. Even the best athletes do not train or compete 24/7.
If you're being treated poorly and it's causing you stress, leave.
It's going to take time to earn trust from peers and your manager to start getting more meatier work. If you're early career, I think 2 years is a good guideline. Many places hiring someone for their second job will expect you to be leaving your first job around 2-ish years. 2 years gives you the chance to take on larger projects and see the results of your work and get feedback about things you've pushed to production.
You probably shouldn't stay at your first job more than 3 or 4 years. The second job change is the hardest. It's when you realize that different companies do and value things differently. Staying too long at your first job will make it tougher to adjust. It's also good to get exposure to new ways of working while you're still agile enough to soak it up.
If you've left more than 2 or 3 jobs within 2 years it starts to look like a red flag.
If you're still learning or giving opportunities to learn new things, stick it out. If you're stagnating and not allowed to learn new things, it's time to leave.
For the first 10 years or so, this is relevant. After that you can figure out what you really want to do.
Yes, the old rule is you are either earning or learning, if you are not doing either you should be out.
Early career pick learning and exposure to different technologies, processes, and company organizations.
That being said, this job market is pretty bad for the youngins so unless you are top 1% of noobs I would say focusing on stability and learning would be my north stars in the next 3 years.
You sort of do; stop doing work above a certain volume, stop meeting deadlines. This will have consequences, which may include a) firing or b) better volume and deadlines, depending on a number of factors.
I've worked roles where our priorities shift with the wind. Many times it is for good reason, like a strategic customer to get a foothold in a market. Other times it is just because management hyped up some effort. All's this to say, nod saying you will do it then just go about your day doing focusing on the actual priorities. Don't let workload mount up bc deadlines are all made up.
Most software engineers in my experience have quite a lot of control, and a large component of growing in your career is learning to perceive the control that you have.
One common misconception the article touches on, for example, is that Jira tickets represent latent task assignments, such that you should always be working on some specific Jira ticket and immediately pick up a new one when you finish or are awaiting review on the last one. That's not how the most successful engineers work, and often it's not even really what management wants.
> Most software engineers in my experience have quite a lot of control, and a large component of growing in your career is learning to perceive the control that you have.
I've found that most of that autonomy comes with trust, and that trust gets unlocked via good relationships, and good relationships get unlocked by a history of good communication.
You are 100% correct that every person has agency, the trick is to get yourself into a social dynamic where it is acceptable to assert it.
Picking up Jira tickets could be a good way to accomplish the other goals. Suppose the ticket has a request from a user you don't chat with, it's a good time to go chat with them. Maybe you don't understand a part of the code base. Looking into a Jira ticket related to that part gives you a reason to read through it. If there's lots of tickets related to a subsystem, you might have a conversation with the product owner about what direction they're taking it. What you might not want to do is accept responsibility for the ticket until it's time to actually hammer it out.
Business will take everything you give. Theyre bean counters will be always calculating when it costs more to hire and onboard a new dev than to let you take your time....
> Are you working under a continuous and immediate threat of dismissal?
Definitely! It's been that way everywhere I've ever worked. Unless you are churning out code at maximum speed then it's only a matter of time before you get fired.
You may not like hearing this - setting boundaries is a skill, and a difficult one to learn. It's also one of the most valuable skills for you, especially you personally, to learn, based on this comment.
When customers that pay you a lot of money demand resolution to issues from your higher ups, you sort of have to. Especially true if their product is not working.
It has to be a really really small place for "you're the only person we can say yes with" to be a fair note on a request. That doesn't mean there aren't plenty of people stuck with such jobs at bigger places, but it doesn't make it any more reasonable an excuse and pretty much still boils down to constant fear of being dismissed if you say no in the end.
It sounds like you could have a little "buffer time" where you "do nothing" to prevent burnout when you need that free time for something that pops up and to take adequate breaks to pace yourself cognitively speaking
Otherwise I don't see why you couldn't do lower value tasks with flexibility to abandon them if something higher value comes up
doing LOTS of nothing can also be a huge power move. i was in software development, technical writing contracting in Silicon Valley back in the 80s. i stepped away to do something completely different for 40 years. curiosity in AI brought me back. the background acquired from my exploration of an apparently unrelated field enabled me to develop some very advanced software concepts relevant to the problems with AI, and implement them in working code.
Also applies to research. Keep leeway to open yourself up for collaborations and you might score lots of easy wins even as you struggle with your 'main' project (it also makes you a more well-rounded, sociable scientist)
> I also believe that being too helpful leaves you vulnerable to predators. Tech companies are full of people who want to extract uncompensated work from software engineers4. This is different from work that arrives via normal channels, and for which you’re compensated by promotions, bonuses (and just your normal salary). I’m talking about work that arrives via backchannels, from people who don’t have the ability or willingness to ensure that work is formally recorded under your name. For instance, a product manager from another organization messaging you to say “you’re so good at querying data, would you mind pulling some statistics for me about X?”, or an engineer from another team asking you to “pair” on a piece of work that will ultimately involve you writing all the code and them quietly submitting the change under their own name.
Put this in a frame.
I’ve had a half-written blog post in this vein for a while now using a fantasy RPG analogy: if you play a character that uses mana in any of these games, you’ll learn fairly quickly that using it all up all the time on trivial battles and running around empty leaves you with none when you genuinely need it.
Your mental energy deployed at work is not so dissimilar: keeping some in the tank gives you the option to deploy it strategically, rather than risking your health (burnout) when something unexpected comes up.
If you join a group in one of these games with a player who is bad at managing their mana, you’ll also find that they’re not such great teammates, either.
One thing I've noticed myself, if you are not sufficiently challenged for a while it can be extremely difficult to surmount the next challenge. Peak "abilities" for me in whatever categories has always been when I had enough work in front of me to just chug away like a machine, and enough trust where I didn't need to stop and constantly explain myself but could just work uninterrupted towards the goal. Skills would grow like wildfire and tasks would be completed sooner than expected.
Unfortunately very few jobs are structured to take advantage of that. So many blockers and distractions from you getting into actual deep work.
> Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts.
Not to be sarcastic but just to offer an observation: in a sufficiently large or bureaucratic organization, preventing an incident from happening can rarely get you any credit or visibility. Such achievement falls into the bucket of "what you're supposed to do". So, those who navigate company dynamics well would rather let the incident happen and then be loud on the follow-up action items. The trick is not to turn an incident into a diaster, so it's a dedicate act.
Also, disaster is a good signal to the higher ups that there are problems in your org. If you keep putting out every fire with heroics, your boss will know (maybe), but his boss's boss's boss will see that your org is doing great and everything is all code green.
If you let a few things burn down, your boss's boss's boss will notice the fire, and things may improve. It's perhaps the easiest way you have of communicating with them.
The examples of high impact all seem like things unlikely to receive recognition.
If you save a sales deal, they'll cheer the sales staff. And pay them a commission, which you will receive no part of.
And start to build a relationship with sales that, at least in a B2B firm, can be of significant benefit.
I learned this early in a conservative org. Preventing things is risky. Just keep the solution ready for when things go wrong because then you'll get approval.
Never waste the opportunity a good crisis presents
If you want to collapse just run a system at 100% for baseline, there's no slack, there's no capacity to meet new demands, you're just running a permanent failure mode if there's any perturbation in the system.
Efficiency is the enemy of resiliency.
Except ... the collapse never happens. Once your engineers burn out or age out you just hire fresh meat and the cycle repeats. The issue I have with these types of articles (and books like Peopleware / Slack) is they never provide any actual metrics that may convince the beancounters to try a different approach.
The metaphor that changed my perspective came from the book, "The Power of Full Engagement", paraphrasing "you're behaving as if you're a world-class endurance athlete without an off season - stop it."
Tom DeMarco had a whole book about this approach: https://www.penguinrandomhouse.com/books/39276/slack-by-tom-...
fantastic book.
Haha that's me right now, I'm enjoying it, I used to be gung ho wanting to be somebody but now it's fun coasting
I've been focused on going out/socializing more which is unfortunately distracting me in life, all I can think about is going out getting laid
There's a lot of wisdom in this. In addition to reserving some capacity for when true high-value work comes along, I think software engineering is not the type of job that you can do well if you're constantly busy. Trying to write some code as quickly as possible seldom yields the best design. This article doesn't get into another important aspect of this, which is how to get away with working at 80% capacity without getting in trouble with your manager. This takes a bit of care around communication and estimation of work. One of the first good pieces of advice that I got from older seasoned developers when I started my first real programming job has stayed with me to this day: take your estimate of how long it will take to do something and double it before communicating to your manager/users. As you get more experienced that ratio can come down to maybe 1.5x instead of 2x, but the principle still applies.
Kent Beck (maybe in Good News Factory but also in talks) that his team would never commit to more than half what they think they can get done. This is a good way to sustainability. And that's the optimization and precedent to set; that we are here for the long term, delivering steadily at a sustainable pace. It's a long game, and over promising only runs down trust, which is your biggest means too getting the space we need as Devs. Under promise, build trust that we can do what we say, earn the space we need to not burn out. Honestly the more senior I get (Lead), boundary setting and preserving my attention; not burning out, _is_ the job. Because there are myriad ways to do this to yourself.
Yep, if you want to run a sustainable business you don't look to fire on all cylinders all the time, but that's the rub, almost no owners are looking to run a sustainable business anymore.
Most people either want hypergrowth idiocy or to be bought by the people doing hypergrowth idiocy.
Setting consistent expectations means you can plan, you can actually reasonably budget, you can have predictability in your business dealings - if you are trying to run a good business these are all real features instead of "puts out more code that might or might not make us money, but at least we were pulling all nighters and adding perceived meaning to our lives!"
Sigh. This article is obviously completely correct, but I don't think the people who actually need to read it will care.
Running anything at constant 100% utilization means you are going to be working in crisis mode all of the time. Even in factory labor, the Toyota Way is several decades old now, and it involves making sure everyone has at least a little breathing room to step back and think about what they're doing. And obviously this is even more important for "knowledge workers" or anyone whose output requires any amount of creativity.
High functioning organizations have a good (not too much, but not too little) amount of slack in their work pipelines. Pretty sure there is not a single person with an MBA (or, lol, any consultants) that knows this anymore.
I've been "Doing nothing" at work for a couple of weeks now, and it's freaking me out. Yes, I have asked for tasking, but the guy in charge is ... I just don't know.
Could you fix some bugs? Please?
Why? The moment you touch the code you become responsible for it. Can't count how many times I fixed something on a goodwill and then became responsible for it.
The testers have the latest build, and have not reported any bugs. I don't even know if the project I am working on is even going to be funded after a few more months. I am just in this sort of limbo that really sucks.
It's a good practice to run at 80% utilization and it helps if you are not being managed by people with an overseer mentality, who demand 100% from you all day, everyday. They are the ones who misinterpret the look of software engineers working in relaxed silent repose as lazy idleness. That's why remote work is the best thing to allow me to keep some utilization in reserve and to keep my sanity.
Doing a little bit of "glue work" can make you indispensable and also a hero to your team if it makes everyone's work life a whole lot better and no one else knows how to do it.
I'd argue 80% is high. This also varies between Devs. The way I learn, think about things, struggle to get started etc, means my 80% is no way near say, another colleagues' level who's simply stronger technically. Factor in any degree of NT tendency, and one person's 80 is anothers' 120.
This goes beyond work. A self made friend told me "if you are always working when will you have time to make money?" We all need free mental space to think.
This sounds a lot like being on call. If you like that kind of work, why not be an SRE instead? Maybe there also need to be people “on call” for responding to other kinds of events, though?
It also sounds a lot like getting pulled into meetings. People complain about it, but sometimes that’s the job.
I've argued the same for 30+ years. Having some slack is healthy so that teams can be simultaneously proactive and reactive to issues. Even the best athletes do not train or compete 24/7.
Thank you for this. I'm new to SWE. How to know when it is time to leave an organization versus sticking it out?
If you're being treated poorly and it's causing you stress, leave.
It's going to take time to earn trust from peers and your manager to start getting more meatier work. If you're early career, I think 2 years is a good guideline. Many places hiring someone for their second job will expect you to be leaving your first job around 2-ish years. 2 years gives you the chance to take on larger projects and see the results of your work and get feedback about things you've pushed to production.
You probably shouldn't stay at your first job more than 3 or 4 years. The second job change is the hardest. It's when you realize that different companies do and value things differently. Staying too long at your first job will make it tougher to adjust. It's also good to get exposure to new ways of working while you're still agile enough to soak it up.
If you've left more than 2 or 3 jobs within 2 years it starts to look like a red flag.
If you're still learning or giving opportunities to learn new things, stick it out. If you're stagnating and not allowed to learn new things, it's time to leave.
For the first 10 years or so, this is relevant. After that you can figure out what you really want to do.
Yes, the old rule is you are either earning or learning, if you are not doing either you should be out.
Early career pick learning and exposure to different technologies, processes, and company organizations.
That being said, this job market is pretty bad for the youngins so unless you are top 1% of noobs I would say focusing on stability and learning would be my north stars in the next 3 years.
So many factors are envolved in this that it is hard to begin the answer. I would spend some time discovering the main points and answer them.
One that is very important: Do you have another opportunity to accept? There is nothing better to get a job than being employed.
If you do have a offer, consider if you take; but if you don't, try to get one while you are employed and jump ship when it's a better one; repeat.
This is written as if you have actual control over the volume of work given to you and/or deadlines.
You sort of do; stop doing work above a certain volume, stop meeting deadlines. This will have consequences, which may include a) firing or b) better volume and deadlines, depending on a number of factors.
Are you working in mines of Uganda? No? Then you do have actual control.
I've worked roles where our priorities shift with the wind. Many times it is for good reason, like a strategic customer to get a foothold in a market. Other times it is just because management hyped up some effort. All's this to say, nod saying you will do it then just go about your day doing focusing on the actual priorities. Don't let workload mount up bc deadlines are all made up.
Most software engineers in my experience have quite a lot of control, and a large component of growing in your career is learning to perceive the control that you have.
One common misconception the article touches on, for example, is that Jira tickets represent latent task assignments, such that you should always be working on some specific Jira ticket and immediately pick up a new one when you finish or are awaiting review on the last one. That's not how the most successful engineers work, and often it's not even really what management wants.
> Most software engineers in my experience have quite a lot of control, and a large component of growing in your career is learning to perceive the control that you have.
I've found that most of that autonomy comes with trust, and that trust gets unlocked via good relationships, and good relationships get unlocked by a history of good communication.
You are 100% correct that every person has agency, the trick is to get yourself into a social dynamic where it is acceptable to assert it.
This was voted down because? I would say after you exceed jr level programming this has been true for the last 20 years of my career.
Aahhh.
Proactive vs reactive
Picking up Jira tickets could be a good way to accomplish the other goals. Suppose the ticket has a request from a user you don't chat with, it's a good time to go chat with them. Maybe you don't understand a part of the code base. Looking into a Jira ticket related to that part gives you a reason to read through it. If there's lots of tickets related to a subsystem, you might have a conversation with the product owner about what direction they're taking it. What you might not want to do is accept responsibility for the ticket until it's time to actually hammer it out.
It's surprising how often people dig their own grave.
You can say no thats too much work load, we're understaffed or its too tight of a timeliness for the results.
But understand the ecosystem. People make promises that arent entirely dependent on them to be able to deliver
If your boss promises something that will take 150% of you capacity for the week does it make any difference whether you put in 80% or 100%?
Business will take everything you give. Theyre bean counters will be always calculating when it costs more to hire and onboard a new dev than to let you take your time....
Your communication with stakeholders about your work ends up having more of an impact than your rate of work output.
Don’t you? You can always say no verbally or with non-delivery. Are you working under a continuous and immediate threat of dismissal?
> Are you working under a continuous and immediate threat of dismissal?
Definitely! It's been that way everywhere I've ever worked. Unless you are churning out code at maximum speed then it's only a matter of time before you get fired.
You may not like hearing this - setting boundaries is a skill, and a difficult one to learn. It's also one of the most valuable skills for you, especially you personally, to learn, based on this comment.
When customers that pay you a lot of money demand resolution to issues from your higher ups, you sort of have to. Especially true if their product is not working.
It has to be a really really small place for "you're the only person we can say yes with" to be a fair note on a request. That doesn't mean there aren't plenty of people stuck with such jobs at bigger places, but it doesn't make it any more reasonable an excuse and pretty much still boils down to constant fear of being dismissed if you say no in the end.
It sounds like you could have a little "buffer time" where you "do nothing" to prevent burnout when you need that free time for something that pops up and to take adequate breaks to pace yourself cognitively speaking
Otherwise I don't see why you couldn't do lower value tasks with flexibility to abandon them if something higher value comes up
doing LOTS of nothing can also be a huge power move. i was in software development, technical writing contracting in Silicon Valley back in the 80s. i stepped away to do something completely different for 40 years. curiosity in AI brought me back. the background acquired from my exploration of an apparently unrelated field enabled me to develop some very advanced software concepts relevant to the problems with AI, and implement them in working code.
Also applies to research. Keep leeway to open yourself up for collaborations and you might score lots of easy wins even as you struggle with your 'main' project (it also makes you a more well-rounded, sociable scientist)