Distractions Cause Bad Code | Hacker News Reader

Distractions Cause Bad Code

ntietz.com

89 pointsntietz47 comments

I'm finding as I get older I'm tolerating distractions less and less, or rather as the distractions come, I find them even more frustrating as the years go on.

I know how well I can work when I have one thing to concentrate on for a period of time, and how badly I can work when there are eight different concurrent projects with questions coming in through slack throughout the day.

It is quite a challenge to try to flow through. I meditate and this helps to create some mental space but that doesn't (for me) mitigate the distractions that much.

I hear you. I am frustrated with distractions more than the next person. I am the person who has received on performance reviews, on multiple occasions, this exact phrase on more than one occasion: "becomes noticeably upset when distracted"

I don't know if this is necessarily "dealing with it" root cause wise, but the stoic approach is what is helping me. I cant' change other people. I can't make other people have consideration for my me or others. I can only control what I can control: how I react, and what I can do to limit the distractions and noise.

Most of that building frustration comes usually comes from myself telling myself things with the word "should" in it, like "it shouldn't be so hard to focus at work", "they should know that distracting an engineer is basically like lighting money on fire", "they should be more considerate", or "I shouldn't have to wear earplugs and headphones to be able to concentrate" etc etc. I dropped all the "shoulds" and just focus on what I can do.

It's not a solution, but it's helping me at least get a little more work done.

I find quotes of the stoics of old especially helpful, especially Marcus Aurelius,

"Choose not to be harmed — and you won’t feel harmed. Don’t feel harmed — and you haven’t been." -- in my case "choose not to be distracted, and you won't be"

To throttle the interruptions from people who "just stop by to ask a question", sound out your boss on the idea of fixed "question desk" hours for the group, say just after lunch. Self-schedule all your shallow-thought tasks into that time slot -- expense and status reports, maybe code reviews.

Kill the two ugly birds with one stone :-}

Tried it -- we did "office hours"

What ended up happening is this, multiple times a day,

"Hey, I know it's outside of office hours, but..."

You need to chat with your boss about enforcement means. Two options for an answer to violators: 1. "Send e-mail or come back during office hours" 2. "Talk to my boss"

If you instead yield to the pressure and make an exception, then: a) You'll be inflaming your own sense of aggrieved anger, and b) It'll keep happening.

I never understood why I am I crammed into the same room with social media/sales/business planner/project management and whatnot people when they don't do any productive work (or any work for that matter) instead they just keep yelling nonsense the whole day over my head. Sometimes they are so loud that even when I turn up the volume in my earphones painfully loud, I can still hear them.

And why would I have to listen to any music to begin with just to get my work done??? I am so pissed each and every day when I clock out and through no fault of my own I can't finish my work. Infuriating situation. Seriously.

I’ve gotten to the point where I accept it as my bosses loss that I’m unable to work as effectively as I otherwise could, if I’m in a situation like that and can’t get out and I’m clear with them about it. If they give me flak for being unproductive in an unproductive environment then I leave, as I count that as a hostile environment (in the same vein as not being given the tools or information I need to do my work). Luckily for me, I’ve had reasonable bosses in my last few jobs and have had the option to work from home (although time in the office has still been in an open plan space).

With all the above, would you share how long on the average do you stay at one job?

You should be able to filter for this before you take a job. Just remember that it comes at a compromise - you will miss out on opportunities that are "better, but..."

You should, yes, but it seems as though open plan offices and the trappings are close to 100% in some areas. Remote jobs now seem to be the main alternative, but not everyone loves that setup (especially those who want to keep the work/home distinction super-clear).

My last two jobs were two years and one year. I only left the first because I was offered a team lead position working in technologies that I care enough about to run the local meet ups for, and the other I left only because the work I ended up doing was very different from what I was hired to do (ie I ended up doing rather little of the tech I was hired for), if I’d went into it knowing that, I’d have been a lot happier doing it, although I would have stayed in the first job then.

Before that, I founded two failed startups one after the other, so those were out of the ordinary jobs.

So, recent jobs, not very long, but the reasons I left were not because of noise related lack of focus. I try to be pretty open and direct with my bosses about what my plans or needs are and what I can offer given the environment I’m in.

"I get more done in 2 or 3 hours on an airplane, than I get done in 2 or 3 days at the office." -Brian Tracy

