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 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"
Kill the two ugly birds with one stone :-}
What ended up happening is this, multiple times a day,
"Hey, I know it's outside of office hours, but..."
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.
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.
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.
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:
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.
I feel like it's the origin of the context switch that changes a bit the things.
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.
54% - Pilot forgot to deploy
30% - Landing gear malfunctioned (mostly poor maintenance)
15% - Landing forces exceed stress limits
I wonder how many of my bugs have to do with HN?
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.
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?"
Might not be the best choice career-wise, but that sounds like a business problem, not a technical problem.
But a twist is that I really hate it when I am being distracted. :)
The scope of "a lot of other functions" seems very limited.
For a broader/scientific article on open space related distractions https://www.washingtonpost.com/business/2018/07/18/open-offi...
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.
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.
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.
(The nature of the experimentation varies, and might be more in the domain of design/UX than technology —- but even so...)
Or if you are trying to come up with an algorithm that is complex. Doing that in open office is impossible for me.
what happens when they operate on the same process?
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.