11 ms·

I have worked at both startups and tech companies 40+ years old, and the conclusion I've come to from my anecdata is that every engineer at every company is swa

I have worked at both startups and tech companies 40+ years old, and the conclusion I've come to from my anecdata is that every engineer at every company is swamped all the time. Feature requests and bug reports are easy. Writing features and fixing bugs is hard. Your todo list will always grow faster than you can tackle items. Once a senior engineer retired, and I inherited about a hundred of his bugs out of the 600 or so he left behind. It's a marathon, not a sprint. Working at a consistent pace is better than burning yourself out. The work is omnipresent. It will never stop growing. It will consume all if you let it. Unless you're at an early-stage startup, let your manager deal with your giant and ever-growing todo list. Let someone more plugged-in to the business side deal with prioritizing, and focus on technical excellence. Unless you aspire to management yourself, that's already plenty to do. Anyone who tells you every engineer needs to be in touch with every business concern either only works on early-stage projects or is part of a hustle culture that I don't ascribe to. I don't have the energy for technical excellence and knowing everything about the business.

insightcheck 4y ago
My worry is that you can be technically excellent and fantastic at what you are assigned, only to find later on that the project you've been toiling over has been cancelled or valued far less than another team's work. I appreciate your experienced perspective greatly and it encouraged reflection (I agree with working at a consistent pace), but I believe there can also be a middle ground to have awareness of business concerns to understand when to switch teams or even companies. It's painful to work very hard at assigned tasks, only to find it wasn't valued due to business priorities.
- VyseofArcadia 4y ago
  Yeah that happens. More than once I've thrown away a lot of work due to a shift in priorities. The thing to realize is that as an engineer you have very little control here. All you really can do is argue with higher-ups (they likely won't listen) or job hop (you can't do that too often). It's sort of like making a movie. You start out with more material than what you need for the finished product because sometimes you don't know what's going to work ahead of time. Yeah, it sucks when you project gets left on the cutting room floor, but it happens. There's plenty more work to do. It might sound cynical, but don't get attached. In terms of a middle ground, I sort of think about business concerns the same way I think about the news. Be aware, but don't worry, because you don't have much control anyway. If something really important comes around, start preparing to do what you can with what little control you do have (job hop, move out of a place that's about to be a war zone, etc). Don't waste your finite time and attention on day-to-day details. Save it for the big stuff.
  - hiptobecubic 4y ago
    The problem is that most places reward you based on "impact" somehow, not "impact had we not given you such a bad roadmap to follow," so being unplugged from the business side is rolling the dice w.r.t. future recognition of your work, no matter how well you did
    - aahortwwy 4y ago
      Not all places do this; the place I currently work only rewards leaders for "impact" and people have the option of whether to take on leadership responsibilities. Places that reward non-leaders for impact are doing so intentionally to encourage people to self-organize into teams that produce the most value for the business. The theory being that the people on the ground often have a clearer view of whether value is being created than the various layers of middle management do. If you work in a place like this it's actually part of your job to stay plugged in to the business side and determine whether you're working on something valuable or not.
Aloha 4y ago
I've learned as a matter of survival to abstract availability for more tasks from my actual capacity. If I don't do this I'm given more work than I can do because I have capacity right now then once I have added tasks invariably later everything comes home to roost at the same time.
- tra3 4y ago
  Can you share how you do that?
rjh29 4y ago
You assume that developers don't know how to pad out their todo list, or complete things quickly and then do other things during work time. I've seen a lot of anecdata to support both, but obviously people prefer to say "I'm really busy" or "I work hard" over "I only work 2 hours a day".
- VyseofArcadia 4y ago
  My advice is for engineers, not managers. And as an engineer, I'm assuming you already have more than you can do. If your todo list is so short that you can just pad it out like that, well, lucky you. It has always, and I mean always, been the case for me than I have more to do than I have time to do it. I ask my manager what takes priority, and I work on that. I miss some deadlines, but I try to hit the important ones, and that's just how real life works.
Joeri 4y ago
A former coworker went through a stretch where his manager deliberately assigned him insufficient work and refused to let him do anything but assigned tasks, in order to get him to quit, and he said it was the most miserable time of his career. Having more work than you can fill your days with is an ideal state of affairs, because it means you never run out of work. Of course, as you point out, to work like that sustainably it is important to pace yourself, limiting working time. The natural consequence of that is a need for prioritizing the todo list, because not all of it will get done. I say “the” todo list, because if there are multiple they must be merged so it can be determined what tasks come first. It is cumbersome and distracting to do this merging and develop a business understanding of everything landing in an inbox to be able to prioritize it so indeed a natural temptation is to let a manager do this toil, and just follow their cue. The consequence of letting a manager setting priorities is a loss of control. You have to have faith the manager will give the right kind of work in the right amount. I am not a good fit for this approach, so I tend to take control of my todo list by proposing my own projects or seizing opportunities as they pass by. This does require having good relations up and down the org chart and good insights into the nature of the business, so ymmv. Seeing work as finite is imho mistaken. The possible work that can be done in a business is effectively infinite, and an effective business will find the best set of work to do with the resources they have, and an optimal level of resources to do enough work to deliver value, but without breaking the bank.
- codethief 4y ago
  > A former coworker went through a stretch where his manager deliberately assigned him insufficient work and refused to let him do anything but assigned tasks Interesting, even if it weren't to make him quit, in my home country (Germany) this would represent a breach of contract.
- lovich 4y ago
  > Having more work than you can fill your days with is an ideal state of affairs, because it means you never run out of work. I think we have very different approaches to work. I can’t imagine being anything but excited if some asshole boss thought I would quit because he was paying me to do nothing
germinalphrase 4y ago
Does anyone have a good reference on how to prioritize in a structured manner?
- volume 4y ago
  eisenhower matrix and cynefin framework
cm2012 4y ago
For what it's worth, I polled HN a while back and there was a perfect normal distribution on hours worked per day: https://imgur.com/qdSltlM https://imgur.com/qdSltlM. I asked, "How busy are you at work on average?". Poll questions here if you want to see them: https://strawpoll.com/polls/47x15cf1 https://strawpoll.com/polls/47x15cf1. So 25% of people work under 4 hours a day including meetings, 50% work 4-8 hours a day, 25% work more than 8 hours a day. And seniority does not affect this curve.
cactus2093 4y ago
I don't think that's the best advice. There is no hard line between business, product, and technical concerns. There's a lot of gray area. If you want to be great at your job, then understanding the context of business and product decisions will let you make more nuanced technical decisions that support where the business is heading, not just where it's at today. If your manager, and PM, and business POCs that you work with are all excellent, then maybe you can get this context from them. But chances are that at least some of the people around you are fairly mediocre, and part of being great at your job is making things happen in spite less than ideal circumstances. Maybe what I would consider being great at the job is what you would consider unhealthy hustle culture, and that's fine. If you want to just get by and not be exceptional in the role, that's much easier. But in that case, why even focus on technical excellence? You can get by with less. Basically, if you're gonna slack off, then you might as well slack off across the board. If you want to be excellent, then be excellent across the board.
- adhesive_wombat 4y ago
  Fundamentally, I agree. Though you need to draw some boundaries between being aware of customer needs and advocating for them during development (and alloying them with realities in your development environment) and being responsible for all customer satisfaction.
- VyseofArcadia 4y ago
  Frankly I have little interest in being great at my job. It's a job. At the end of the day, I have exactly as much loyalty for the company as they do for me. None. [1] Furthermore, the "rewards" for being great at your job kind of suck, which at most companies is just slowly accruing experience until you get noticed and someone has the bright idea to make you a manager. [2] I want to be great at software engineering. I want to use tech to build things. I see it as coincidence that there's enough overlap between that goal and the company's goal to at least make me good at my job. [1] That's a lie. I wish I had no loyalty to the company, but my personal pride in a job well done unfortunately means I have a non-zero amount of company loyalty. [2] Just happened to me, actually. My stress levels are through the roof, and I didn't even get a raise. Clearly I miscalibrated my job performance.
namaria 4y ago
I never met any person who has not claimed in a professional set to be swamped with work. It's unwise to seem not busy. There is no signal here, just socially acceptable noise.
- treis 4y ago
  Yeah, as developers you usually get to estimate your work so estimate for however much free time you want. This is especially true the older/bigger the company is. Developers with lots of experience working in a specific application can barely tell how long stuff will take. Your EM/PM/Whoever isn't going to know that you're padding time. As long as most of the time you deliver what you say you will when you say you will nobody will catch on or care.
  - VyseofArcadia 4y ago
    Don't I wish. Currently in the middle of a big thing with a director who keeps mandating unrealistic deadlines with zero engineer input.
    - bluefirebrand 4y ago
      When you find yourself in this position, it's time to look for a new job. It will likely never improve
    - treis 4y ago
      This misses the point. Pretty much all businesses are going to want to mandate unrealistic deadlines. Their default stance is to get as much out of the dev team as they think they can get. It doesn't matter because they don't know what a realistic deadline or a realistic amount of work is. The point is that they have no real understanding of time it takes to develop anything. It all comes from what the developers tell them. You have a huge asymmetric information advantage and should be able to use that to limit the amount of work you have to do. To put it bluntly, if you work 45 hours a week now and want to work 40 start padding you estimates by 10%. Nobody is going to know.
jollybean 4y ago
Yes, very good point. That said, Big Co. Engineers should be brought into the big picture of stuff that's happening, and, communicate with Engineers.
elcomet 4y ago
But the underlying reason is that some (most?) bugs are not worth fixing. If they were worth fixing, then managers would hire more engineers and get through the todo list. So engineers might feel swamp but I guess they shouldn't.
shalmanese 4y ago
If you live in a normally distributed universe, then you get ahead by being swamped and incrementally doing more hours of work than someone else. But hopefully most engineers hoping to have an impact live in a power law distributed universe. I tell all my DRs that, at the end of the year, I will evaluate them on their (self-assessed) 3 most impactful things they've done that year with a 60%, 30%, 10% weighting. There's a couple of different ways of optimizing towards that goal, you can try out a lot of little projects and double down on the ones that seem like they're working or you can do a careful analysis and scope out a few things you think will be a big hit. In truth, there's no ability for me to evaluate them to that level of precision, the framework is mainly there to foster two skills I regard as vitally missing: 1. Ruthless prioritization. One of my frequent questions is "does this sound like the 4th most important thing you'll do this year? If so, why are you doing it?". Being able to cut down on the noise and really focus is hard for people, especially when they feel like there isn't a permission structure in place for it to happen. Even with an explicit focus in place, the norms of the workplace make clearing away time for deep thought preciously valuable. 2. Owning of measurement of impact. Being able to measure a thing is, I believe, in many ways more important than doing the thing in the first place. Measuring forces us to ask hard questions that we often skip over: What metrics am I hoping to affect via this project? How does this metric tie into the larger goals of the company? Are we measuring this metric already? If not, how do we start? What change in this metric would count as impactful vs other projects I could be doing?
- azmodeus 4y ago
  Going to try your approach. I think prioritisation and measuring impact are awesome skills to cultivate.
z3t4 4y ago
Stop worry about forgetting about a feature idea, or bug description. If it's any important it will come back to you. Stop writing down bad ideas. Have at most 20 tasks on your todo-list, then order them in importance, and if something else comes in you just drop the least important todo/task. Think of tasks/todos as balls, you only have to juggle those that are made of glass, the other balls will bounce back up. If you have a list of 600 issues, most of them are no longer relevant - the code has changed, or the issue no longer exist. It's not the holy bible. Focus on what needs to be done right now - in order to to achieve your near future goals.

insightcheck 4y ago

My worry is that you can be technically excellent and fantastic at what you are assigned, only to find later on that the project you've been toiling over has been cancelled or valued far less than another team's work. I appreciate your experienced perspective greatly and it encouraged reflection (I agree with working at a consistent pace), but I believe there can also be a middle ground to have awareness of business concerns to understand when to switch teams or even companies. It's painful to work very hard at assigned tasks, only to find it wasn't valued due to business priorities.

VyseofArcadia 4y ago
Yeah that happens. More than once I've thrown away a lot of work due to a shift in priorities. The thing to realize is that as an engineer you have very little control here. All you really can do is argue with higher-ups (they likely won't listen) or job hop (you can't do that too often). It's sort of like making a movie. You start out with more material than what you need for the finished product because sometimes you don't know what's going to work ahead of time. Yeah, it sucks when you project gets left on the cutting room floor, but it happens. There's plenty more work to do. It might sound cynical, but don't get attached. In terms of a middle ground, I sort of think about business concerns the same way I think about the news. Be aware, but don't worry, because you don't have much control anyway. If something really important comes around, start preparing to do what you can with what little control you do have (job hop, move out of a place that's about to be a war zone, etc). Don't waste your finite time and attention on day-to-day details. Save it for the big stuff.
- hiptobecubic 4y ago
  The problem is that most places reward you based on "impact" somehow, not "impact had we not given you such a bad roadmap to follow," so being unplugged from the business side is rolling the dice w.r.t. future recognition of your work, no matter how well you did
  - aahortwwy 4y ago
    Not all places do this; the place I currently work only rewards leaders for "impact" and people have the option of whether to take on leadership responsibilities. Places that reward non-leaders for impact are doing so intentionally to encourage people to self-organize into teams that produce the most value for the business. The theory being that the people on the ground often have a clearer view of whether value is being created than the various layers of middle management do. If you work in a place like this it's actually part of your job to stay plugged in to the business side and determine whether you're working on something valuable or not.

Aloha 4y ago

I've learned as a matter of survival to abstract availability for more tasks from my actual capacity. If I don't do this I'm given more work than I can do because I have capacity right now then once I have added tasks invariably later everything comes home to roost at the same time.

tra3 4y ago
Can you share how you do that?

rjh29 4y ago

You assume that developers don't know how to pad out their todo list, or complete things quickly and then do other things during work time. I've seen a lot of anecdata to support both, but obviously people prefer to say "I'm really busy" or "I work hard" over "I only work 2 hours a day".

VyseofArcadia 4y ago
My advice is for engineers, not managers. And as an engineer, I'm assuming you already have more than you can do. If your todo list is so short that you can just pad it out like that, well, lucky you. It has always, and I mean always, been the case for me than I have more to do than I have time to do it. I ask my manager what takes priority, and I work on that. I miss some deadlines, but I try to hit the important ones, and that's just how real life works.

Joeri 4y ago

A former coworker went through a stretch where his manager deliberately assigned him insufficient work and refused to let him do anything but assigned tasks, in order to get him to quit, and he said it was the most miserable time of his career. Having more work than you can fill your days with is an ideal state of affairs, because it means you never run out of work. Of course, as you point out, to work like that sustainably it is important to pace yourself, limiting working time. The natural consequence of that is a need for prioritizing the todo list, because not all of it will get done. I say “the” todo list, because if there are multiple they must be merged so it can be determined what tasks come first. It is cumbersome and distracting to do this merging and develop a business understanding of everything landing in an inbox to be able to prioritize it so indeed a natural temptation is to let a manager do this toil, and just follow their cue. The consequence of letting a manager setting priorities is a loss of control. You have to have faith the manager will give the right kind of work in the right amount. I am not a good fit for this approach, so I tend to take control of my todo list by proposing my own projects or seizing opportunities as they pass by. This does require having good relations up and down the org chart and good insights into the nature of the business, so ymmv. Seeing work as finite is imho mistaken. The possible work that can be done in a business is effectively infinite, and an effective business will find the best set of work to do with the resources they have, and an optimal level of resources to do enough work to deliver value, but without breaking the bank.

codethief 4y ago
> A former coworker went through a stretch where his manager deliberately assigned him insufficient work and refused to let him do anything but assigned tasks Interesting, even if it weren't to make him quit, in my home country (Germany) this would represent a breach of contract.
lovich 4y ago
> Having more work than you can fill your days with is an ideal state of affairs, because it means you never run out of work. I think we have very different approaches to work. I can’t imagine being anything but excited if some asshole boss thought I would quit because he was paying me to do nothing

germinalphrase 4y ago

Does anyone have a good reference on how to prioritize in a structured manner?

volume 4y ago
eisenhower matrix and cynefin framework

cm2012 4y ago

For what it's worth, I polled HN a while back and there was a perfect normal distribution on hours worked per day: https://imgur.com/qdSltlM https://imgur.com/qdSltlM. I asked, "How busy are you at work on average?". Poll questions here if you want to see them: https://strawpoll.com/polls/47x15cf1 https://strawpoll.com/polls/47x15cf1. So 25% of people work under 4 hours a day including meetings, 50% work 4-8 hours a day, 25% work more than 8 hours a day. And seniority does not affect this curve.

cactus2093 4y ago

I don't think that's the best advice. There is no hard line between business, product, and technical concerns. There's a lot of gray area. If you want to be great at your job, then understanding the context of business and product decisions will let you make more nuanced technical decisions that support where the business is heading, not just where it's at today. If your manager, and PM, and business POCs that you work with are all excellent, then maybe you can get this context from them. But chances are that at least some of the people around you are fairly mediocre, and part of being great at your job is making things happen in spite less than ideal circumstances. Maybe what I would consider being great at the job is what you would consider unhealthy hustle culture, and that's fine. If you want to just get by and not be exceptional in the role, that's much easier. But in that case, why even focus on technical excellence? You can get by with less. Basically, if you're gonna slack off, then you might as well slack off across the board. If you want to be excellent, then be excellent across the board.

adhesive_wombat 4y ago
Fundamentally, I agree. Though you need to draw some boundaries between being aware of customer needs and advocating for them during development (and alloying them with realities in your development environment) and being responsible for all customer satisfaction.
VyseofArcadia 4y ago
Frankly I have little interest in being great at my job. It's a job. At the end of the day, I have exactly as much loyalty for the company as they do for me. None. [1] Furthermore, the "rewards" for being great at your job kind of suck, which at most companies is just slowly accruing experience until you get noticed and someone has the bright idea to make you a manager. [2] I want to be great at software engineering. I want to use tech to build things. I see it as coincidence that there's enough overlap between that goal and the company's goal to at least make me good at my job. [1] That's a lie. I wish I had no loyalty to the company, but my personal pride in a job well done unfortunately means I have a non-zero amount of company loyalty. [2] Just happened to me, actually. My stress levels are through the roof, and I didn't even get a raise. Clearly I miscalibrated my job performance.

namaria 4y ago

I never met any person who has not claimed in a professional set to be swamped with work. It's unwise to seem not busy. There is no signal here, just socially acceptable noise.

treis 4y ago
Yeah, as developers you usually get to estimate your work so estimate for however much free time you want. This is especially true the older/bigger the company is. Developers with lots of experience working in a specific application can barely tell how long stuff will take. Your EM/PM/Whoever isn't going to know that you're padding time. As long as most of the time you deliver what you say you will when you say you will nobody will catch on or care.
- VyseofArcadia 4y ago
  Don't I wish. Currently in the middle of a big thing with a director who keeps mandating unrealistic deadlines with zero engineer input.
  - bluefirebrand 4y ago
    When you find yourself in this position, it's time to look for a new job. It will likely never improve
  - treis 4y ago
    This misses the point. Pretty much all businesses are going to want to mandate unrealistic deadlines. Their default stance is to get as much out of the dev team as they think they can get. It doesn't matter because they don't know what a realistic deadline or a realistic amount of work is. The point is that they have no real understanding of time it takes to develop anything. It all comes from what the developers tell them. You have a huge asymmetric information advantage and should be able to use that to limit the amount of work you have to do. To put it bluntly, if you work 45 hours a week now and want to work 40 start padding you estimates by 10%. Nobody is going to know.

jollybean 4y ago

Yes, very good point. That said, Big Co. Engineers should be brought into the big picture of stuff that's happening, and, communicate with Engineers.

elcomet 4y ago

But the underlying reason is that some (most?) bugs are not worth fixing. If they were worth fixing, then managers would hire more engineers and get through the todo list. So engineers might feel swamp but I guess they shouldn't.

shalmanese 4y ago

If you live in a normally distributed universe, then you get ahead by being swamped and incrementally doing more hours of work than someone else. But hopefully most engineers hoping to have an impact live in a power law distributed universe. I tell all my DRs that, at the end of the year, I will evaluate them on their (self-assessed) 3 most impactful things they've done that year with a 60%, 30%, 10% weighting. There's a couple of different ways of optimizing towards that goal, you can try out a lot of little projects and double down on the ones that seem like they're working or you can do a careful analysis and scope out a few things you think will be a big hit. In truth, there's no ability for me to evaluate them to that level of precision, the framework is mainly there to foster two skills I regard as vitally missing: 1. Ruthless prioritization. One of my frequent questions is "does this sound like the 4th most important thing you'll do this year? If so, why are you doing it?". Being able to cut down on the noise and really focus is hard for people, especially when they feel like there isn't a permission structure in place for it to happen. Even with an explicit focus in place, the norms of the workplace make clearing away time for deep thought preciously valuable. 2. Owning of measurement of impact. Being able to measure a thing is, I believe, in many ways more important than doing the thing in the first place. Measuring forces us to ask hard questions that we often skip over: What metrics am I hoping to affect via this project? How does this metric tie into the larger goals of the company? Are we measuring this metric already? If not, how do we start? What change in this metric would count as impactful vs other projects I could be doing?

azmodeus 4y ago
Going to try your approach. I think prioritisation and measuring impact are awesome skills to cultivate.

z3t4 4y ago

Stop worry about forgetting about a feature idea, or bug description. If it's any important it will come back to you. Stop writing down bad ideas. Have at most 20 tasks on your todo-list, then order them in importance, and if something else comes in you just drop the least important todo/task. Think of tasks/todos as balls, you only have to juggle those that are made of glass, the other balls will bounce back up. If you have a list of 600 issues, most of them are no longer relevant - the code has changed, or the issue no longer exist. It's not the holy bible. Focus on what needs to be done right now - in order to to achieve your near future goals.