Flow, and creating the environment that allows devs to achieve it, is a major theme of Peopleware. Probably the central theme. So while it's always good to draw attention to the problem, the problem and its solutions are not breaking news.

As for a model for getting both management and devs on the same page for solving the problem, I always like the example presented by Paul O'Neill's safety-first campaign at Alcoa:

http://www.post-gazette.com/business/businessnews/2012/05/13...

Tackle these seemingly middling but pervasive issues, both sides will see benefits and the whole company culture will probably transform for the better.

Of course, if you have the type of management that would read that article and meditate on its deep implications for their software development operation, then you probably aren't dealing with these types of issues in the first place.

Does anyone else feels like human distractions are worse than other distractions? I mean that if I read an article while something is compiling, I can switch back immediately when the compilation is done, while talking so someone provoke a way bigger context switch.

I feel like it's the origin of the context switch that changes a bit the things.

For me the single most distracting thing from deep work is people talking in an open office especially loudly like a conference call on speaker.

HN and whatnot can be contained. Noise-cancelling headphones, turned way up, with some sort of non-lyrical music playing only does so much. Sometimes I move away to quieter parts of the office in spaces like call booths to do deep work.

To me it feels more complicated: sometimes I can tune out discussions and sometimes I can't.

Discussions that are peripherally related to something you’re working on can be dramatically worse than something random. Hence people who can work in coffee shops but not open-plan offices.

Very similar to the issue I suffer from. If I overhear co-workers discussing a problem within my domain, my brain just goes right on ahead without me and starts chipping away at it. After a few minutes I might find myself staring blankly at a screen full of code while my brain is somewhere else entirely.

There is an interesting similarity here with gear-up landings of airplanes. You can group most of those events into 3 categories:

    54% - Pilot forgot to deploy
    30% - Landing gear malfunctioned (mostly poor maintenance)
    15% - Landing forces exceed stress limits

In the majority of cases in the 1st group, distractions are cited.

https://www.youtube.com/watch?v=B9ot2YxPHdE&t=443s

I wonder how many of my bugs have to do with HN?

I helped a non-programmer coworker with an Excel macro a while back. After working out the details on their own, the coworker told me I needed to be in an office by myself. After fighting through a little bit of VBA code, they couldn't see how I could get anything done with all of the open-office distractions. Maybe we need to get all of the decision-makers that come up with open offices to sit and write Excel macros for a day.

At the current gig, we're stuck in an open office setup that is a thoroughfare between the warehouse, marketing, another dev bullpen, and sales.

The main AC unit (the size of a mid sized Kia) is directly above my head making sure that this place feels like a damn meat freezer every day.

The things you endure for clients.

Nice to see you posting here Nick, I don't think we've seen each other for about 7 years now; last time being the CS building at KSU.

> you have to talk to users... that should be done on your schedule, not on theirs (most of the time) so that when you are done talking to them and you have a good idea of what to build, you can go crank out a high quality first version.

I pretty vehemently disagree with this. Your users are pretty much priority #1. That doesn't at all mean "keep your phone on at night so you can respond immediately", but you should be as accommodating as possible (within reason) to your users.

> This version will be on the right track, technically: good architecture, usable performance, well-tested, with minimal bugs. This is a first iteration you can go take to users to get concrete feedback and keep iterating.

Most of the time your first version should probably just be essentially tossed. Sinking a bunch of time into it inevitably results in feelings of sunk costs that means you're focused more on "how can we tweak this solution to sorta solve the problem" than "is this fundamentally the right solution to the problem?"

Well, all programming problems become trivially simple if one is allowed to ignore the users. Just develop your own requirements, and they'll be happy with what they get!

Might not be the best choice career-wise, but that sounds like a business problem, not a technical problem.

I think that is not always true and stepping back could be a benefit sometimes. There were moments when I had to get back to my code and I realized that it could be done in a better/more simple way. Distractions force me to write code in a way such that I can switch back to it very easily.

But a twist is that I really hate it when I am being distracted. :)

Why not "Distractions cause bad work". Why do people assume these types of articles are unique to programming?

Its an anecdotal article, the author doesn't have to apply their experiences to all domains.

For a broader/scientific article on open space related distractions https://www.washingtonpost.com/business/2018/07/18/open-offi...

One of the studies mentioned in that article argues that in an open office, individuals use more electronic communications, fewer face to face communication. Arguably that's fewer distractions, not more.

