Developer Time

by craigkerstiens • 14 years ago

103 74 14 years ago

chewxy• 14 years ago

Headphones, and a reflexive action to punch anyone who touches you when you have your headphones on is a very good way to dissuade people from distracting you and pulling you into meetings.

source: I do this :P

sharkweek• 14 years ago

I like this idea -- headphones on, head down; get into the habit of having extreme reactions to people tapping on your shoulder by flailing around and acting super surprised they were there. Should hopefully keep the random drop-ins to a minimum.

gurkendoktor• 14 years ago

Doing this (well not punching people, just saying "not now" and putting the music back on :)) I think it works because there is such a need for programmers. Otherwise, I would probably come across as a candidate with terrible communication skills.

nicholassmith• 14 years ago

I do that, but I always follow it with "sorry I was in the zone", which everyone instinctively gets and understands.

tomasien2• 14 years ago

I wrote about this morning actually! Realized that hating being interrupted by meetings made me feel like a programmer for the first time. http://tommy.authpad.com/i-apologize-for-every-unnecessary-s...

pydanny3• 14 years ago

This is awesome. Thank you.

tomasien2• 14 years ago

My apologies to everyone who read this from this thread, I'm going to put this on HN tomorrow morning. Meant to do it this morning.

pygorex• 14 years ago

As a developer I schedule "surgery time" to avoid distractions. Blocks of 2-4 hours during the day where I go dark - no phone, no email, no chat/IM. The surgery analogy is apt. A good surgeon is amicable, knowledgeable, listens to patients and applies a deft touch to fix problems. But when he's elbow deep inside a patient he sure as hell isn't going to be taking any phone calls.

wglb2• 14 years ago

When I need to be in the zone, knowing that there is a fixed end time can be an obstacle.

aleprok2• 14 years ago

Why to set a fixed end time for your zone? Your zone will end when you have finished your task and start to look for the next task.

j-kidd• 14 years ago

If you do not telecommute, you may want to set an end time to beat the rush hours traffic. One of the many reasons why it is unproductive to work in an office.

wglb2• 14 years ago

External inputs. Upcoming family events, scheduled meeting a few hours away, things of that sort.

diminoten2• 14 years ago

As a guy in QA, what should I do? I can't ever tell if it's just the developer being nice when they say they want me to tell them about bugs before filing them, or if they actually want me to.

How would you want your QA people to deal with this problem?

pydanny3• 14 years ago

See, that's part of the problem. We need to interact with you. Do we skip meetings and go to tickets? Except that tickets are often ignored or are misunderstood. Then comes the need for discussion. Of course, interrupting a developer is bad, so you have to schedule a discussion - A.K.A a meeting.

There is no magical solution to this problem. :P

meej4• 14 years ago

Agreed.

What I notice at my current employer is that trying to avoid pulling people into meetings results in what I call "Development by game of Telephone", where software requirements become rumors passed between employees. (Even when requirements are documented -- because the documentation is vague.)

lostnet• 14 years ago

Short email. Anyone who is bothered by an email midstream chose to be.

X-Istence• 14 years ago

File a ticket. I will generally be nice when people interrupt me due to bugs or issues, but in most cases I will also be annoyed because I am busy working on something and now I am out of the flow.

File a ticket, I will get to it the next time I am in the tracker updating my task list or jotting down the time it took me to do certain things. Anything from QA coming back to me requires my immediate attention because most likely I am holding someone or something up.

aleprok2• 14 years ago

File the ticket and email me and I will get to it when I read your email. Easy as that.

chris_mahan2• 14 years ago

If you have to file a ticket every time you need to ask someone a question about work, you will find that the lack of coordination will make whatever your team is working on fail, so you should just fire the developer who requires that and save his salary.

rhizome4• 14 years ago

A bug is a bug, what's the conversation supposed to be about?

diminoten2• 14 years ago

Usually there's a question of, "Is this a bug, or do we have an environment problem, or configuration problem, or is it really a feature?"

In a perfect world, environments would be exact, configs would never change, and features would be flawlessly documented, but such a world is not one I live in, nor do many other people.

moocow01• 14 years ago

The fix: work remotely.

Besides call in meetings you can filter all your communications through electronic means. I check my email only every 4 hours. When I need to not be distracted I turn off my IM. It can be kind of lonely but Im overall much much happier.

