7 ms·

The ability to work during normal business hours, dealing with interruptions and collaborating with your colleagues, is a skill that every engineer should devel

The ability to work during normal business hours, dealing with interruptions and collaborating with your colleagues, is a skill that every engineer should develop. This skill doesn't come naturally to some people, but it can be developed and it will make you more productive. In particular, develop the ability to enforce encapsulation on your mental model of the program you are working on, so you don't need to keep the entire thing in your head all the time (this will probably make your code better too). This makes it easier to get back into the flow after being interrupted. The most productive engineers I know work during normal business hours, get interrupted constantly because they work on important projects with a lot of stakeholders, and get a lot of work done anyway. That's what 99% of engineers should aspire to. There are very few rockstars like Carmack who are so good that the benefits of their crazy work styles outweigh the drawbacks.

inetknght 7y ago
> That's what 99% of engineers should aspire to. I wholeheartedly disagree. You're trying to force a generation of imagination into a box. That will only destroy the very imagination you need.
- mathgladiator 7y ago
  So, I have a different and more sinister version. My sinister version is yes, yes, please, keep those imaginations in the box so that I may continue to have a monopoly.... whwhahahaahhaa ---- I'm a principal engineer with a fully capable imagination, and I once got the feedback that my creativity was "transcendental"; the reality is that I don't confine myself to schedule, and my only real discipline is using English to describe my thoughts and improve as a writer. I try very hard to get people to think out of the box, but it is really hard because 99% of the work does not require "divine inspiration". Most people gravitate towards this advice because it is most applicable, and it becomes a virtuous cycle for them. However, it creates a vicious cycle of the Pareto distribution where 1% of engineers can actually use their max level of creativity and use the full breadth of computer science.
  - Darkphibre 7y ago
    OMG, resistance to change is so crazy. I've fought for years to get teams to adopt a relatively simple pattern (complete with transition plans to minimize pain). After the change finally happens, everyone talks about how amazing and brilliant it is, and if I ever have big ideas like this "please share them." So, I bring up data quality, and how we need a centralized test architecture! Same. Blank. Stares... and I'm another year in on shifting the needle, while random reports spontaneously stop breaking and we wait for customers to report data outages. Blows my mind.
    - mathgladiator 7y ago
      Oh, and there can be good reasons like inertia. However, it is very human to resist to change since incentives are aligned with status quo. It is a frustrating field to say the least, but at least some companies fail providing opportunities to try again.
- diminoten 7y ago
  What software engineers need to learn is that their skills aren't magic, and they don't need to be coddled to be entirely productive. So many engineers have learned this, that if you can't, you aren't competitive in the field unless you're literally in the top 0.001%, and no, you aren't.
gwbas1c 7y ago
It's a balance. Part of management's responsibility is to keep interruptions under control. If management does nothing so that everyone goes directly to the engineers; management isn't managing. Specifically, this includes making sure that everyone is onboarded so newcomers don't need to go to the more experienced engineers to ask trivial questions. It also includes making sure that processes are defined and agreed on by stakeholders, making sure that people don't bypass the ticketing system, and sometimes reminding certain employees about things like manners.
sweeneyrod 7y ago
Yes, and also most people spend most of their time working on things like CRUD web apps rather than pioneering rendering techniques. Not only does the former not need the intense focus of the latter, but it also does require actually talking to stakeholders. Also, most people have not been described as having "no empathy for other human beings" in a psychiatric evaluation.
deleted 7y ago
[deleted]
emptysongglass 7y ago
Science says you're wrong and not only wrong but this mistaken belief some of these people hold that they can multitask or be interrupted without significant loss of productivity is actually an admission that they are the worst of multitaskers. [1] The mind is single-core. There's no black lotus you can huff or secret technique to master to make it more than one core. And the inertia returning to its task is significant. [1] https://www.npr.org/sections/health-shots/2013/01/24/170160105/if-you-think-youre-good-at-multitasking-you-probably-arent?t=1573504082179 https://www.npr.org/sections/health-shots/2013/01/24/1701601...
- tj-teej 7y ago
  Sure, but most engineers are working for a business and most businesses don't have perfect processes. I think we can say (1) engineering productivity is severely impeded by interruptions and (2) it doesn't hurt to work on skills to help yourself get less impacted by disruptions. You're right there's no secret technique, but documenting your work and thoughts, keeping TODO lists, breaking down large work items into small chunks can all help distractions not ruin your day. But, these are effectively "hacks" and the only way to ensure highest possible productivity is to have processes which prevent engineers from being interrupted