> Arguably that's fewer distractions

I'd argue that you're wrong. What's the difference between getting distracted by a physical interruption or an electronic interruption?

One's physical and one's electronic. They're both still distractions.

Admittedly, it depends on your configurations (edit: and social norms where you work). But email and Slack are both potentially asynchronous. A coworker talking is not.

The notification GUI opening up in front of the element you was going to click isn't any asynchronous.

I said "depending on your configurations". I have email set to pop up on my phone every 30 minutes. I have slack set to never send me a notification except for an @here or direct reply to me. These settings work decently for my current role.

The one major hole is that the slack icon shows a red dot whenever I use ⌘-tab to switch apps, and the red dot appears on non-essential slacks that I'd rather not read so frequently.

I'm aware that some people have unreasonable bosses who freak out when emails aren't answered faster. But clueless bosses will be clueless in any medium.

I think programming is definitely more prone to have bad problems with distractions. Some problems may take days, weeks or months of focused work to develop a mental model. I think a lot of other functions don't require this long time focus. They are done in smaller chunks.

More prone than what? Actuaries updating excel spreadsheets? Engineers doing CAD work. Woodworkers making a cupboard?

The scope of "a lot of other functions" seems very limited.

Marketing people working on strategies, sales people making phone calls, managers planning something, maintenance people replacing something. Lots more.

My phone is permanently on silent mode, and I have revoked push notifications for almost every social media app. No distractions during work day at all.

Same here. Permanent silent mode (quarter moon icon on Apple, volume switch off). Have done this over the last 2 years. I spoke to an old friend recently on the phone, it had literally been months since my last phone conversation. It takes an effort to unplug but it’s hard to go back once you do.

Distractions doesn't cause bad code, poor system design experience causes bad code. Programming is like any activity, once you're good at it, you can do it while doing other things. You can code while listening to music, watching a movie, talking on the phone. Provided you know what you're doing. If you have poor system design experience and have no framework for your current task, and you're pretty much experimenting, then you will easily fail especially when distracted, without noticing you're on the wrong path. However, if you have a unit of work to do, and a known framework to map it to, distraction won't cause you to lose sight of your goal, sure you might have a typo or even an incorrect logical cause, but I argue that those are minor and not bad code but mere and easy to fix mistakes.

Bad code is code that looks like good code, works, but is really bad because of poor design. Begins to show itself for what it is once it's time to modify and maintain it.

Okay, this is probably generalising a little bit but if a programming task doesn’t contain at least some element of “pretty much experimenting”, shouldn’t you be looking at existing tools or libraries?

(The nature of the experimentation varies, and might be more in the domain of design/UX than technology —- but even so...)

Sure that's true if you're a code monkey stamping out CRUD apps all week long, if you're trying to push yourself to the limit. Imagine you're writing an exam in something you really really pushed yourself to learn in a highly competitive field, would you feel your tuition money would have to be well spent if you had to write said exam in an open office solution shared with loud sales people?

This is not true when you are writing code you haven't tried before. It's true for html, Css, devops stuff.

Or if you are trying to come up with an algorithm that is complex. Doing that in open office is impossible for me.

Unless you’re just reproducing a high fidelity mock-up from a designer, HTML/CSS work absolutely can include experimentation. And I’d argue that this is pretty important if you want web apps that are at all pleasant to use.

Well, not to put words in your mouth, but maybe to put words in my bosses mouth, you can say that, “if you were smart, you’d be able to program in a distraction-filled environment, and you can’t (at least not as effectively as otherwise), therefore you must be stupid”. I get that sentiment, and hey, maybe I am just stupid. But I also have an MSCS and a high GPA and two and a half decades of experience. That doesn’t make me smart by any means, but any form of filtering you’re doing on job candidates is one I’m going to pass with flying colors - so you had better be prepared to end up hiring an army of people about as stupid as me.

I think the Ping Pong table is a good idea. You should take a break from time to time and do something physical.

> "But that should be done on your schedule, not on theirs ..."

what happens when they operate on the same process?

Deadlocks.

This article is a pretty good summary of the book "Deep Work" for a programmer.

It's the largest downside with the job. I like programming at home but can't do it in an open office.

I switched to a job where I don't write complex code anymore. Now it's simpler, devops style things that can be done in noisy environments.

Reply on news.ycombinator.com