Hacker News Reader

I've become a Cal Newport fan and I'd recommend you read at least some of his blog (http://calnewport.com/blog/) or his book (Deep Work) since he'll be able to explain things much better than I can.

In knowledge work, it's important (for most people) to get into deep focus to solve hard problems. Anecdotally I've seen huge gains by setting aside an 1:30 in the morning to WFH completely disconnected and then another 1:30 in the afternoon to hide away from my open work area. It's incorrect to claim that development of soft skills is at odds with the ability to get into a state of deep work with offices and / or working from home.

As for your question about being hard to focus on some work, yes it definitely is. I'd recommend you look into attention residue. In addition, I'm afraid your perception of your own possible output is probably much less than what you're actually capable of because you've learned to live with constant distraction. If you can't go more than an hour without checking email/texts/talking to coworkers/being interrupted, I'd argue that (as a knowledge worker), you're operating well below your capabilities.

Thanks for your comment and advice! It gives me the idea that I should perform a self-study. I can take two weeks "off" and work in complete isolation (during actual engineering time) and compare my productivity to the norm. I expect the difference to be negligible but I am prepared to eat my words if I am wrong.

If anyone else is interested, I can write about this experiment and its results in a few weeks once I'm done with it. Replies here or emailing me will work.

Your HN bio says "DevOps Engineer" - I think that means that you apply software development techniques to tasks that traditionally belong to sysadmins or "IT"?

Note that the article quotes Spolsky talking about "developers" - it's possible your job has a slightly different mix of need-to-concentrate versus need-to-communicate compared to a pure developer making software at Microsoft.

Thanks for asking! Actually, although my official role is DevOps engineer, I spend 90% of my time writing application code. I am part of an engineering team and simply consult the team on operations. This is how we do DevOps at my place of employment. In a nutshell, your thoughts are probably accurate in most cases, but for me, personally, I do software engineering full time.

How productive would you gauge yourself? I find my productivity drops off significantly on days when I have alot of distractions. I suppose I'm being productive in other ways on those days, but sometimes it seems like I've accomplished little.

Over much time, I have learned that my personal feelings about productivity and my actual contribution are wildly different. This is because my sentiment toward work I want to do and my actual work can be different. This really is tangential to the original subject matter, but what I often see is that people feel less productive when the fix a bug than when they ship a feature; they feel less productive when they resolve some service outage rather than when they fix a bug; and they feel less productive when they hold a design review for some operations process improvement than when they resolve some service outage. As this hierarchy descends, I find that "having a discussion with a colleague" is often at the bottom. But in reality, all of these types of work are equally valuable and important. Their literal value may be different, but for an organization to operate, they are all about the same. Sometimes there is no "literal" value -- teaching an intern about git seems like a waste of time, like you're not being productive, but when they eventually get hired and ship a really valuable feature, your work enabled that.

With all of this in mind (and by the way, if your direct manager disagrees with the above statements, I recommend finding a new employer), I consider my productivity to be mostly the same on a day to day basis, with some ebb and flow. This despite interruptions or what my work environment is. I feel this way because of my perception that all types of work are equal, I just spend most of my time doing software engineering work specifically.

Consider the metric for your productivity in terms of value, not sprint points or lines of code or even "number of features shipped." What "value" means to you, your boss, and your organization varies.

This is not about soft skills, at least for me.

This is about the environment often present with any sufficiently large open office. I have been in offices with 26 people in a space probably meant to hold 20. It speaks to a culture of cost cutting over engineer productivity; when even a low amount of tech discussions at a given time end up with 6~ people talking simultaneously constantly. (see comment re: emotional noise being worse than mechanical noise, in a prior sysadmin job I worked in an office next to a transformer room and would go back to that in an instant because if I really needed to focus at least I could shut the door; and the transformer wasn't going to ignore signs of focus like headphones and being heads down to come over tap me on the shoulder and context switch me to something that really doesn't need to be discussed.)

Similarly; not having enough private rooms when they're actually needed for focus work, being placed in rooms with entirely distinct feature teams, and being often shuffled between them.

These are all "non soft skilled" environmental factors that have made working in open offices FAR more unpleasant for me than private offices (By private I include up to 1-2~ other people sharing your literal role)

Let me address your "at a cto role you must handle distraction" comment as well, since while I agree, we are _not_ at the CTO role, and to pretend the nature of our work is even similar is dishonest. Long-term context dependent thought work has an extremely well documented penalty from context switches. The CTO role, as has been described in recent HN threads and elsewhere, is far more of a salesman/face/public mouthpiece than engineer or even a technical role, and these career skills lend themselves to very different traditional environments.

Some great points here. I'm on mobile but will try to respond to them all.

If your open floor plan does not have plenty of huddle rooms or jump in rooms for private conversations, as well as plenty of single-person focus rooms, then you very well may be in this situation where your employer is trying to cram you in too small a space like chickens in a modern day farm. If the space feels cramped you may be suffering. These are important details and my original comment did leave them out. Where I work we have plenty such focus areas, for individuals and groups, and as a courtesy to others we frequently make use of them. Meanwhile the office atmosphere is bright and open and feels like home.

I agree with your statements about a CTO role, completely, and so I suspect that my wording was confusing and insinuates that we disagree; but based on your statement, we do not disagree. To reiterate, I was trying to point out that interruptions will happen, and developing the skills to deal with them is important; simply changing your environment doesn't necessarily develop those skills, which may be equally or more important to your career than completing your next development task. We're all on different paths, and so if your goal is to always, eternally complete the next development task, then my suggestions do not apply to you, and you should work out of a private office, as learning skills such as dealing with interruptions and managing your time are skills less useful.

> For example, if you ever intend to pursue entrepreneurship or aspire to CTO rank, you can expect to be interrupted often.

If you are at CTO rank, your job is not to program. You may still do that at times, or other things that require quiet time, of course. For that, you need "office hours" or "quiet hours." You simply make yourself unavailable and go somewhere you can have uninterrupted time.

If you are trying to be a developer that gets interrupted all the time as a CTO, you are definitely not doing your job right.

If you are at CTO rank and were previously an engineer, then you've already accomplished your goal and know interruptions on a constant basis are part of the job. That was my argument. Your rebuttal is a straw man: I make no claims as to what the role of a CTO is or in what way it differs from a software development role. Simply that, if you are a software developer and have aspirations to become a CTO, you have more skills to develop than technical skills that are only effective in a perfectly isolated setting.

I loathe being in offices. Especially without Windows. I feel castrophobic. I like to work in big open spaces. At the same time I do love my me-time. So I come to work 10.30-11 and leave at 8. Gives me 2-3 hours after everyone leaves. Those are my most productive hours.

Also I love working from coffee shops. It's like you're alone but you have people around. The smell of tea and coffee have something to do with it.

i'd love an office. I do my best work when i pretend i'm a real functioning engineer. This open-concept agile way of working is very frustrating for me.