- war1025 7y ago
  It all depends on what you are optimizing for. You can do a lot of work in parallel if you have the correct coroutine architecture. That involves encapsulating information in a way that you can put it down and pick it back up efficiently. An upside of developing this skill is that if you become adept at storing the relevant information, you will be better at handing that information off to another person. Further, absolute productivity at a single task is rarely the most important thing. If it is, then you've reduced yourself to a cog or a worker bee. Taking responsibility for the direction of your work means accepting that you need to be part of the decision-making process, which will lower your absolute productivity, but (done well) will increase your overall effectiveness.
- shados 7y ago
  but if they don't get interrupted, what's the cost of it vs the cost of them actually being interrupted? Did someone else spend a day trying to solve a problem they could have solved in minutes by interrupting the lone genius?
eikenberry 7y ago
> get interrupted constantly because they work on important projects with a lot of stakeholders Are they really OK with this? Constant interruptions is the hallmark of a broken process and usually means the company is a bad employer and the projects are in trouble. I'd guess those "most productive engineers" handle that situation usually by finding new employment.
bonestamp2 7y ago
I agree, some of the best engineers I have worked with do this. On the other hand, I disagree that all engineers are capable of working best like this -- I don't think everyone has the same aptitude for the same things as everyone else.
munchbunny 7y ago
I somewhat disagree. More specifically, as an engineer your ability to collaborate is a big factor in your effectiveness. Even as an IC, you are being paid in part because your experience and skills help the whole team, not just your code. However, it's impossible to get good work done if you don't have contiguous blocks of time to focus. Even if you take great notes and write things down, momentum is definitely a thing. I've adopted the practice of blocking out 2-3 hours at a time on my calendar the morning of, so that they are not available for meetings, which guarantees me quality time to think and work. If people ask, I'm busy. If people ask why I'm at my desk when I'm supposedly busy, it's because I have to block time for quality thinking or no high quality thinking gets done.
erikpukinskis 7y ago
> In particular, develop the ability to enforce encapsulation on your mental model of the program you are working on, so you don't need to keep the entire thing in your head all the time This one is hard, because the company will push you to make the model as complex as your brain can bear, and all of our programming tools are designed to support the most complex program the toolmaker could imagine. And on your resume you want to put the most complex set of capabilities that you could possibly put. And in your mind you want to be the most dangerous programmer you could possibly be. It took me 20 years to realize that there are ~0 problems that necessitate more than an intro-to-programming level of tooling. It took that long because the whole ecosystem around me pushed me away from transparent coding towards grandiose coding. Even now, I can rarely write simple code for hire because my coworkers have installed a veritable AGI of declarative tooling, and not using it is more conspicuous than using it. But I try. You are absolutely right plain (not fancy) code is the ultimate goal.
- diminoten 7y ago
  This. This so fucking hard. The whole point of writing clean code is so I can spin back up on it in 15 minutes instead of the 30 mentioned in the article (or often very much longer). Literally everything I do at my job is in service of this fact, and no one else where I work understands that. :/
afarrell 7y ago
This comment could be greatly improved by some tips on how to do these things. As it stands, this comment sounds like an imperative to merely subject oneself to something and endure the discomfort of it, without any indication that the reader will build any skill. Since changing workflow to something dramatically less-productive is also something that can disrupt a person's healthcare and housing, people are understandably going to be skeptical.
nscalf 7y ago
Naa, this is totally backwards. Organizations should strive to decrease the number of interruptions and be flexible enough to allow people to work in environments that let them thrive. There is no good reason to say people should get used to poor working environments. All of the research shows that interruption doesn’t last for the two minutes someone needed to get a ticket judged as a 3 for the board, it lasts much longer and effectively resets your focus. A good practice for engineers is setting periods of time for non-critical interruptions, like an engineering office hours. Set periods of time on your calendar as “meetings” and disappear into a room to work for an hour, shut off your messengers. The world usually won’t blow up in the hour that you’re gone, but you will be a much happier and more productive engineer. We’re usually pretty effective when we time box things, so these methods have helped me drastically improve my focus.

