Developer Time | Hacker News Reader

Developer Time

pydanny.com

103 pointscraigkerstiens74 comments

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.

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.

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! :)

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

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.

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

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

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

I have long wondered how the phrase came to mean this, because when it happens, it's never a drill.

I imagine it's due to the superficial similarities, i.e. a bunch of people running around not really knowing what they should be doing, but in a big hurry.

You go through all the pomp and circumstance like it actually mattered, even though the majority of the people running around know it doesn't.

The vast majority of business firedrills are arbitrarily caused by someone wanting a deadline met for no particular reason.

Everyone does crunch time not because there is actually a pressing emergency, but because the company wishes to extract additional effort for no additional pay.

Hm, ok. That's not been my experience. For example, I have definitely heard it used in Operations contexts to describe broken shit that needs fixing now -- things that are real problems and not drills. "Drill" to me implies preparation for an event in the future like a test or an emergency.

Perhaps it is a politically-correct version of this: https://en.wikipedia.org/wiki/Chinese_fire_drill which includes the substitution of mere activity (all hands on deck & running around) in place of the desired results.

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

This makes a lot of sense to me, and might explain what's going on with the puzzling uses of "fire drill" I've witnessed in recent years. I almost want to say that there's been a shift in jargon going on, because I feel like I hear people talk about fighting fires at work less often than I used to say, a decade ago.

To the degree that it's systematic, I'd say it's probably a perjoration as people became uncomfortable talking about fighting in the workplace (or whatever).

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.

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

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.

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.

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

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.

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.

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.

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?

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.

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

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

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

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.

I am of a similar age to you I am guessing. I think many people have a mythical view of their own ability to escape the typical human experience.

Perhaps distractions don't damage your productivity, but I am guessing you're merely more productive now, so the short bursts you make are more productive than your old longer bursts, therefore your 'Warm up and cool down' periods FEEL shorter. It's not like people do nothing when not in flow, they just do less.

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.

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...

This is awesome. Thank you.

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.

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

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.

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.

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

Higlight the was part strong enough, and maybe you'll make them feel a bit of healthy guilt about interrupting you.

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).

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.

Arguably this is the role their manager should be taking.

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.

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

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.

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.

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.

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!)

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

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

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.

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.

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.

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

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.

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.

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

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?

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

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.)

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

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.

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

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.

Where do you need that kind of coordination?

Any company that is competing in the marketplace.

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

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.

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

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

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.

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

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

Reply on news.ycombinator.com