8 ms·

Many people complain about the usual work chaos. I'm also an engineer and I don't get it. For me, having other people come and ask questions is not distraction

by erikb 9y ago

Many people complain about the usual work chaos. I'm also an engineer and I don't get it. For me, having other people come and ask questions is not distraction but an opportunity to help, learn to know their point of view, learn new things. Meetings are a way to influence the direction of the company however small my influence may be. Other people talking can really distract if it's heavily on topic, but usually also enables a little smalltalk 2-3 times each hour, which provides a lot of the otherwise missing social life between Monday Morning and Friday Afternoon. Even the actual development can happen together with one or two other guys, which increases the speed (since what's hard for me is usually easy for one of the colleagues and vice versa) and makes the solutions smarter (you can't just think off something, you need to be able to argue it as well). In my eyes it's really addicting, and I usually get this after-disco/cinema low when the amount of people in office starts to slow down. What's the actual "engineering work" you are trying to do without interacting with people all the time? Edit: I think most answers can be summarized as "When I'm left alone I get into the flow mode, and that's enjoyable". The same way I mostly get it when working together with a colleague on a problem. Both ways may not always be the most productive, but due to producing a good feeling we prefer these. I see, thanks for showing your points of view.

nyrulez 9y ago
Hmm. How about actually building stuff? For most software engineers, thats a very important part of their job/life/happiness. That requires long focus and flow. And in my personal opinion has a great sense of fulfillment attached to it compared to lot of scattered micro impacts. Ultimately you need to learn to balance both otherwise it gets very frustrating.
- grogenaut 9y ago
  Do you have to personally write every single line of code or are you happy when the whole team builds the code?
  - dasmoth 9y ago
    Not the previous poster, but I'd argue that being able to point to something meaningful (doesn't have to be the whole system, but a coherent component) and say "I made that" brings satisfaction that's hard to beat. This seems tricky to reconcile with the "everything is done by a team" model that's currently in vogue.
    - akavel 9y ago
      Also: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-... The above comic strip absolutely perfectly shows what's it about for me. Though I agree there is stuff better done with others (brainstorming, or discussing hard problems where you're stuck; also variants of rubber-duck debugging/designing; I'd say it boosts "breadth" and "lateral thinking"). But for many people there is most certainly also stuff better done alone ("depth" I suppose? often things like analysing interactions between subsystems; or building an algorithm; or reading docs or a paper; researching existing apps/solutions/libs in order to "spreadsheet" their pros & cons; also analysing/designing thread interactions; or debugging, building internal knowledge of a problem - which is also a required step before rubber-ducking, or generally discussing it, is even possible; also arguably maybe reviewing someone else's code).
      - TeMPOraL 9y ago
        +1, this comic strip is perfect. It describes the issue precisely, in a way rarely seen even in best comic strips. Things I have to do fall into two categories - either I immediately know how to approach them, at which point I can code while having conversations and there's little you can do to distract me - or, I don't immediately know how to approach them, at which point I need time alone and in peace to load the whole system into my head and think through appropriate steps, possibly running mental simulations of several solutions in my head. The second kind of work is when I turn into a pretty antisocial person - I don't just avoid conversations, I avoid being in the same room with other people. And frankly, second kind of work is kind of more important. It doesn't take skill to pump out hundreds of lines of code an hour. It takes skill and concentration to write those and only those lines that move the project forward in a way that's maintainable down the road.
- erikb 9y ago
  Yeah, not for me. My experience with building stuff on my own: Very stressful and long winding, a lot of procrastination and unsocial habbits start to creep in after a week, solution is not really valuable to anybody since nobody is familiar with it. The biggest, most used solutions I helped building usually happened when I cooperated with others. The same discussions that happen in your head, just that part of it is coming from another brain.
  - srean 9y ago
    Most of this kind of 'collaboration' that I have seen have fallen in the bikeshedding or superficial variety. Not all work is of this kind. Some require building mental constructs and contexts that are easily derailed and painstaking to reconstruct