inetknght 7y ago

> That's what 99% of engineers should aspire to. I wholeheartedly disagree. You're trying to force a generation of imagination into a box. That will only destroy the very imagination you need.

mathgladiator 7y ago
So, I have a different and more sinister version. My sinister version is yes, yes, please, keep those imaginations in the box so that I may continue to have a monopoly.... whwhahahaahhaa ---- I'm a principal engineer with a fully capable imagination, and I once got the feedback that my creativity was "transcendental"; the reality is that I don't confine myself to schedule, and my only real discipline is using English to describe my thoughts and improve as a writer. I try very hard to get people to think out of the box, but it is really hard because 99% of the work does not require "divine inspiration". Most people gravitate towards this advice because it is most applicable, and it becomes a virtuous cycle for them. However, it creates a vicious cycle of the Pareto distribution where 1% of engineers can actually use their max level of creativity and use the full breadth of computer science.
- Darkphibre 7y ago
  OMG, resistance to change is so crazy. I've fought for years to get teams to adopt a relatively simple pattern (complete with transition plans to minimize pain). After the change finally happens, everyone talks about how amazing and brilliant it is, and if I ever have big ideas like this "please share them." So, I bring up data quality, and how we need a centralized test architecture! Same. Blank. Stares... and I'm another year in on shifting the needle, while random reports spontaneously stop breaking and we wait for customers to report data outages. Blows my mind.
  - mathgladiator 7y ago
    Oh, and there can be good reasons like inertia. However, it is very human to resist to change since incentives are aligned with status quo. It is a frustrating field to say the least, but at least some companies fail providing opportunities to try again.
diminoten 7y ago
What software engineers need to learn is that their skills aren't magic, and they don't need to be coddled to be entirely productive. So many engineers have learned this, that if you can't, you aren't competitive in the field unless you're literally in the top 0.001%, and no, you aren't.

gwbas1c 7y ago

It's a balance. Part of management's responsibility is to keep interruptions under control. If management does nothing so that everyone goes directly to the engineers; management isn't managing. Specifically, this includes making sure that everyone is onboarded so newcomers don't need to go to the more experienced engineers to ask trivial questions. It also includes making sure that processes are defined and agreed on by stakeholders, making sure that people don't bypass the ticketing system, and sometimes reminding certain employees about things like manners.

sweeneyrod 7y ago

Yes, and also most people spend most of their time working on things like CRUD web apps rather than pioneering rendering techniques. Not only does the former not need the intense focus of the latter, but it also does require actually talking to stakeholders. Also, most people have not been described as having "no empathy for other human beings" in a psychiatric evaluation.

deleted 7y ago

[deleted]

emptysongglass 7y ago

Science says you're wrong and not only wrong but this mistaken belief some of these people hold that they can multitask or be interrupted without significant loss of productivity is actually an admission that they are the worst of multitaskers. [1] The mind is single-core. There's no black lotus you can huff or secret technique to master to make it more than one core. And the inertia returning to its task is significant. [1] https://www.npr.org/sections/health-shots/2013/01/24/170160105/if-you-think-youre-good-at-multitasking-you-probably-arent?t=1573504082179 https://www.npr.org/sections/health-shots/2013/01/24/1701601...

