7 ms·

Coping with context-switching madness

99 points by kreeben 11y ago

drewcrawford 11y ago
I've solved this problem by adapting the algorithm from a journaling filesystem to my real life. http://faq.sealedabstract.com/uninterruptible_programming_supply/ http://faq.sealedabstract.com/uninterruptible_programming_su...
- VaidasC 11y ago
  Interesting technique. But I cannot help to think that it is good mostly for people who are already good (or at least not that bad) at context switching anyways. What I mean is that many people, inherently are more chaotic, and over-structuring their lives is counter productive. It could make productivity constant but overall worse. Thinking about psychology of this, I believe this might be good to "right brained" types, but it would be such a burden for someone who solves problems mainly via extroverted intuition - random thoughts that are generated so quickly and without any structure - you would need to write down something every few seconds basically, forget about actually doing something.
  - Tiksi 11y ago
    I do something similar, and I'm very chaotic, not at all structured. When Im doing something I have my notebook open, if an idea pops into my head I write it down, maybe make a few notes about it, then go back to what I was doing before. Whatever I'm currently working on has a star next to it in the notebook. And once I finish I cross it out (usually). Its not organized like a list, basically just a brain dump. ( Examples of old pages: http://paste.click/VvnUdA http://paste.click/VvnUdA http://paste.click/RZyWLG http://paste.click/RZyWLG http://paste.click/CsVaoa http://paste.click/CsVaoa ) Doing it in a text editor would be just one more thing to get distracted by, and it doesn't really work for the brain-dump/brain-map style, since spatial relations between what I write has significance. This way instead of going off on a tangent I can finish what I'm actually trying to get done, but still keep track of the unrelated ideas/thoughts. Obviously it won't work for everyone, but it's boosted my productivity massively, and I'm the furthest thing from structured and awful at context switching (Well I'm great at switching, its the switching back that I'm bad at :) )
    - Starwatcher2001 11y ago
      I used to write stuff down, but in my case on sheets of paper that got filed with the project. But I kept thinking "Dammit, I know I've met this problem before, what was the solution?". Doing the same note-taking thing, but using the PC instead of paper, makes it searchable. You're right about the mind-map diagrams though.
      - Tiksi 11y ago
        Yeah I have plenty of pages filled with the project. Not having them searchable is a pain, but every time I've tried to use vim for it, it ends up being a bigger distraction than the ideas themselves.
    - dharma1 11y ago
      When do you get to research your unrelated ideas? Do you have a set time of the week for it? Or do you just go through your list one by one as and when you finish the current item?
      - Tiksi 11y ago
        I usually go one by one. They end up in a chain of ideas so I just follow that chain down.
- verytrivial 11y ago
  Huh. I do almost exactly this, but with an always-present vim instance in screen: [ ] reply to comment [x] mention screen [x] what is that other one? -- tmux [x] mention it? -- nope [x] should I produce an example? -- yes, easy [.] demonstrate '.' as current work item [ ] hit reply
jacques_chester 11y ago
I have ADHD and, consequently, task-switching is one of my more problematic quirks. Apart from medication, I've found that pair programming has been an absolute godsend. Having another engineer next to me helps me to keep coming back to the task. We can recreate context quickly through conversation and as one of us fades, the other can jump in. It's also helping me to realise more often when I am launching into a tangent, because those tangents will involve me vocalising the fascinating shiny thing that just popped into my head. That said, the linked post raises a different practice: one story at a time. Context switching should be within the boundaries of a story. If it's too big, break it down. I'm lucky to work for a company (Pivotal Labs) where this is the accepted way of working.
- jwdunne 11y ago
  Great tips, I too am a programmer with ADHD. I have ADHD to thank for my self-education and following career, where by I cannot resist spending hours on things that are highly stimulating, such as the next interesting thing to learn in computing, which is pretty much infinite. The tragedy is that once something is learned or done so many times it becomes routine and boring. It doesn't provide the same mental stimulation. Unfortunately, in most businesses, the types of problems are almost always in the routine category. This I've found is where my attention faulters.
  - VaidasC 11y ago
    At least to me, symptoms you wrote sound totally normal and not necessary ADHD. Of course since nowadays everything that deviates from common character traits is considered ADHD... You could take a look at MBTI character types and find out that this is very normal for some (e.g. INTP).
    - jwdunne 11y ago
      In fairness, what I've written is only a very small facet of the larger set of problems I face on a near daily basis - a lot of which I'd really rather not write about (mostly out of embarrassment, some of which purely because of the massive sense of failure I experience daily). I'm not saying you are one but ADHD deniers tend to dismiss symptoms described in isolation off as "oh this is normal". Without the ability to describe in coherent way how deep the rabbit hole actually goes, many people with ADHD suffer needlessly when trying to seek help. ADHD symptoms are often described as "everybody experiences the symptoms to at least some small degree, perhaps in combination or maybe one alone, but a sufferer is where they experience the majority of the symptoms to a massive degree on a daily basis". In a lot of ways, it DOES look normal. What isn't normal is how extensive the symptoms are and how much of impact they have on daily functioning.
kabouseng 11y ago
To the OP, you are definitely not alone. PG had a good article on the difference between a managers schedule and a programmers schedule [1] (Interrupt driven vs Focus driven). Unfortunately as you become more responsible for the management of your peers and projects, you will experience this problem more and more. Some people cope by having a context switching role during office hours and after hours get a good 1 or 2 hours of solid dev work in, others book their own time out, and close their door signaling they are unavailable. Unfortunately this isn't always possible, you'll always get colleagues / clients that still bash your door to get some time with you. But being in this transition phase between the two worlds is definitely one of the biggest challenges every dev faces. Best of luck. One thing though, having more personnel will not solve this problem, only make it worse, as you now will have even more people reporting to you and which you have to keep busy. [1] http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html
- kreeben 11y ago
  A good desription of my working situation is that I'm somewhere in-between the two worlds you describe. Thx.
- erikb 11y ago
  I don't know. Even since I was a student developer for companies there were always at least three topics at any given focus that needed at least some share of my attention. PG's suggested stretches of time where I could just do one thing are very small and very small to realise. In a great world one would have such a schedule, but if you don't code alone you will always be interrupted. At least that's my experience up to now.
  - aidenn0 11y ago
    It really depends on where you work. I worked one place where communication was biased heavily in favor of e-mail, with the understanding that it was less intrusive than other forms of communication. There was not exactly a ban on interrupting developers, but there was a culture against it (and there were things that were explicitly always okay to interrupt a developer for; e.g. a bug found by a customer).
desbo 11y ago
A bit of humility will do you good.
- kreeben 11y ago
  I've just recently learned all the good things that come with being humble. Becoming an adult, but slowly.
jackgavigan 11y ago
The act of context-switching itself is tiring so the trick is to keep the amount of context-switching you do to a minimum. For example, during brief idle times (e.g. while you're waiting for something to download/upload/compile), don't do stuff that requires you to concentrate hard. If you do, you're effectively "unloading" the previous context from your brain and replacing it with something else (e.g. dealing with email). Then, when the thing finishes downloading/uploading/compiling, you have to "reload" the original context. That's two context-switches that you don't really need to do. I used to be a trader, which requires a lot of high-pressure, high-focus context-switching, most of it interrupt-driven. During brief downtimes, we wouldn't try to get something else done - we'd let our brains relax by goofing off, talking about crap/sports/girls/whatever, shooting Airzooka or Nerf guns at one another, playing practical jokes, giving one another shit, etc. That sort of stuff doesn't require a context switch in your brain because you don't have to concentrade - you just let your brain relax (like letting a CPU sleep while it's waiting for input). When a work-related interrupt arrives, you just drop the goofing off and concentrate on work stuff again. It may sound like you're wasting time by not filling every minute of the day with productive work but, overall, you'll probably be more productive because, althought you're spending less time actually working, the quality of your work will be higher. Plus, you won't feel as exhausted at the end of the day/week.
- Steve44 11y ago
  I was a programmer many years ago and always had music on when working. It wasn't pumping / awesome music but it allowed me to drop back from the concentration of work into the music for a short while then get straight back into work. I wouldn't lose my attention and it game by brain 30 seconds of down time. People are different, but that works really well for my. My role is now more 'interrupt driven' and I really don't like it, people get the hump when I make them wait 10 seconds stood at my desk seemingly being ignored as I finish the micro task.
kreeben 11y ago
Big thanks for reading my post. I most definetly have a touch of ADHD (my therapist concludes), I'm anti-social whenever there is room for me to be that, I love the rush of being in the middle of a complex problem, alone in my cathedral, looking, debugging, and slowly reaching a solution, one you intuitively know is right, but I'm quite easily distracted when stressed, and context-switching stresses me out. I'm not always humble, sure, and that's is because I am still influenced by an old world view of mine, one which there exists Neo's and ninjas, but it is slowly being replaced by a more adult view of things. But with all my psychological problems I have still managed to make a career out of my abilities but nowadays that career no longer feel like a good path for me. I'm not loving the stress of being half sys dev and half a PL. I'd prefer skipping the latter if it is at all possible. I think, since I'm not enjoying myself that much, that I should either find a more purified sys dev role at Microsoft, Minecraft or Spotify (are you hiring?), or become a PL, or change my line of work entirely.
bshimmin 11y ago
"I’m tech lead in these projects and I coach two of my colleges, rookies, by using peer programming and code reviews and just by straight up lecturing them, sometimes both arrogantly and with a temper, on naming conventions and object orientation and stacks and heaps and such. A couple of hours each day I sit on my own chair at my own desk and code, you know, implementing requirements, doing the things the customer wants us to do, the acctual work. I love those couple of hours." This guy sounds like an absolute delight to work for. I wonder how his "colleges" would feel if they read this!
- kreeben 11y ago
  My colleges have learned to love me. It's not an instant thing, liking me, but after having apologized on several occasions to the people who's feelings have gotten hurt, well, if they know you're a good person they seem to take some abuse ;) But it's a problem I'm well aware of. However, my arrogance can often be explained by me being completely stressed out by my work situation.
  - collyw 11y ago
    Yes, i used to have a boss that would literally shout at me in an open plan office in front of everyone. After a while I realized it was just his style (and I wasn't the only one he shouted at). He was basically a decent guy with some bad habits. His / our boss was the opposite. Came across as a nice guy at first but turned out to be a real ct.
  - selimthegrim 11y ago
    Er, you may be a native German speaker, but a touch of spellcheck might be appropriate given the quotes in the person you are replying to
lmm 11y ago
"The Zone" is not as productive as you think. But also being tech lead for two projects is not a good way to live - you can probably stand to be tech lead on one project, or work on two projects at once, but not both. Find someone you trust enough to hand one of the lead positions over to. If no-one is good enough, maybe you need to work on hiring and/or training.
- buster 11y ago
  What do you mean with "the zone is not as productive"? I recently had the luck to work a few hours from home, undisturbed, alone, in the "zone". It was by far the most productive time i ever had.
Starwatcher2001 11y ago
I've been at this game professionally for over 30 years and still struggle to switch context, and now the memory isn't as sharp as it once was. I can have several projects on the go at one time, and need to provide technical support to various customers "on-demand". My coping strategies are: I context switch as little as possible and try to spend at least a solid day on each project. Of course the support calls scupper this when they come in. I've persuaded my boss to either email, or save up all his attention-breaking calls into a single one each day. I have a text file for each project into which I log what I'm doing and why. You probably know what it's like to be several levels down your stack, "in the zone", when a call comes in. By adding just a line or two, indented, I can quickly recover where I was. eg: Starting to build routine XYZ Need to add new table ABC to database User will need maintenance for that. ToDo. Ask Joe to add it to testing. done. Table added. Create AA class Need a new SQL view for that Created view If this gets more complex in future, consider changing to an SP. Added to deployment file Would this class be better split? That would make for better design, but time is limited now Not convinced UserView belongs in here... ... RING... RING... aggghhhh... mental construct collapses in a heap. I also add comments in there about ideas, changes, problems. If I don't get to pick the project back up for a week or two, I can read the last few dozen lines and get back to where I was. It's also invaluable for recalling why something was done or not, and what else was considered. Using a simple text file allows a bunch of projects to be "grepped" for specific key words very quickly.
mavdi 11y ago
I reserve 4 hours a day for client queries mainly when they are online. And then shut things off for 8 other hours of coding. 4 hours per client mas/menos.
v4n4d1s 11y ago
I really like those context-switches during my workday, never thought that would be a problem for other people. Thanks for the interesting post.
- nchelluri 11y ago
  I confess to being shocked by this (v4n4d1s') post
  - v4n4d1s 11y ago
    Why? Is this really uncommon?
    - markus2012 11y ago
      You're the first developer I've heard of that says they like context switches.
      - v4n4d1s 11y ago
        I'm not really a developer anymore :3 Currently I manage a bunch of eLearning and eAssessment services, like a Moodle installation for 25k users, at one of the biggest universities in Switzerland. It's a very heterogenous environment with a shitload of different systems, different tasks and different objectives from all directions. Context switches keep me awake and my day interesting.
cityzen 11y ago
Why not work with your team to develop a well documented process? Having an actual human being as the source of information on naming conventions, etc. seems counter productive. Obviously the constant context-switching is also counter-productive and borderline unhealthy. It sounds like most of the issues here come down to poor organization and management. If your company embraces the "yes man" culture of trying to keep every client happy all of the time and wouldn't dare tell them that it will be done tomorrow, you'll be in context-switching hell for the life of your job there. It's interesting to me to see people martyr themselves over a poorly organized or nonexistent process.
- kreeben 11y ago
  Yeah, it's an organizational issue that I'm the only one in my team with more than 2 years of experience. I was hired just recently. The strategy of having one strong developer in a group of 3-5 (very cheep) juniors is not working out. We are growing painfully fast and the bottleneck is often finding good developers (that will work for peanuts). What I want to achieve here is an agile development team that can work on several projects at a time, i.e. a whiteboard with tasks coming in from several projects and where everyone in the team has knowledge of all parts of the systems. To me it boils down to this: business men think money can be saved (and quality upheld) by having few or inexperienced developers, if only you manage them properly. I do not.
  - cityzen 11y ago
    I agree with the business men in theory but not in implementation. It sounds like they're talking out of both sides of their mouths. You can certainly save money and uphold quality if you've invested the time/money in developing a solid process. If you don't spend the time to develop a process and don't spend the money on the people that can manage that chaos, you're going to have a bad time. Unfortunately that's what this Startup Cowboy Culture seems to embrace. It's more about looking and feeling busy than actually producing any quality results.
collyw 11y ago
I have now reached the stage where my database and front end app is so central to the running of my organization, that I can hardly get any real development done (I have given up on any features that I expect to take more than a weeks worth of full time coding, as I am bound to be interrupted with something more urgent). How I can frame that as a positive in job applications? I feel like I am not learning much and becoming a 1 years experience 10 times (well for the last two or three). Everyone seems interested in silly hour and a half coding challenges.
fruzz 11y ago
A coping mechanism I have is to work from home. Tracking time in-the-moment (as opposed to waiting until the end of the day) also helps. And having a boss that's been a programmer and is aware of how context switching can hurt productivity. Context switching bleeds time from the main tasks I'm assigned to. If I'm not tracking my time precisely, making a summary at the end of the day, I'll wonder how I was so unproductive in the span of the day for the given task. If I measure it in the moment, I'll see all the little interactions that stopped me. This developer asking me a question. QA asking me to look in something that requires investigation. A little fire to put out over here. Things that are too short and resolved to remember.
devonkim 11y ago
One thing that should be mentioned is that one of the easier ways to avoid interruptions is to simply say "No" more often. As it goes with most simple advice, it's much easier said than done, but delegating tasks better is one skill as a manager that I think must be learned and practiced over time than something that is innate to people in any way. Unfortunately, it's extremely hard to stop the habits of a bunch of people unless you actually change things enough around them to encourage change. Becoming a single point of failure as a human resource is no different of a problem to me than neglecting to design your systems for high availability, failover, and sufficient redundancy. Bus factor is something that does matter but people seem to only realize these things are so terrible in hindsight of a disaster. Unfortunately, I've found that most organizations being reactive by nature rather than proactive tend to require disasters in order to have a sufficient shock to their workflows and methodologies.

99 points by kreeben 11y ago

I've solved this problem by adapting the algorithm from a journaling filesystem to my real life. http://faq.sealedabstract.com/uninterruptible_programming_supply/ http://faq.sealedabstract.com/uninterruptible_programming_su...

VaidasC 11y ago
Interesting technique. But I cannot help to think that it is good mostly for people who are already good (or at least not that bad) at context switching anyways. What I mean is that many people, inherently are more chaotic, and over-structuring their lives is counter productive. It could make productivity constant but overall worse. Thinking about psychology of this, I believe this might be good to "right brained" types, but it would be such a burden for someone who solves problems mainly via extroverted intuition - random thoughts that are generated so quickly and without any structure - you would need to write down something every few seconds basically, forget about actually doing something.
- Tiksi 11y ago
  I do something similar, and I'm very chaotic, not at all structured. When Im doing something I have my notebook open, if an idea pops into my head I write it down, maybe make a few notes about it, then go back to what I was doing before. Whatever I'm currently working on has a star next to it in the notebook. And once I finish I cross it out (usually). Its not organized like a list, basically just a brain dump. ( Examples of old pages: http://paste.click/VvnUdA http://paste.click/VvnUdA http://paste.click/RZyWLG http://paste.click/RZyWLG http://paste.click/CsVaoa http://paste.click/CsVaoa ) Doing it in a text editor would be just one more thing to get distracted by, and it doesn't really work for the brain-dump/brain-map style, since spatial relations between what I write has significance. This way instead of going off on a tangent I can finish what I'm actually trying to get done, but still keep track of the unrelated ideas/thoughts. Obviously it won't work for everyone, but it's boosted my productivity massively, and I'm the furthest thing from structured and awful at context switching (Well I'm great at switching, its the switching back that I'm bad at :) )
  - Starwatcher2001 11y ago
    I used to write stuff down, but in my case on sheets of paper that got filed with the project. But I kept thinking "Dammit, I know I've met this problem before, what was the solution?". Doing the same note-taking thing, but using the PC instead of paper, makes it searchable. You're right about the mind-map diagrams though.
    - Tiksi 11y ago
      Yeah I have plenty of pages filled with the project. Not having them searchable is a pain, but every time I've tried to use vim for it, it ends up being a bigger distraction than the ideas themselves.
  - dharma1 11y ago
    When do you get to research your unrelated ideas? Do you have a set time of the week for it? Or do you just go through your list one by one as and when you finish the current item?
    - Tiksi 11y ago
      I usually go one by one. They end up in a chain of ideas so I just follow that chain down.
verytrivial 11y ago
Huh. I do almost exactly this, but with an always-present vim instance in screen: [ ] reply to comment [x] mention screen [x] what is that other one? -- tmux [x] mention it? -- nope [x] should I produce an example? -- yes, easy [.] demonstrate '.' as current work item [ ] hit reply

jacques_chester 11y ago

I have ADHD and, consequently, task-switching is one of my more problematic quirks. Apart from medication, I've found that pair programming has been an absolute godsend. Having another engineer next to me helps me to keep coming back to the task. We can recreate context quickly through conversation and as one of us fades, the other can jump in. It's also helping me to realise more often when I am launching into a tangent, because those tangents will involve me vocalising the fascinating shiny thing that just popped into my head. That said, the linked post raises a different practice: one story at a time. Context switching should be within the boundaries of a story. If it's too big, break it down. I'm lucky to work for a company (Pivotal Labs) where this is the accepted way of working.

jwdunne 11y ago
Great tips, I too am a programmer with ADHD. I have ADHD to thank for my self-education and following career, where by I cannot resist spending hours on things that are highly stimulating, such as the next interesting thing to learn in computing, which is pretty much infinite. The tragedy is that once something is learned or done so many times it becomes routine and boring. It doesn't provide the same mental stimulation. Unfortunately, in most businesses, the types of problems are almost always in the routine category. This I've found is where my attention faulters.
- VaidasC 11y ago
  At least to me, symptoms you wrote sound totally normal and not necessary ADHD. Of course since nowadays everything that deviates from common character traits is considered ADHD... You could take a look at MBTI character types and find out that this is very normal for some (e.g. INTP).
  - jwdunne 11y ago
    In fairness, what I've written is only a very small facet of the larger set of problems I face on a near daily basis - a lot of which I'd really rather not write about (mostly out of embarrassment, some of which purely because of the massive sense of failure I experience daily). I'm not saying you are one but ADHD deniers tend to dismiss symptoms described in isolation off as "oh this is normal". Without the ability to describe in coherent way how deep the rabbit hole actually goes, many people with ADHD suffer needlessly when trying to seek help. ADHD symptoms are often described as "everybody experiences the symptoms to at least some small degree, perhaps in combination or maybe one alone, but a sufferer is where they experience the majority of the symptoms to a massive degree on a daily basis". In a lot of ways, it DOES look normal. What isn't normal is how extensive the symptoms are and how much of impact they have on daily functioning.

kabouseng 11y ago

To the OP, you are definitely not alone. PG had a good article on the difference between a managers schedule and a programmers schedule [1] (Interrupt driven vs Focus driven). Unfortunately as you become more responsible for the management of your peers and projects, you will experience this problem more and more. Some people cope by having a context switching role during office hours and after hours get a good 1 or 2 hours of solid dev work in, others book their own time out, and close their door signaling they are unavailable. Unfortunately this isn't always possible, you'll always get colleagues / clients that still bash your door to get some time with you. But being in this transition phase between the two worlds is definitely one of the biggest challenges every dev faces. Best of luck. One thing though, having more personnel will not solve this problem, only make it worse, as you now will have even more people reporting to you and which you have to keep busy. [1] http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html

kreeben 11y ago
A good desription of my working situation is that I'm somewhere in-between the two worlds you describe. Thx.
erikb 11y ago
I don't know. Even since I was a student developer for companies there were always at least three topics at any given focus that needed at least some share of my attention. PG's suggested stretches of time where I could just do one thing are very small and very small to realise. In a great world one would have such a schedule, but if you don't code alone you will always be interrupted. At least that's my experience up to now.
- aidenn0 11y ago
  It really depends on where you work. I worked one place where communication was biased heavily in favor of e-mail, with the understanding that it was less intrusive than other forms of communication. There was not exactly a ban on interrupting developers, but there was a culture against it (and there were things that were explicitly always okay to interrupt a developer for; e.g. a bug found by a customer).

desbo 11y ago

A bit of humility will do you good.

kreeben 11y ago
I've just recently learned all the good things that come with being humble. Becoming an adult, but slowly.

jackgavigan 11y ago

The act of context-switching itself is tiring so the trick is to keep the amount of context-switching you do to a minimum. For example, during brief idle times (e.g. while you're waiting for something to download/upload/compile), don't do stuff that requires you to concentrate hard. If you do, you're effectively "unloading" the previous context from your brain and replacing it with something else (e.g. dealing with email). Then, when the thing finishes downloading/uploading/compiling, you have to "reload" the original context. That's two context-switches that you don't really need to do. I used to be a trader, which requires a lot of high-pressure, high-focus context-switching, most of it interrupt-driven. During brief downtimes, we wouldn't try to get something else done - we'd let our brains relax by goofing off, talking about crap/sports/girls/whatever, shooting Airzooka or Nerf guns at one another, playing practical jokes, giving one another shit, etc. That sort of stuff doesn't require a context switch in your brain because you don't have to concentrade - you just let your brain relax (like letting a CPU sleep while it's waiting for input). When a work-related interrupt arrives, you just drop the goofing off and concentrate on work stuff again. It may sound like you're wasting time by not filling every minute of the day with productive work but, overall, you'll probably be more productive because, althought you're spending less time actually working, the quality of your work will be higher. Plus, you won't feel as exhausted at the end of the day/week.

Steve44 11y ago
I was a programmer many years ago and always had music on when working. It wasn't pumping / awesome music but it allowed me to drop back from the concentration of work into the music for a short while then get straight back into work. I wouldn't lose my attention and it game by brain 30 seconds of down time. People are different, but that works really well for my. My role is now more 'interrupt driven' and I really don't like it, people get the hump when I make them wait 10 seconds stood at my desk seemingly being ignored as I finish the micro task.

kreeben 11y ago

Big thanks for reading my post. I most definetly have a touch of ADHD (my therapist concludes), I'm anti-social whenever there is room for me to be that, I love the rush of being in the middle of a complex problem, alone in my cathedral, looking, debugging, and slowly reaching a solution, one you intuitively know is right, but I'm quite easily distracted when stressed, and context-switching stresses me out. I'm not always humble, sure, and that's is because I am still influenced by an old world view of mine, one which there exists Neo's and ninjas, but it is slowly being replaced by a more adult view of things. But with all my psychological problems I have still managed to make a career out of my abilities but nowadays that career no longer feel like a good path for me. I'm not loving the stress of being half sys dev and half a PL. I'd prefer skipping the latter if it is at all possible. I think, since I'm not enjoying myself that much, that I should either find a more purified sys dev role at Microsoft, Minecraft or Spotify (are you hiring?), or become a PL, or change my line of work entirely.

bshimmin 11y ago

"I’m tech lead in these projects and I coach two of my colleges, rookies, by using peer programming and code reviews and just by straight up lecturing them, sometimes both arrogantly and with a temper, on naming conventions and object orientation and stacks and heaps and such. A couple of hours each day I sit on my own chair at my own desk and code, you know, implementing requirements, doing the things the customer wants us to do, the acctual work. I love those couple of hours." This guy sounds like an absolute delight to work for. I wonder how his "colleges" would feel if they read this!

kreeben 11y ago
My colleges have learned to love me. It's not an instant thing, liking me, but after having apologized on several occasions to the people who's feelings have gotten hurt, well, if they know you're a good person they seem to take some abuse ;) But it's a problem I'm well aware of. However, my arrogance can often be explained by me being completely stressed out by my work situation.
- collyw 11y ago
  Yes, i used to have a boss that would literally shout at me in an open plan office in front of everyone. After a while I realized it was just his style (and I wasn't the only one he shouted at). He was basically a decent guy with some bad habits. His / our boss was the opposite. Came across as a nice guy at first but turned out to be a real ct.
- selimthegrim 11y ago
  Er, you may be a native German speaker, but a touch of spellcheck might be appropriate given the quotes in the person you are replying to

lmm 11y ago

"The Zone" is not as productive as you think. But also being tech lead for two projects is not a good way to live - you can probably stand to be tech lead on one project, or work on two projects at once, but not both. Find someone you trust enough to hand one of the lead positions over to. If no-one is good enough, maybe you need to work on hiring and/or training.

buster 11y ago
What do you mean with "the zone is not as productive"? I recently had the luck to work a few hours from home, undisturbed, alone, in the "zone". It was by far the most productive time i ever had.

Starwatcher2001 11y ago

I've been at this game professionally for over 30 years and still struggle to switch context, and now the memory isn't as sharp as it once was. I can have several projects on the go at one time, and need to provide technical support to various customers "on-demand". My coping strategies are: I context switch as little as possible and try to spend at least a solid day on each project. Of course the support calls scupper this when they come in. I've persuaded my boss to either email, or save up all his attention-breaking calls into a single one each day. I have a text file for each project into which I log what I'm doing and why. You probably know what it's like to be several levels down your stack, "in the zone", when a call comes in. By adding just a line or two, indented, I can quickly recover where I was. eg: Starting to build routine XYZ Need to add new table ABC to database User will need maintenance for that. ToDo. Ask Joe to add it to testing. done. Table added. Create AA class Need a new SQL view for that Created view If this gets more complex in future, consider changing to an SP. Added to deployment file Would this class be better split? That would make for better design, but time is limited now Not convinced UserView belongs in here... ... RING... RING... aggghhhh... mental construct collapses in a heap. I also add comments in there about ideas, changes, problems. If I don't get to pick the project back up for a week or two, I can read the last few dozen lines and get back to where I was. It's also invaluable for recalling why something was done or not, and what else was considered. Using a simple text file allows a bunch of projects to be "grepped" for specific key words very quickly.

mavdi 11y ago

I reserve 4 hours a day for client queries mainly when they are online. And then shut things off for 8 other hours of coding. 4 hours per client mas/menos.

v4n4d1s 11y ago

I really like those context-switches during my workday, never thought that would be a problem for other people. Thanks for the interesting post.

nchelluri 11y ago
I confess to being shocked by this (v4n4d1s') post
- v4n4d1s 11y ago
  Why? Is this really uncommon?
  - markus2012 11y ago
    You're the first developer I've heard of that says they like context switches.
    - v4n4d1s 11y ago
      I'm not really a developer anymore :3 Currently I manage a bunch of eLearning and eAssessment services, like a Moodle installation for 25k users, at one of the biggest universities in Switzerland. It's a very heterogenous environment with a shitload of different systems, different tasks and different objectives from all directions. Context switches keep me awake and my day interesting.

cityzen 11y ago

Why not work with your team to develop a well documented process? Having an actual human being as the source of information on naming conventions, etc. seems counter productive. Obviously the constant context-switching is also counter-productive and borderline unhealthy. It sounds like most of the issues here come down to poor organization and management. If your company embraces the "yes man" culture of trying to keep every client happy all of the time and wouldn't dare tell them that it will be done tomorrow, you'll be in context-switching hell for the life of your job there. It's interesting to me to see people martyr themselves over a poorly organized or nonexistent process.

kreeben 11y ago
Yeah, it's an organizational issue that I'm the only one in my team with more than 2 years of experience. I was hired just recently. The strategy of having one strong developer in a group of 3-5 (very cheep) juniors is not working out. We are growing painfully fast and the bottleneck is often finding good developers (that will work for peanuts). What I want to achieve here is an agile development team that can work on several projects at a time, i.e. a whiteboard with tasks coming in from several projects and where everyone in the team has knowledge of all parts of the systems. To me it boils down to this: business men think money can be saved (and quality upheld) by having few or inexperienced developers, if only you manage them properly. I do not.
- cityzen 11y ago
  I agree with the business men in theory but not in implementation. It sounds like they're talking out of both sides of their mouths. You can certainly save money and uphold quality if you've invested the time/money in developing a solid process. If you don't spend the time to develop a process and don't spend the money on the people that can manage that chaos, you're going to have a bad time. Unfortunately that's what this Startup Cowboy Culture seems to embrace. It's more about looking and feeling busy than actually producing any quality results.

collyw 11y ago

I have now reached the stage where my database and front end app is so central to the running of my organization, that I can hardly get any real development done (I have given up on any features that I expect to take more than a weeks worth of full time coding, as I am bound to be interrupted with something more urgent). How I can frame that as a positive in job applications? I feel like I am not learning much and becoming a 1 years experience 10 times (well for the last two or three). Everyone seems interested in silly hour and a half coding challenges.

fruzz 11y ago

A coping mechanism I have is to work from home. Tracking time in-the-moment (as opposed to waiting until the end of the day) also helps. And having a boss that's been a programmer and is aware of how context switching can hurt productivity. Context switching bleeds time from the main tasks I'm assigned to. If I'm not tracking my time precisely, making a summary at the end of the day, I'll wonder how I was so unproductive in the span of the day for the given task. If I measure it in the moment, I'll see all the little interactions that stopped me. This developer asking me a question. QA asking me to look in something that requires investigation. A little fire to put out over here. Things that are too short and resolved to remember.

devonkim 11y ago

One thing that should be mentioned is that one of the easier ways to avoid interruptions is to simply say "No" more often. As it goes with most simple advice, it's much easier said than done, but delegating tasks better is one skill as a manager that I think must be learned and practiced over time than something that is innate to people in any way. Unfortunately, it's extremely hard to stop the habits of a bunch of people unless you actually change things enough around them to encourage change. Becoming a single point of failure as a human resource is no different of a problem to me than neglecting to design your systems for high availability, failover, and sufficient redundancy. Bus factor is something that does matter but people seem to only realize these things are so terrible in hindsight of a disaster. Unfortunately, I've found that most organizations being reactive by nature rather than proactive tend to require disasters in order to have a sufficient shock to their workflows and methodologies.