squeaky-clean 9y ago
I enjoy helping when people come up to me with legitimate questions, for all the reasons you mention. It feels like half the time, I'm being bugged not for any real reason, but because the person couldn't bother to put some effort in first. For example, I've become known as "the regex guy" at the office. I know regex really well as well as the ins and outs of the regex engines of languages we use. I don't mind when I get called over to help with a tough regex, or optimizing something. But way too often whatever I get interrupted and cross the building just to replace ".*" with ".+" or something equally simple. I usually just type the solution and tell them my copy of Mastering Regular Expressions is on the office bookshelf if they'd like to borrow it, the first chapter should cover all the basics. I'm also very happy to explain the basics of regex to someone in my down time, but very few people have taken me up on that offer.
- positivecomment 9y ago
  Programmer who doesn't know regex is something like a system admin who doesn't know sed.
  - brookside 9y ago
    I do ok.
  - erikb 9y ago
    regex and sed also feels somewhat related. hehe
- GuiA 9y ago
  Well of course people are gonna keep calling on you, you're known as the guy who will cross the building to fix their work for them! What incentive does anyone have to borrow your copy of Mastering Regular Expressions when their problems can be fixed with a simple email to you?
  - lloeki 9y ago
    Sometimes you really have two NOOP choices: 1. Give them a quick answer and point them to the book but they'll never read it and continue to interrupt even if you told them to not interrupt for trivial matters. On and now you're so much of patronizing dork. Back to square one. 2. Don't give them the answer, and point them to the book. Now you're the smartass jerk that doesn't socialize. Plus they won't read the book and invent some crazy solution to get shit done and later when you have to fix the mess the WTF/min ratio goes through the roof. Back to square one. Which leaves you with three possible actions: DealWithIt, RageQuit, or RageFix, only one of them being a long term fix but things don't happen in a vacuum and you're not always in a position to do so.
macNchz 9y ago
> I usually get this after-disco/cinema low when the amount of people in office starts to slow down When the office slows down and things get quieter is when I find myself finally able to get completely focused in on things that require all of my attention. I enjoy meetings, business talk, planning and miscellaneous conversations with coworkers more than (I think) most software developers, but to get any sizable software project done I do best with chunks of a few hours at a time to get into a focused state, get all of the moving parts loaded into my head, then actually write the code/fix the bug etc. My solution to this–in an office that I share with people who talk on the phone–is to show up in the late morning after they've made their morning calls, and leave in the evening a few hours after they leave. This way we overlap in the afternoon, but I get some time with a quiet office where I can really think. Just while writing this comment several conversations happened around me that drew my attention away from what I was writing. When I focused my attention back to the comment, I had to skim what I'd just written to 'reload' my thoughts. At least for me, this 'reloading' process takes a long time when it comes to writing software, despite various tricks I've come up with over the years to help speed it up.
- TeMPOraL 9y ago
  Same here. As described in the schedule I posted elsewhere in this thread, I tend to come to office at 12:00 - 13:00[0]. And I like it quite much. Most of the cow-orkers in my room work ~09:00 - ~17:00, so there's 4-5 hours of overlap in the afternoon, followed by 3 hours of peace when I can focus and get something done. There are days when I do actually manage to come as early as 08:00, and those days I really miss being alone in the room. -- [0] - Had long battles about that with my boss. He gave up after a year, realizing that there's no way to make me come before 10:00 regularly (my sleeping patterns are weird), but I am there when it matters and get the job done.
- aswanson 9y ago
  Yeah that "reloading " process is hard for me as well, which is why I wear headphones. But some people don't respect headphones! They still interrupt with trivial bs, even after you've given them every possible nonverbal clue that you're trying to get shit done!
