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.

So Beautiful

Memories of Winter

Lets go for a Swim

Treating RSI

One of the most critical health issues around programming is RSI. If not properly addressed, it can end your career. For a while I was quite concerned that it would end mine.

The problem with RSI is it seems the causes are each subtly different, and so it responds differently to various treatments.

Here then is my personal set of treatments. If you're feeling any discomfort at all, don't wait, change your set-up immediately.

• See a doctor immediately. I eventually got a doctor to drain the cyst in my wrist, drastically reducing the discomfort.
  
• Take breaks of all kinds. Hourly breaks for 5 minutes. Lunch breaks. Weekends off. Long computerless vacations.
• Sleep. Highly underrated treatment. Directly proportional to comfort.
• Wear long-sleeve shirts and even fingerless gloves in order to keep the hands warm while working. Also very underrated.
• Ice inflamed areas after work.
• Kinesis Advantage keyboard. Worth more to me than the entire computer itself.
• Ergonomic mouse. Try to never use it. Especially the wheel.
• Turn up the thermostat in your computer room. Never program in the cold.
• Sleep. Some more.
  

Language Acquisition

Moving from Canada to live in Japan exposed me a lot to issues of acquiring and using language.

In Canada, Japanese is considered an exotic, difficult, but cool-to-know language. Often people would stop me while reading Japanese and exclaim "how on earth can you read that?"

In Japan by contrast, Japanese would always complement me on my Japanese, regardless of how poorly I was speaking. The Japanese believe their language is hard to learn (a common enough bias, after all they don't know how they learned it), and they know from experience that English is "hard". They naturally assume its because all language acquisition is hard.

(Aside: a joke among expats: "How can you tell when your Japanese is getting good? When people stop complimenting you on it!")

The problem with Japanese and learning English, is not that English, or any other language, is hard to learn. The problem is with the Japanese and the way they try to learn it.

They approach foreign things as one might approach alien things: with a certain distance born of trepidation; and not without a little touch of fear. Japanese culture teaches that it is polite to be reserved, and that verbal outbursts could land you in real hot water.

They are also taught that since speakers are circumspect, listeners hold the burden of interpreting the meaning of those choice words, and must act without need for further clarification.

The result is an intolerable internal state for many Japanese people; marked by a sensation of stress owing to the conflict between the demands of society, and their individual failure to meet those demands in a foreign language. This angst can be avoided in education by sticking to completely sanitized forms of learning, specifically wrote memorization of vocabulary and grammar being the most common teaching method throughout Asia.

When I was there, I tried to explain this to some of my exasperated Japanese friends when they complained how hard English was. I would say, "No, no; you just have to adjust your strategy to include more human-human practise! Just speak and listen often! And don't care about making mistakes!"

Another problem I found was that Japanese always wanted to learn English in little convenient to chew pieces -- an hour once a week -- after work as part of an involuntary training program at the local English Conversation school. They'd spend .5hr turning their brain to English mode, then just when they'd have succeeded, the next 23.5hrs were spent forgetting all about it.

Another frequent recommendation that was fairly abhorrent to most inquisitors was the suggestion to spend a month overseas. I never understood how one could spend so much time and effort on consistently proven ineffective methods, then balk at such a simple, proven, effective ones. No one had ever heard of "language immersion!"

Now living in Finland, its such a shock to me how it is that so many Northern Europeans are so good at English. One might be able to argue that Swedish and Norwegian are distant relatives of English, and that's why its easy for them. But there is no arguing that Finnish is any way related to English -- and yet the Finns are astoundingly good at it.

If you ask them why it is, they'll tell you, "Because we are only [4] million people. No one is ever going to bother to learn [Finnish], so we learn English. And its not just in the schools. Almost all of our (imported) television is in English, with subtitles."

In other words, from youth they are exposed to a lot of English speaking, with Finnish translations. And in time, probably years, it becomes easier to listen to the (native) English than read the Finnish. Repetitive exposure.

I am not sure how really "revolutionary" this study is, since it just validates what I knew already from experience. However perhaps if it gets more exposure, it will quiet the old-school thinkers who actually think text-books and memorization will ever help. Or that one can learn a language in "X minutes per day!" Or speaking two languages to a (my) child will only "confuse" them (her).

Bottom line: if you don't indent to spend a significant amount of time surrounded by a language, you should not be surprised that its not sticking, or its "hard". That includes the majority of Japan.

What was a bit of a surprise to me, now validated by the above study, is that exposure to a lot of TV-with-subtitles appears to be enough (along with basic grammar in schools) to attain a surprising level of proficiency.