MattRogish2• 14 years ago

It's up to the entire company to make sure to leave ample time for developers to enter flow. And to reduce any interruptions that will negatively impact flow.

I find it really amusing when companies have "no meeting Wednesdays!" - fix your damn system so that you don't need so many meetings. I know of no actual programming problem that requires so much coordination that a programmer actively needs more than two or three meetings a week. My goal is to get every developer to 1 meeting a week (the weekly 1:1).

Things to remove:

* Meetings

* Interruptions/Noise (this is why open-plan offices are terrible)

* "Can I ask you a quick question?" questions

* High-bandwidth communication for anything that isn't life-or-death emergency

* Fire-drills/"emergencies"

* Fixed work schedule

Things to do instead:

* All meetings (with the exception of 1:1's) are optional

* Async communication wherever possible (chat rooms, email)

* Assume that any person, at any time, can be remote (this changes everything and makes sure that folks prepare ahead of time)

* 100% flexibility in work schedule to allow for folks to find their productive peaks, whether that's at 4am or 4pm

agrona• 14 years ago

Fire drills strike me as an infrequent yet important safety measure. Unless it's some management term I don't understand?

MattRogish2• 14 years ago

When someone else's lack of preparation or planning makes it your last-minute problem. NOT the life-saving kind.

rhizome4• 14 years ago

I think the poster misspoke and they meant, "fire-fighting."

dominicrodger• 14 years ago

We use it to mean practising how we handle bad things, such as unexpected server failures, which seems to me a reasonable appropriation of the term.

jaggederest2• 14 years ago

Don't forget paperwork. Nothing kills productivity like logging time in quarter-hour increments, or filling out weekly summaries, for example.

sounds• 14 years ago

I agree in principle, but especially when I'm still getting up to speed on a complex code base (and when am I not?) I need something like a weekly summary to achieve a good balance between exploratory and goal-driven tasks. Not to say that every weekly summary is as useful – sometimes management turns it into Sisyphean labor.

For instance when I'm starting to learn a new language: I do a mix (whatever's comfortable) between exploring and goals. Explore: read some documentation, look at tutorials, make toy projects. Goals: figure out how hard it is to get "real work" done.

The weekly summary often is the catalyst for my mind to take the different small projects and find larger threads in them.

Bamafan• 14 years ago

This only works in environments where:

[a] Others (non devs) can be entrusted to make decisions without developer input. Rare, in my experience.I've been in several hour-long meetings where I've only had 5 minutes of input, but that 5 minutes of input saved weeks/months of frustration/headaches.

[b] Offices are setup in such a way that devs get their own quiet space without surrounding distractions.

Most money available in the industry exist at places where 'a' and 'b' don't exist.

jrs235• 14 years ago

I have a saying, "If someone's not crying or dying, they can wait 25 minutes."

emmapersky• 14 years ago

I think striking a balance is better, or more specifically allowing individuals to find there personal optimum spot. Personally, I love working in a busy open place office with conversations and discussion going on all the time. I thrive on the energy and excitement. But I like to balance that with only working part of my day like that, and stay after the hubbub dies down.

tommccabe• 14 years ago

Everyone gets interrupted. Why do we (developers) think that we're unique and should be the only ones immune to interruptions in the workplace?

Nearly everyone is going to work better with blocks of time dedicated to their task(s). How about we all (developers + non-tech people) work together to reduce the amount of noise that our companies generate so that everyone can be more efficient?

mgkimsal2• 14 years ago

Lots of thoughts on this, not sure where to start.

Generally, if you try to reduce socializing, you're seen as antisocial. Trying to be more efficient for the "bottom line" or "good of the company" or whatever makes you sound like a brown-noser.

Yes, everyone gets interrupted. It affects some classes of workers more than others. Not that developers should be treated as "special", but most places I've worked at, mgt and financial people get private offices so they're "not interrupted", but somehow developers building the software the company runs on and/or sells are supposed to be fine in open-air bullpens, just like call-center workers.

There's an element of status I suppose to, but perhaps those with private offices should try to get their work done out in open-air offices for a few months.

mixmastamyk• 14 years ago

Because managers don't understand the "maker's schedule":