ntsplnkv2 9y ago
No surprise, some people prefer other methods of work than others. But it isn't black and white. Helping others is fun but I've been on both sides. There are plenty of people who always need help and never put effort in, and are extremely distracting and lower morale. And interactions are not always of the "Hey can you explain this" variety. Sometimes it's your manager worrying about a project and nitpicking every detail and still managing to not know what's going on. Sometimes it's your manager trying to prove he is "technical" despite not being technical at all, and just downplays your work. Yes, I deal with this daily. Sometimes people are just assholes, and HR/management doesn't deal with it because they produce or are too afraid. Something else I deal with daily. And on top of that, sometimes I just don't want to talk to someone about something. I just want to focus and get done what I need to get done.
TeMPOraL 9y ago
> What's the actual "engineering work" you are trying to do without interacting with people all the time? Building systems. Adding features to software. Debugging it. Anything more trivial than generating and wiring classes that someone else designed for you. I guess a lot depends on the kind of work you're doing. In all of the projects I worked on, 90% of work time would be spend on actually doing it, and only 10% on talking about it (and most of that at the beginning, and then at some critical moments in the project). After the design discussions had been concluded and we've settled on appropriate division of labour (critical aspect: modularity, so that people can work in isolation and have to agree only on interfaces), it was mostly individual work. Now don't get me wrong, I love helping others and answering their questions, or sitting with them and figuring stuff out. Just not all the time, and not in the very moment I'm trying to do something cognitively demanding (like redesigning half a dozen subsystems, or carefully weaving in new features requested by the client in a way that doesn't disrupt the rest of the application).
dasmoth 9y ago
I think most answers can be summarized as "When I'm left alone I get into the flow mode, and that's enjoyable". The same way I mostly get it when working together with a colleague on a problem. Both ways may not always be the most productive, but due to producing a good feeling we prefer these. I think it's hard to separate the questions of productivity and satisfaction. It's satisfying because you're being productive, but conversely it's easy to dodge the urge to procrastinate because the results are satisfying. So the two go hand in hand. (And yes, I entirely recognise that for some people the satisfying+productive mode does involve intense, fine-grained collaboration, while for others it doesn't. I've seen both modes work, and don't really see why they shouldn't coexist -- although ideally with walls and doors to keep the noise of the collaborative types at bay!)
bjourne 9y ago
Suppose you are taking a math exam. One about advanced calculus that is really hard and taxing. I'm talking about one of those that is five hours long and there are only three problems in total on the test, so you are expected to spend over an hour on each problem. Would you prefer if a) the environment was quiet and no one was interrupting you. Or b) the environment was noisy and you were constantly interrupted by people talking about how they spent their weekend. To many developers, productive work is like taking a math exam. Therefore we want the same kind of environment (a distraction free one) to do our best work.

by erikb 9y ago

nyrulez 9y ago

Hmm. How about actually building stuff? For most software engineers, thats a very important part of their job/life/happiness. That requires long focus and flow. And in my personal opinion has a great sense of fulfillment attached to it compared to lot of scattered micro impacts. Ultimately you need to learn to balance both otherwise it gets very frustrating.

grogenaut 9y ago
Do you have to personally write every single line of code or are you happy when the whole team builds the code?
- dasmoth 9y ago
  Not the previous poster, but I'd argue that being able to point to something meaningful (doesn't have to be the whole system, but a coherent component) and say "I made that" brings satisfaction that's hard to beat. This seems tricky to reconcile with the "everything is done by a team" model that's currently in vogue.
  - akavel 9y ago
    Also: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/ http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-... The above comic strip absolutely perfectly shows what's it about for me. Though I agree there is stuff better done with others (brainstorming, or discussing hard problems where you're stuck; also variants of rubber-duck debugging/designing; I'd say it boosts "breadth" and "lateral thinking"). But for many people there is most certainly also stuff better done alone ("depth" I suppose? often things like analysing interactions between subsystems; or building an algorithm; or reading docs or a paper; researching existing apps/solutions/libs in order to "spreadsheet" their pros & cons; also analysing/designing thread interactions; or debugging, building internal knowledge of a problem - which is also a required step before rubber-ducking, or generally discussing it, is even possible; also arguably maybe reviewing someone else's code).
    - TeMPOraL 9y ago
      +1, this comic strip is perfect. It describes the issue precisely, in a way rarely seen even in best comic strips. Things I have to do fall into two categories - either I immediately know how to approach them, at which point I can code while having conversations and there's little you can do to distract me - or, I don't immediately know how to approach them, at which point I need time alone and in peace to load the whole system into my head and think through appropriate steps, possibly running mental simulations of several solutions in my head. The second kind of work is when I turn into a pretty antisocial person - I don't just avoid conversations, I avoid being in the same room with other people. And frankly, second kind of work is kind of more important. It doesn't take skill to pump out hundreds of lines of code an hour. It takes skill and concentration to write those and only those lines that move the project forward in a way that's maintainable down the road.
