Hacker News Reader

Comment by twblalock | Hacker News Reader

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.

View on HN

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/1701601...

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

I think you've missed their point. Those engineers are aware of the cost of context switching, and because they plan accordingly they're able to get more done than those who don't

Awareness and planning cannot compensate for the fact that lost productivity is lost productivity.

I tend to agree with you, but I'm compelled by the argument that organizing your productive time in a way that minimizes the impact of context switches will make your programs much better anyways.

There might be a good reason why code developed under extreme focus also tends to be inscrutable to others.

> There might be a good reason why code developed under extreme focus also tends to be inscrutable to others.

Wow. I have never thought about it this way. That's quite a profound insight. Thanks.

On the other hand, extreme focus can and should be used to make a complex algorithm simple. It all depends on the programmer's competency to begin with. If he/she doesn't care or know how to make code readable, it never will be readable despite their level of concentration.

The corollary is true as well. I, as well as many others I imagine, have had to fix and maintain dumpster fires of spaghetti code developed under the standard distraction-filled modern business day.

Distraction doesn't beget good code; instead, a good programmer learns how to be as productive as they can despite the dysfunction of a typical modern business.

I'm writing this under the influence of Deming, but could you be confusing individual productivity with productivity for the whole department, company, country, world?

Any engineer is only as productive as the system she works in, and a system that eschews communication for long periods of solitary work is not, generally, a productive system.

I vaguely remember reading about an old study from one of those telephone companies in the '60s or so about engineering productivity, and they found that the single thing that set the "best" engineers apart from their peers was in how much more they communicated. I haven't been able to find this study, but if someone knows what I'm talking about, please shoot me a link or something.

Was it Hamming's talk?

https://www.cs.virginia.edu/~robins/YouAndYourResearch.html

Might have been! Haven't taken the time to read it yet but it looks very interesting. Thank you irregardless!

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?

This. If you have one person holding everything in their had blocking other engineers who can’t get around then you are just wasting resources.

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.

Just to attempt to explain why the responses to this comment seem all over the place:

'Productivity' is subjective to the business and position. In your 2-person startup, productivity might be shipping CRUD functionality in triplicate and setting up the bones for a larger application. In an enterprise, productivity can simply be not _reducing_ productivity while doing something. A develop and a manager being productive also look very different. I don't think your point and GP's point are mutually exclusive.

> 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.

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. :/

> 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.

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.

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.

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.

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.

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.

> 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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com