http://www.paulgraham.com/makersschedule.html

gte910h2• 14 years ago

Developers have to have a lot more in working memory than many other types of position.

riazrizvi• 14 years ago

Though the better you get at organizing your code, the less you need to push your working memory. In the first decade of my coding life, it took me a while to 'warm up' and 'cool down', distractions were extremely irritating. In the second decade I started to find it easier to jump in and out of the coding state, by maintaining a more focused problem-space.

briancurtin• 14 years ago

Working from home changed the game for me. I used to sit outside of the busiest conference room on the floor and not only did it affect me, but it opened my eyes to how many meetings people were going to.

I understand PMs being in a bunch of meetings, but I'd see devs and testers in that room multiple times a day. The worst would be how many 3 minute meetings would go on there that started 2 minutes late. People would show up a minute early, leave a few minutes later, then be back to their desk a minute later. They probably tuned out of work five minutes before that, wasted five or so minutes with this "meeting", then weren't back in the flow for another 10 minutes after that. Some useless or empty "status update" cost 25 minutes, and I think that's being pretty generous.

3rd3• 14 years ago

Not related to the article but the CSS text selection color is really bad.

pydanny3• 14 years ago

Ouch. And I just started the css/design refactor today. :P

jkbyc2• 14 years ago

I think this concept is much better described here via a dream analogy:

http://alexthunder.livejournal.com/309815.html

(DON'T WAKE UP THE PROGRAMMER!)

jkbyc2• 14 years ago

and also by pg: http://www.paulgraham.com/makersschedule.html

thaumaturgy• 14 years ago

Also: build better tools (and get better at using the ones you have).

If you can squirrel away a little bit of time here and there to make hard things easier, then you can eventually start breaking tasks down into chunks that fit better into a day of interruptions.

This has been the only way that I've found to consistently increase my productivity no matter how much I'm procrastinating or being distracted at the time.

rhizome4• 14 years ago

So when you're deep in focus, or trying to be, and there's an interruption or ad-hoc open-floor brainstorming meeting right next to you, you just blink once or twice and shift over to some easy-pickup task you already have waiting in the back of your brain? Add a zero to your rate.

corwinstephen• 14 years ago

Headphones: the ultimate "don't talk to me, I'm working" sign.

tobyjsullivan• 14 years ago

I agree that a complete fix is unrealistic; however, identification of the problem certainly leads to potential for mitigation.

My personal favourite was the idea of a day of no interuptions. I think this would be relatively easy to implement and one day of high productivity is still an improvement over zero days of high productivity.

A further solution might be good old fashioned office hours. You have a question for that requires my personal advisement? Great! I'm happy to answer! Anytime between 4:00 pm and 5:30 pm. If it really can't wait, email me and hopefully I lose my flow and check my email in time.

willholloway2• 14 years ago

This is why I created my own alternative to ordinary clocks - Maker Time: http://willholloway.net/makertime.html

Clocks get it wrong because they count up, but one day we will all die, so from our perspective time is counting down.

I started thinking about alternative calendar systems when I learned about Post-Revolutionary France's attempt at introducing metric time.

The problem with dividing the year by 1000 is 1000 is divorced from astronomical reality of life on earth. Swatch internet time is the latest attempt at this but I think it misses the mark.

I wanted a time keeping system that matched up with our cosmic reality and the reality of making things vs managing people. We have two important events, the year (one rotation of the earth around the sun) and the day (one rotation of the earth). The moon's cycle is only important for tides (and it's close in duration to the female menstral cycle)

Maker time divides the year into 1095 (or 1098 in a leap year) blocks. Each block is 8 hours. On January 1st the count resets.

This way I don't have to look at the clock and feel the stress it engenders, but also I get to mark the passage of time.

There are 82 maker time blocks left this year and I have big plans for those 82 remaining blocks of time. And one 8 hour block for sleep per day is productive time, thats when my brain encodes the things I learned into long term memory.

hdivider• 14 years ago

Stuff like this is why I still love HN, for all its flaws. :)

This is pretty interesting - I'm going to start checking Maker Time regularly, and see if my perspective on things changes. One's perception of the passage of time surely has an uncommonly high influence on important psychological factors like motivation and focus, and we've been using pretty much the same division of time for hundreds of years, so there are probably efficiency gains to be made with stuff like this.