erikb 9y ago
Yeah, not for me. My experience with building stuff on my own: Very stressful and long winding, a lot of procrastination and unsocial habbits start to creep in after a week, solution is not really valuable to anybody since nobody is familiar with it. The biggest, most used solutions I helped building usually happened when I cooperated with others. The same discussions that happen in your head, just that part of it is coming from another brain.
- srean 9y ago
  Most of this kind of 'collaboration' that I have seen have fallen in the bikeshedding or superficial variety. Not all work is of this kind. Some require building mental constructs and contexts that are easily derailed and painstaking to reconstruct

squeaky-clean 9y ago

I enjoy helping when people come up to me with legitimate questions, for all the reasons you mention. It feels like half the time, I'm being bugged not for any real reason, but because the person couldn't bother to put some effort in first. For example, I've become known as "the regex guy" at the office. I know regex really well as well as the ins and outs of the regex engines of languages we use. I don't mind when I get called over to help with a tough regex, or optimizing something. But way too often whatever I get interrupted and cross the building just to replace ".*" with ".+" or something equally simple. I usually just type the solution and tell them my copy of Mastering Regular Expressions is on the office bookshelf if they'd like to borrow it, the first chapter should cover all the basics. I'm also very happy to explain the basics of regex to someone in my down time, but very few people have taken me up on that offer.

positivecomment 9y ago
Programmer who doesn't know regex is something like a system admin who doesn't know sed.
- brookside 9y ago
  I do ok.
- erikb 9y ago
  regex and sed also feels somewhat related. hehe
GuiA 9y ago
Well of course people are gonna keep calling on you, you're known as the guy who will cross the building to fix their work for them! What incentive does anyone have to borrow your copy of Mastering Regular Expressions when their problems can be fixed with a simple email to you?
- lloeki 9y ago
  Sometimes you really have two NOOP choices: 1. Give them a quick answer and point them to the book but they'll never read it and continue to interrupt even if you told them to not interrupt for trivial matters. On and now you're so much of patronizing dork. Back to square one. 2. Don't give them the answer, and point them to the book. Now you're the smartass jerk that doesn't socialize. Plus they won't read the book and invent some crazy solution to get shit done and later when you have to fix the mess the WTF/min ratio goes through the roof. Back to square one. Which leaves you with three possible actions: DealWithIt, RageQuit, or RageFix, only one of them being a long term fix but things don't happen in a vacuum and you're not always in a position to do so.

macNchz 9y ago

> I usually get this after-disco/cinema low when the amount of people in office starts to slow down When the office slows down and things get quieter is when I find myself finally able to get completely focused in on things that require all of my attention. I enjoy meetings, business talk, planning and miscellaneous conversations with coworkers more than (I think) most software developers, but to get any sizable software project done I do best with chunks of a few hours at a time to get into a focused state, get all of the moving parts loaded into my head, then actually write the code/fix the bug etc. My solution to this–in an office that I share with people who talk on the phone–is to show up in the late morning after they've made their morning calls, and leave in the evening a few hours after they leave. This way we overlap in the afternoon, but I get some time with a quiet office where I can really think. Just while writing this comment several conversations happened around me that drew my attention away from what I was writing. When I focused my attention back to the comment, I had to skim what I'd just written to 'reload' my thoughts. At least for me, this 'reloading' process takes a long time when it comes to writing software, despite various tricks I've come up with over the years to help speed it up.

