Why You Shouldn't Interrupt a Programmer
heeris.id.au
heeris.id.au
There is a bug in module X
Module is X is calling module Y when user is not yet activated
We are creating user subscription
We are using current subscription in subscription creation
Current subscription is A when user is not activated
Current subscription is B when user is activated
Probably bug in method c()
Think what is going to happen in situation M when changed the implementation to d().
I use NV on MacOS, the SimpleNote app on iPhone and iPad, and the SimpleNote website on Windows.
(It can be seen at http://www.videoarts.com/sales-and-negotiation/so-you-want-t... at 15:15 , but alas only after registration now.)
What OP mentions is taking notes of his though process as he goes along, so he can jump back in after an interruption.
Its basically to learn to localize the problem to a specific part in the code/system. Study the inputs and outputs to that system. Establish single responsibility to that part of the code. Now study the input and expected output from that part of the code. If they mismatch, correct the code and test it out for all possible values of the input.
Additionally automate it/check list it such that those mistakes are not made in the future.
It also provides a visual level of how deep you are into "shaving the yak" - once you're 10 levels into a problem, it becomes easy to forget what the original problem was.
http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gs...
I've considered using a simple stickies app, but there's something about pencil and paper that I find beneficial — or at the least, comforting — and I haven't quite put my finger on it. Not sure if it's the ability to do free-form sketching, or that I can quickly physically shuffle/order/arrange the cards, or that I can jot things down without needing to be at my computer/on a mobile device — or just being able to step/look away from a screen for a bit.
I'm thinking most likely it's that whatever added functionality or benefits I would get from using an app to manage this stuff would be offset by me fiddling around with features, settings, tweaks, etc., and screwing around "evaluating" different tools.
I think meta-productivity is just too much damn fun to leave alone.
I discussed it with a another friend of mine (a business guy) who similarly prefers notes/notebooks and we seemed to hone in on the fact that its superiority over non-physical mediums comes from its freeform nature. The freeform nature allows you to record things in a format that more accurately models the way your mind works. This makes it easier to come back to and have your brain go "Aha yes I have a memory stored for this data because I created this note". With a physical medium, you're never (or at least, much less so) forced into any format that was created by another person (to-do apps, etc.).
When a company invests in expensive equipment like that, it is very important to keep it producing output. So by sending programmers to meetings, your expensive equipment is sitting idle, offline, producing nothing.
Interruptions are like shutting down an entire assembly line. When you turn it in again, it will take time to be running smoothly again.
So to the managers and executives, it is your choice how to utilize this highly specialized, very expensive equipment. You can try to keep it running at full capacity, or frequently start it up and shut it down, take it offline, and leave it sitting idle.
I think, though, it does not invalidate the basic point of keeping the software producers on the task of software production as much as possible in order to maximize output.
When I worked as a team lead I created a rule that there could be no meetings in the afternoons. The daily schedule was that we'd have a morning scrum where everyone would say what they did yesterday and plan on doing today. That was also an opportunity to schedule any meetings for the day, to be done immediately following the scrum. As team lead I considered it my job to take on that burden, when possible, and fill in the rest of the team with the pertinent details afterwards.
It worked out fairly well: stakeholders could schedule time any day to talk to the dev team, but every afternoon (at least) was no-outside-interruptions development time.
I usually get the most done in the morning. I would not be as productive if I had nothing but meetings until lunch.
(It doesn't sound like "nothing but meetings until lunch" characterizes your team, I'm just making a point)
At some points in the project my day often ended up being half meetings, half development. Lunch ended up being a break where I'd switch modes from 'team lead' to 'developer'. It wasn't ideal for me, but it was ideal for the rest of the team and I considered that my top priority.
Some times I literally can't make my brain work after 2 - 3 hours of in-the-zone work. I just can't read lines off a screen anymore.
Other times I can go 24+ hours without breaking a sweat.
I think in practice your average programmer can't operate on the 40 hour a week traditional work schedule and actually output solid performance for all 40. On average, at least. So maybe the first businesses to start introducing meetings and such were attempting to pace their SE staff and actually saw positive results, since they still got whatever the maximum output one engineer could put out before their brain went to mush in a week but also had them talking to clients or discussing other things.
It is just the industry latched on to bureaucracy without postulating why it might be useful. You want your SE coding whenever possible.
For the rest of us there is always code reviews and emails and other fun things that needs to be handled and requires less brain power (well code reviews should require more but let's ignore that).
Then a day or two later I would come up with a better solution and boom, milestone achieved.
Writing that crappy code that feels like pulling barbed wire through your brain forces you to think about the problem. To look at the corner cases, to really figure out a solution.
The breakthrough in a few days is just a cleaner solution you were able to come to after a deep understanding of the problem.
When I was in the zone, I would stay at work until right before I would go to bed.
This way I would spend nearly all of my "in the zone" time doing work.
Now that I have kids and such, I leave at 6 every day regardless of my productivity level, so even though I spend only slightly less time at work, my net productivity is way lower.
These days, I sometimes get cut out of the zone by quitting time, but more often than not I am mentally exhausted and ready to go. I'm sure that this would not apply to the most focused and driven programmers, but I'm also sure that a lot of young startup types are fooling themselves that the long hours they put in are giving them better returns than they would get with a bit more sleep, a bit more exercise and a bit more downtime.
In a sense, "professionalism" in any field implies a certain "frequency of success". For a programmer, that means learning techniques to accomplish tasks even when you aren't "in the zone". This means learning to get in the zone, how to stay in the zone, and learning to produce when you're nowhere near the zone. This requirement is universal to all professionals, including all professional programmers[1]
I would add that learning to approach your work even when you don't feel like it can sometimes yield surprising insights. Your brain is recoiling from work, but only as it approaches it from certain directions. It is possible to approach a problem from other angles, and getting "in the zone" from another angle can sometimes yield unexpected improvements to the product for the simple reason that you're looking at it in a new way.
[1] There are two categories of professional programmers, the hired guns and the artists. They both want to build great things. The hired-gun wants to build things faster and to spec. To him, "great things" is unambiguously defined as 'the things that will satisfy the customer'. All businesses love a speedy, accurate programmer - especially if they can be speedy and accurate in a non-disruptive way. Such programmers are very good at understanding existing codebases, processes, and doing the minimum work to get the job done. Often they simply do not care about technical debt - (indeed, they are incentivized the other way, to maintain (and even increase) technical debt, every bit of which only improves their negotiating position with the client.)
Meanwhile the artist-programmer success is not defined by conformance to a spec. Success is harder to define - but the artist can define success as getting the time to perfect his creations, traveling ever higher up that diminishing returns curve, going higher than most people are willing to go. This kind of programmer is the dreamer, the architect, the creative. This can be a backend architect, or a front-end perfectionist. They share the common goal of mastery and beauty. Most, if not all, programmer heroes come from this category. And rightly so, I think.
I am reading 'Dune' now and I found this advice from Halleck to Paul so relevant :
'I guess I'm not in the mood for it today' Paul said.
'Mood ? Halleck's voice betrayed his outrage even through the shield's filtering.
'What has mood to do with it? You fight when the need arises - no matter the mood! Mood's a thing for cattle or making love or playing the baliset. It's not for fighting'
-- Dune, Frank Herbert
In fact, programmers have to "fight" too, and it is highly different from their daily work: It is when the software is burning cash and they have to find the problem and implement a fix right now. Most programmers find that they deal with that extremely well, though it usually happens at the cost of the rest of the day.
It's certainly the case that I can't grind out code 40 hours per week, but I don't think that sticking meetings in the "unproductive" time helps matters at all.
It also tends to cut down on meeting times because two sets of eyes are usually looking at any given piece of code, so knowledge disperses among the team organically so long as we swap pairs regularly.
Though I like your analogy, most programmers I know would rather say, "Don't interrupt Picasso" rather than "Don't stop the Lexus factory" :-)
Meetings scheduled by managers stand out from the crowd, but if you count them up, are actually a minority (at least for me).
Meetings can be useful tools if you make sure to involve the right people and stay focused. This doesn't require anything special. Just define what you want to decide in the meeting, prepare for it ahead of time, and come to the required decision in the meeting -- discussing as necessary.
If you do that, it was a useful meeting. I have one or two such meetings a week at work, occasionally even three. They're rarely scheduled by management, but instead by the engineers building the system.
Meetings can also be used to disseminate information.
Thankfully I've escaped that sort of nonsense, but it seems like it can pop up anywhere.
While I totally agree with not disrupting working people - I don't think you should ring fence them out of input in the process of defining product - we've all seen what happens in that case - "requirements" nailed down by a non technical team. And it's even more wasteful to have people working on the wrong things, or worst still being given so overly defined work that there is no room for them to add any value or find a better and faster solution.
While good management can help shield teams from unwanted intrusion - everyone needs to get involved in the process of manufacturing great software - which doesn't just mean attending meetings, but taking time to actively plan and consider the issue before the session. If your company values your input enough to bare the cost of asking you to be involved, then you should look upon that as a positive thing (unless they REALLY are just wasting your time with 'busy' meetings, which are really just wasting everyone's time - and it's a sign of either having money to burn with limited direction or a company going the wrong way fast)
Equipment needs to be maintained to continue working at peak efficiency. Sometimes it needs to be taken offline for repairs or routine maintenance. Or maybe you realize you need to switch over an assembly line to build a different product or model more important to your bottom line.
So, yes, there are times when the software manufacturing equipment will not be manufacturing software. But you want to keep that time to a minimum and understand the cost to the business of having the equipment offline.
But other distractions as shown in the comic, I totally agree with doing everything teams, companies and individuals can do to remove all those distractions and keep people working however best works for them.
Send a manager to the meetings, and get that manager to do a nice write up, with action points, afterwards. Email that round the team.
The people with people skills do the people stuff, and the people with coding skills don't "waste" a couple of hours in a frustrating meeting.
I had creative aspirations when I was younger (writing and music in particular), and came to programming because it's far more predictable; the costs of interruption are bad, but interruptions can be avoided, and the difficulties can be mitigated (e.g., I take notes for anything complicated, and re-read them when restarting a task; I break compilation as a to-do list, and/or use version control for non-compiling code). Flow is really important, but I generally know how to do it -- get enough sleep, clear away overhanging stress clouds (like "taxes are due soon"), eat well, break tasks down, get the smallest possible thing working, iterate, and so on).
But creative work killed me -- it was so painful to do iteratively; I'd spend 8 hours "writing" a poem that actually didn't coalesce until the 7.5 hour point, at 4am. Composing a bad first draft of anything left me feeling horrible; I never managed to force my way through that as long as I was trying to make it "what I did".
Now that I do something else primarily, I can noodle around creatively and get much more joy out of it -- but those years left me with much more respect for people doing more creatively-oriented mental work than I do.
> - get enough sleep, clear away overhanging stress clouds (like "taxes are due soon"), eat well, break tasks down, get the smallest possible thing working, iterate, and so on).
That's great for writing a novel, too.
If I'm coding on an uninspired day, I can easily just shift to tasks that I know are simpler, and create a perfectly workable (if boring) solution. I can work my way through to finding even fairly subtle bugs just by stepping through the logic; it's slower than a flash of insight, but it works.
A writer or other creative person with high standards must discard all of that uninspired work. In theory it may help keep the ideas churning, but for most writers I know it can be a frustrating grind when things just aren't quite clicking. It certainly helps to "train the muse" by writing every day at the same time, always filling the page (even with nonsense if that's all you can produce), and so on, but at the end of the day, they can't say "well, this is a shitty story, but it'll pay the bills". It won't.
There's also the psychological difficulty that comes with putting sometimes years of work into something that may actually have no monetary value, or minimal. There are obvious parallels to building a startup, except that novels that succeed can't naturally be built into sustaining income -- you have to start another novel, and it can easily earn you nothing after 5 years of work.
I like to think of writing prose as "writing code against the human BIOS."
Is this really a big deal?
You can't win with some people...
Employers: take note.
Don't Wake Up the Programmer!
Turn off your e-mail client, phone, messages, internet connection, HN.
Need to find places where we can post it to NON-programmers
Write it down. It will be clearer to you. You can more easily refer back to it. You will be interrupted. You will need to do other things before you finish your current grand opus. You will lose your place in your own thoughts just by trying to hold it all in your head the whole time.
I don't have an habit of writing stuff down, but I know I really should. That said, a couple hours of interruption-free work doesn't seem an extravagant request.
Also, be aware that flow applies to all your non programmer friends too. I usually have to train people to respect the signal of the headphones. The most common compromise I've struck is that we IM each other first and ask "are you in flow?" before diving in. It's acceptable culturally to say "yes-ping me in 1 hour." etc.
But maybe that's because I've been in tech for over a decade now and so many people trained me right. :)
It's not that we can't figure out HOW to show it to non-programmers, it's that we DON'T.
I have 50+ retweets of it in my feed - all programmers sharing with other programmers. Don't do that. Go post it somewhere where OTHERS will see it.
For non-compiled code I'll add a dozen line breaks and a note in all-caps to make it jump out in a diff.
Just make sure she knows to not take it personal and she's not 'bugging' you, you just can't be interrupted. You'd think you'd get a ton done when you're completely alone, but that's not the case.
The flip side of saying no to meetings/walk ups is that the senior won't be doing a good job of unblocking the team. It is a huge waste to leave a bunch of junior engineers solving the same issues that you had solved years ago. Mentoring takes a hit and morale takes a dive in that case.
So I told him I'd be happy to oblige if he wouldn't schedule me in as many. He was shocked and said most of the meetings must be from my other manager (who's a real hands-off kind of guy). So I broke out the details and showed him that the vast, vast majority of my "meetings" time was scheduled by him.
He didn't bring it up again, but also continued to schedule me in as many meetings as before... So I guess that's a decision. :)
I suspect there is a correlation between managers who believe their meetings are important and managers who believe that an hourly breakdown of a direct report's work tasks is a more meaningful metric than the direct report's work output.
Edit: I meant plaintive, but my eyes were still crusty with sleep, and I am a giant dummy.
STUDYING: You are all computer scientists. You know what FINITE AUTOMATA can do. You know what TURING MACHINES can do. For example, Finite Automata can add but not multiply. Turing Machines can compute any computable function. Turing machines are incredibly more powerful than Finite Automata. Yet the only difference between a FA and a TM is that the TM, unlike the FA, has paper and pencil. Think about it. It tells you something about the power of writing. Without writing, you are reduced to a finite automaton. With writing you have the extraordinary power of a Turing machine.
Nothing really beats the flexibility of pencil and paper. You can draw boxes, doodles, graphs, heuristics, flow charts, mind maps etc. Basically you can do what you can think and conceive of, with your mind as your only limit.
Service Temporarily Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
(FWIW, I don't think the assembly line is a good example, because programmers work in parallel, not in sequence, but it's the best sort-of-example I could think of on a Monday morning...)
The day we can replace the mental process required to fully understand a problem is the day we can put down our keyboards and let the computers do all the programming for us. Until then I assert that you will not produce the same quality of code without doing the hard work in your own head.
I work with vim only because I don't think IDE's contribute much at the moment. I believe they should be able to contribute a lot more. I'm just not sure how that is supposed to look, but luckily smarter people than me are working on that :)
However, when you are really focused on a complicated problem it is hard to find a solution when your thought process is constantly interrupted.
Exploration mode is crucial to the development workflow. It's a space where there isn't "right" or "wrong" and creatively constructive conversations can occur.
You're absolutely right that conversation belongs in development. But only at the right time for the highest effectiveness.
I think sometimes we overlook that really strong problems require many days of active/passive thought. Soooo, sometimes interruptions are good!
Fortunately, computers can do all that for you.
http://www.npr.org/blogs/health/2013/01/24/170160105/if-you-...
You need mutually EXCLUSIVE skills.
When effect is a verb, the object must be the change itself, similar to cause: "Hacker News effected a significant deterioration in site availability". With affect, the thing being changed is the object: "Hacker News affected the site."
Correction was imo: a) correct (was proven false by you) b) unnecessary - pedantry is only OK in strictly professional context, which I don't consider HN to be. This was omitted from original claim by my error ( http://www.youtube.com/watch?v=J7E-aoXLZGY).
I really meant to thank you for correcting me there i.e. "Thanks for that input". It might have came of as sarcastic, but was not my intention. There is nothing (of value) to win/lose in a debate. In fact losing debate is more enlightening.
Obviously, as this is in the purview of the Lexicology Squad, not the Grammar Squad.
"Hacker News did bring something about as a result."
Except that Hacker News did not bring about the existence of the linked site, which would be the actual meaning of "effected the site".
Unless they're particularly egregious, they're generally ignored and the content of the post is focused on instead.