A Programmers Work-day

When I first started working as a programmer full time outside of school, in the "real world", I was a bit unsure what to expect. Would I spend all my day slaving at a keyboard? Would I spend it all in endless meetings? Buried under mountains of TPS reports? How does a real software house organize it's labour force on the day-to-day?

Starting my career in some poorly managed companies didn't provide a shining example for me to learn from.

I was literally shocked to see how much of the day co-workers just surfing out of boredom, but I was a little ashamed to ask anyone about their workplaces. Would anyone be honest about such flagrant waste of time? Would they look down on my workplace as a joke? Was the big horrible secret of the "working world" the fact that very little work actually gets done?

It touched protestant work ethic I didn't know I had. So much wasted time and money felt dirty to me.

That said, it wasn't long before I too #$%@ed my day away on websites; and for the same reason co-workers did: there was no serious management structure. Management didn't give anyone serious goals, or give developers the resources needed to meet them. Management provided no structure or oversight to the development process, and morale was fairly low; no one cared. One place I worked some of the developers showed up at 3pm and left before 7pm, four days of the week!

Over the development of my career no one has yet come out and given me a clear definition of what the professional standard for work ethic, but I have managed to develop my own idea of what should be expected of all programmers from a work day (you'll note I do not include managerial job titles):

Organizational Overhead

2 hours per day

This is the overhead that is not an output itself, but is a natural requirement of any development process, and thus is has to be done every day.

It's often characterized by a series of interruptible tasks that center around communication with other human beings.

• Face to face meetings
• Phone calls
• E-mail and mailing-lists
• Bug triaging and code reviews
  
• Work-related blogs, websites, and IMs

Development

4 hours per day

This is the "real" work, and is the measurable result by which your contribution to the group will be judged. If you're not producing here, you are not a developer.

This work is characterize by the necessity to spend long unbroken periods concentrating single-mindedly on the task(s) at hand.

• Researching technologies or libraries
• Devising designs
• Proposing and discussing design details
  
• Implementing code
• Testing and debugging running code
• Implementing tests and documentation

You'll also note that that accounts for only 6 hours, and the reason is that I essentially do not believe that knowledge workers' productivity, especially developers who are required to expend so much concentration for extended periods of time, scales linearly with time. Your brain needs breaks to open back up. Overwork just leads to burn-out.

The ideal work day for a programmer is some variation on the following:

• 0900-1000: handle time-critical overhead tasks such as emails, bug reports, and meetings
• 1000-1200: concentrate on priority work items
• 1300-1400: regular meetings and emails
• 1400-1600: concentrate on other important work items

It may look like a short day, but I do assume you have developed the ability to concentrate on your task, and you have the freedom to eliminate distractions. I do admit that it is often quite hard, and most people's day looks more like:

• 1300-1700: try concentrate on work while being distracted by meetings and emails

If you really need to have an 8 hour work day for some reason, you'll only find that the extra two hours ends up going into work-place play or dawdling; and I'd personally prefer to go home to my family.

Trying to do too much per day leads to burn-out, which doesn't have to be emotional or dramatic; it can be intellectual, and manifest itself is a subtle lack of creativity that's hard to detect.

Do you agree with my experience-bought conclusion? Do you have your own? Let me know.

Dotmatrix Rhapsody

Mini book reviews

I buy and read a lot of computer books (for various definitions of "read" -- references often aren't page turners).

I always have my judgement about the book from my point of view, but I hesitate to share it with others, as I think there is no better opinion than the one a reader has after he's read the whole book on his own.

That said, when I buy books, I want to read what others thought of it. So to provide a service to my faithful readers, I am kicking off some mini-reviews of book's I've read, mostly in relation to my work.

About Face 3: Essentials of Interaction Design

For anyone like me, who hasn't formally studied Human-Computer Interaction in school but now finds themselves working on anything with a non-trivial user interface, this is the first book I recommend you read.

It's extremely easy to read, and spends a respectable part of the beginning of the book explaining why UIs need to be designed, before moving on to the how of designing one. If you're buying an interaction design book it's because you realize the need for UI design yourself, but may be first required to convince management that the interaction design process needs to be taken seriously; the beginning section will give you that ammunition.

However those who are already professional designers will likely find it fairly a waste of time, and spend most of the book skimming over repetitions of things they already know.

Those like myself, who feel they have a bit of intuition for user interaction design, will find a fair amount to skim over; however without any previous training HCI, it is reassuring to have your intuitions confirmed by the experts, and so even the skimming will be rewarding.

The reason why I chose this book over others is that it's a tutorial, and it proposes a simple design method that concentrates on the heart of designing any tool: people (personas) and what they want to do (goals). It's simple, direct, and resonates very well with my design sensibilities.

The middle part of the book introduces the core methodology (Goal-directed Design), and the latter part of the book moves on to placing that theory within the context of contemporary GUI design. An excellent combinational of motivation, leading into theory, leading into method, leading into example, in a comprehensive, intuition building manner.

Any software developer without existing library on user interaction design needs this book in their core library.

Content Networking: Architecture, Protocols, and Practise

I am not sure if the book defines "Content Networking" very well, but basically it amounts to "how do you get lots of cool content to lots of people on an Internet Scale?" This is very relevant question for our virtual world design efforts.

Printed 2005, this book is somewhat dated given that I am basically only looking out for state-of-the-art texts (or theory, which is undying).

It has chapters on web content, streaming media, IM, and P2P, but those chapters, for me, feel like very cursory survey chapters that don't tell me very much. I enjoyed reading them and found them useful, but I'd probably rather buy dedicated books on each of those topics separately.

What I found very interesting was the treatment of web content, and the secret weapon of the web that makes it so insanely scalable: load balancing and caching. Both of which are relatively simple techniques, but the book goes into specific methods in detail and really opened my eyes to what goes on that I merely took for granted. HTTP gets static for having higher overhead than UDP, but this book makes it pretty clear the stateless nature of HTTP means you can do amazing things with caching and load balancing that make the web scale to global levels.

If you're planning a large scale content deployment system I recommend taking a browse through this survey book, but otherwise it's not overly impressive. Borrow a copy.

Parallel and Distributed Simulation Systems

From the title it's appropriateness to virtual worlds is obvious. However its printing date of 2000 belies a different focus. The book assumes an audience of mostly military simulation designers, and makes direct reference to various standards published by the US military for use in war simulations. The book makes reference to "casual" uses outside tanks and jets, and may even use the phrase "virtual world", but it will take some imagination to remove the discussion from it's military context and place it in a VW one.

The book has a distinct academic feel, visible in its eagerness to categorize all different kinds of methods or system types and give them "helpful" acronyms. The reading is a bit dry, but not overly technical.

If you are looking for a systematic approach to simulations, and want to know what the baseline standards are, having been established in 2000 or earlier, it's worth spending some time to look through. It is probably reassuring to know some terminology within the book, and that you can't go wrong doing something the military has done previously. However there are no new or interesting ideas here at all. At best a reference for a fall-back implementation.

Level of Detail for 3D Graphics

Level of Detailing is quite possibly one of the single most critical linchpins for scalability in a virtual world. You can have a large number of objects sitting in a database, but at the end of the day, a camera sees everything up until the horizon, in all directions, and in some manner everything visible has to be brought into memory and drawn. Clearly the less work "drawing" all those things are, the higher your simulation can scale.

Sometimes reading a book is less about what it tells you as what it doesn't tell you, or rather what it tells you "don't worry, you're not missing anything":

Although the book is dated, the book told me the state of the art LoDing in 2003 boils down to the following decisions: when to LoD, what to LoD, and how far to LoD. LoDing itself is taken for granted as only mesh simplification, which was a bit of a disappointment in that I was hoping there were more magical techniques available, especially for textures which are a substantial burden in VWs. Perhaps there is more to LoDing, just all of it invented post 2003. I was also hoping to find some techniques that minimize loading of meshes, but perhaps the authors failed to consider anyone would be so reckless as to download meshes over the internet. :)

Disappointments aside, mesh simplification is extremely important for future reX, but I suspect that loading those meshes from over the network is by far the greater bottleneck, hitting long before the graphics card breaks a sweat from excessive vertices, so for us mesh simplification would have to happen before the client viewer downloads it.

Recommended for anyone who is implemented a LoD system where huge meshes are bottle necking the G/CPU.

You can help stop this horrible social affliction

Looking for stock art or illustrations?

I recommend the guys at stockart.com for their dedication in representing their clients protecting their copyrights.

It can be hard to make a living when copying work on the internet is so easy.