TeMPOraL 9y ago
Same here. As described in the schedule I posted elsewhere in this thread, I tend to come to office at 12:00 - 13:00[0]. And I like it quite much. Most of the cow-orkers in my room work ~09:00 - ~17:00, so there's 4-5 hours of overlap in the afternoon, followed by 3 hours of peace when I can focus and get something done. There are days when I do actually manage to come as early as 08:00, and those days I really miss being alone in the room. -- [0] - Had long battles about that with my boss. He gave up after a year, realizing that there's no way to make me come before 10:00 regularly (my sleeping patterns are weird), but I am there when it matters and get the job done.
aswanson 9y ago
Yeah that "reloading " process is hard for me as well, which is why I wear headphones. But some people don't respect headphones! They still interrupt with trivial bs, even after you've given them every possible nonverbal clue that you're trying to get shit done!

ntsplnkv2 9y ago

No surprise, some people prefer other methods of work than others. But it isn't black and white. Helping others is fun but I've been on both sides. There are plenty of people who always need help and never put effort in, and are extremely distracting and lower morale. And interactions are not always of the "Hey can you explain this" variety. Sometimes it's your manager worrying about a project and nitpicking every detail and still managing to not know what's going on. Sometimes it's your manager trying to prove he is "technical" despite not being technical at all, and just downplays your work. Yes, I deal with this daily. Sometimes people are just assholes, and HR/management doesn't deal with it because they produce or are too afraid. Something else I deal with daily. And on top of that, sometimes I just don't want to talk to someone about something. I just want to focus and get done what I need to get done.

TeMPOraL 9y ago

> What's the actual "engineering work" you are trying to do without interacting with people all the time? Building systems. Adding features to software. Debugging it. Anything more trivial than generating and wiring classes that someone else designed for you. I guess a lot depends on the kind of work you're doing. In all of the projects I worked on, 90% of work time would be spend on actually doing it, and only 10% on talking about it (and most of that at the beginning, and then at some critical moments in the project). After the design discussions had been concluded and we've settled on appropriate division of labour (critical aspect: modularity, so that people can work in isolation and have to agree only on interfaces), it was mostly individual work. Now don't get me wrong, I love helping others and answering their questions, or sitting with them and figuring stuff out. Just not all the time, and not in the very moment I'm trying to do something cognitively demanding (like redesigning half a dozen subsystems, or carefully weaving in new features requested by the client in a way that doesn't disrupt the rest of the application).

dasmoth 9y ago

I think most answers can be summarized as "When I'm left alone I get into the flow mode, and that's enjoyable". The same way I mostly get it when working together with a colleague on a problem. Both ways may not always be the most productive, but due to producing a good feeling we prefer these. I think it's hard to separate the questions of productivity and satisfaction. It's satisfying because you're being productive, but conversely it's easy to dodge the urge to procrastinate because the results are satisfying. So the two go hand in hand. (And yes, I entirely recognise that for some people the satisfying+productive mode does involve intense, fine-grained collaboration, while for others it doesn't. I've seen both modes work, and don't really see why they shouldn't coexist -- although ideally with walls and doors to keep the noise of the collaborative types at bay!)

bjourne 9y ago

Suppose you are taking a math exam. One about advanced calculus that is really hard and taxing. I'm talking about one of those that is five hours long and there are only three problems in total on the test, so you are expected to spend over an hour on each problem. Would you prefer if a) the environment was quiet and no one was interrupting you. Or b) the environment was noisy and you were constantly interrupted by people talking about how they spent their weekend. To many developers, productive work is like taking a math exam. Therefore we want the same kind of environment (a distraction free one) to do our best work.