nileshtrivedi• 14 years ago

Nice! I made http://936months.staticloud.com/ to look at one's life in blocks of months (936 on average). Seems to work well for inspiring someone! :)

willholloway2• 14 years ago

936 Months is really good. It sounds trite but this really does put things in perspective.

Shorel• 14 years ago

Just to inform you and thank you, your application looks really beautiful in the Opera speed dial page ( https://www.google.com/search?q=opera+speed+dial&hl=es-4... ).

I made it the first bookmark.

laquan_is_great• 14 years ago

The post is right on, but I also have to repost what laquan jackson said in the comments:

"Programming is for weak and effeminate men. Try carrying bricks up flights of stairs, or collecting rent checks in the inner city. And on top of all this you complain about "being interrupted"? Oh, how awful it must be for you. You need to check to see if you have a vagina down there."

Sure it may be controversial, but it's funny.

logn• 14 years ago

Just get to work early. I used to work on the east coast alone and the rest of the team was west coast which was great since I got about 4 hours every day of being alone. You could do the same thing by switching your start time from say 10:30am to 7am.

ww520• 14 years ago

That's why coding at night works so well. No one will bother you at night.

jschuur• 14 years ago

I'm a developer turned product manager, and from first hand experience, I can tell you that distraction is one concern, but easy access to chat with the devs also runs the risk of 'just one more feature', or constantly revising the scope of previously discussed work too. That doesn't just get them out of the zone, it confuses them about what they're meant to build.

Sometimes, it's best to just complete a user story as it was logged and then see where we go from there (or even, shudder, after it's been deployed, and actual users have gotten their hands on it).

michaelochurch• 14 years ago

I'm going to inflict some blistering cynicism on this thread.

You don't succeed in most environments based on whether or not you're productive, competent, or expert at what you do. None of that really matters once a company gets to the point where decisions are no longer being made by technical people.

So, you have to suffer. You have to deal with the meetings and the social expectations. Most developers work in an environment where availability matters more than excellence. In at 9:45, when the boss is in at 9:30? Stee-rike one! Miss the daily standup? Stee-rike two!

There is a positive spin you can put on it. Most companies won't actually fire you for skipping those meetings. They're mandatory, but not that mandatory. However, you'll just end up increasingly out of the loop and with a negative reputation... and eventually lose your job, but it will take a long time-- possibly 6 to 12 months, and certainly long enough to get another one. Attending that 15-minute status meeting rather than skipping it probably has as much of an impact on your political standing (and, thus, career) as a 2-hour swing in the overall length of your day. So the efficiency ratio of that meeting to normal ass-in-chair time is 8-to-1. No, it's not what you'd like to be doing with your time, but it's work, and most people deal with a lot worse than status meetings.

The game in most places isn't about getting the most done, or getting into flow and building great software. It's about creating an image so that managerial types, many of whom operate on antiquated emotional metrics of availability and subordination, feel confident in you. It's a game to be played, not a meritocracy.

zacharydanger• 14 years ago

This is excellent advice for when one wants to advance their career working for "the man."

yuhong• 14 years ago

http://programmers.stackexchange.com/questions/45776/why-do-...

imgabe• 14 years ago

I'm going to propose a somewhat radical solution: secretaries (or administrative assistants if you prefer).

Seriously, give developers and engineers secretaries/assistants. Even one assistant per 3-5 engineers would be a huge benefit. A good secretary will run interference with people who are coming to provide a distraction, and in many cases will probably be able to answer any questions necessary without bothering the engineer.

It could also provide a good entry level position for someone to get some experience and move up to coding.

mmcnickle• 14 years ago

Arguably this is the role their manager should be taking.

mgkimsal2• 14 years ago

goodness, the social signals implication that sends would never fly in any company I've ever worked at. You're elevating the developers to the status of "rock stars!". Now, many companies say they want rock star developers, they just don't want to treat them as such.

koz_• 14 years ago

Meditation is a great way to train one's attention and focus.

A lot of ink is spilled describing what companies and bosses could do to enable programmers to get or stay in the zone, but all of that is immaterial compared to one's intrinsic ability to focus, which is a skill that can be developed.

Developer Time

Related Stories