tj-teej 7y ago
Sure, but most engineers are working for a business and most businesses don't have perfect processes. I think we can say (1) engineering productivity is severely impeded by interruptions and (2) it doesn't hurt to work on skills to help yourself get less impacted by disruptions. You're right there's no secret technique, but documenting your work and thoughts, keeping TODO lists, breaking down large work items into small chunks can all help distractions not ruin your day. But, these are effectively "hacks" and the only way to ensure highest possible productivity is to have processes which prevent engineers from being interrupted
war1025 7y ago
It all depends on what you are optimizing for. You can do a lot of work in parallel if you have the correct coroutine architecture. That involves encapsulating information in a way that you can put it down and pick it back up efficiently. An upside of developing this skill is that if you become adept at storing the relevant information, you will be better at handing that information off to another person. Further, absolute productivity at a single task is rarely the most important thing. If it is, then you've reduced yourself to a cog or a worker bee. Taking responsibility for the direction of your work means accepting that you need to be part of the decision-making process, which will lower your absolute productivity, but (done well) will increase your overall effectiveness.
shados 7y ago
but if they don't get interrupted, what's the cost of it vs the cost of them actually being interrupted? Did someone else spend a day trying to solve a problem they could have solved in minutes by interrupting the lone genius?

eikenberry 7y ago

> get interrupted constantly because they work on important projects with a lot of stakeholders Are they really OK with this? Constant interruptions is the hallmark of a broken process and usually means the company is a bad employer and the projects are in trouble. I'd guess those "most productive engineers" handle that situation usually by finding new employment.

bonestamp2 7y ago

I agree, some of the best engineers I have worked with do this. On the other hand, I disagree that all engineers are capable of working best like this -- I don't think everyone has the same aptitude for the same things as everyone else.

munchbunny 7y ago

I somewhat disagree. More specifically, as an engineer your ability to collaborate is a big factor in your effectiveness. Even as an IC, you are being paid in part because your experience and skills help the whole team, not just your code. However, it's impossible to get good work done if you don't have contiguous blocks of time to focus. Even if you take great notes and write things down, momentum is definitely a thing. I've adopted the practice of blocking out 2-3 hours at a time on my calendar the morning of, so that they are not available for meetings, which guarantees me quality time to think and work. If people ask, I'm busy. If people ask why I'm at my desk when I'm supposedly busy, it's because I have to block time for quality thinking or no high quality thinking gets done.

erikpukinskis 7y ago

> In particular, develop the ability to enforce encapsulation on your mental model of the program you are working on, so you don't need to keep the entire thing in your head all the time This one is hard, because the company will push you to make the model as complex as your brain can bear, and all of our programming tools are designed to support the most complex program the toolmaker could imagine. And on your resume you want to put the most complex set of capabilities that you could possibly put. And in your mind you want to be the most dangerous programmer you could possibly be. It took me 20 years to realize that there are ~0 problems that necessitate more than an intro-to-programming level of tooling. It took that long because the whole ecosystem around me pushed me away from transparent coding towards grandiose coding. Even now, I can rarely write simple code for hire because my coworkers have installed a veritable AGI of declarative tooling, and not using it is more conspicuous than using it. But I try. You are absolutely right plain (not fancy) code is the ultimate goal.

diminoten 7y ago
This. This so fucking hard. The whole point of writing clean code is so I can spin back up on it in 15 minutes instead of the 30 mentioned in the article (or often very much longer). Literally everything I do at my job is in service of this fact, and no one else where I work understands that. :/

afarrell 7y ago

This comment could be greatly improved by some tips on how to do these things. As it stands, this comment sounds like an imperative to merely subject oneself to something and endure the discomfort of it, without any indication that the reader will build any skill. Since changing workflow to something dramatically less-productive is also something that can disrupt a person's healthcare and housing, people are understandably going to be skeptical.

nscalf 7y ago

Naa, this is totally backwards. Organizations should strive to decrease the number of interruptions and be flexible enough to allow people to work in environments that let them thrive. There is no good reason to say people should get used to poor working environments. All of the research shows that interruption doesn’t last for the two minutes someone needed to get a ticket judged as a 3 for the board, it lasts much longer and effectively resets your focus. A good practice for engineers is setting periods of time for non-critical interruptions, like an engineering office hours. Set periods of time on your calendar as “meetings” and disappear into a room to work for an hour, shut off your messengers. The world usually won’t blow up in the hour that you’re gone, but you will be a much happier and more productive engineer. We’re usually pretty effective when we time box things, so these methods have helped me drastically improve my focus.