How important is coding style? This debate is something that really draws out the "artist" and critic in every programmer. In many ways the style of writing code is similar to writing poetry, and what makes the subject so hotly debated is that the beauty of the code, sentence or poem is all in the eye of the beholder. Just like those critics of of prose and poetry, the serious critiques of coding style come from understanding the limits and history of the form. Practice reading and writing lots of code, in different languages if possible, and acknowledging how many ways there are to write the same functionality.
In the same way that experimentation in poetry and prose makes for a better understanding of the overall form, understanding how different coding standards can make for better (or worse) code. With every coding standard the code will be limited but also potentially clarified in a new way.
Organization of code one way can make code reviews easier, but potentially making maintanability more difficult, code may be separated into different sections that are ordered in a certain way that causes significant scrolling, opening of multiple files and jumping through layers of code, that structured a different way may minimize bouncing around.
Coding standards for teams is especially important, and should be strictly adhered to as best as possible, for the overall benefit of the team. Consistency is very important as being able to quickly jump into a new class, module or section of the code "should" be as easy as jumping into a section that you wrote yourself. Coding standards are an agreement between programmers to create a cohesive work, much like any collaborative effort, the final product should be a uniform work of art.
The most diplomatic way to handle this is often through adopting a tool that lets catches errors quickly and consistently. This also frees up code reviews to be on more important aspects like architecture, re-usability, error checking, design patterns etc. as non-adherence to coding standards often ends up becoming the main focus if the code strays too far from the standards outlined. These tools should also be part of the commit process, so that the code is rejected if it does not pass the coding standards (in certain cases some of these tools may have to have slight adjustments, as desired, but with a focus on consistency).
For those C# Unity or XNA projects some guys really like Resharper (30 day trial at http://www.jetbrains.com/resharper/) For a free style specific checker I like StyleCop: http://stylecop.codeplex.com/ there is a good amount of customization and easily embeds into Visual Studio. The information that is provided from the code checks make it easy to know the issue and change the code to follow the coding standards that have been setup.
For python there is pep8 http://pypi.python.org/pypi/pep8 and pychecker http://pychecker.sourceforge.net/ as well as a few more.
In general the style and syntax checkers are becoming quite popular (especially with scripting languages that don't compile) but regardless a good "style cop" will improve code quality, readability of all sections of the code, and allows everyone to focus on writing great code, instead of what it looks like in the end.
Until next time, StyleCop: that is all.
Michael Hubbard
http://michaelhubbard.ca
Monday, October 18, 2010
Saturday, October 16, 2010
Book Review: Agile Software Engineering
Agile Software Engineering by Orit Hazzan and Yael Dubinsky works largely as an undergraduate textbook, dealing a lot with how to teach and educate Agile methodologies in a learning environment. The book is broken up into progressively more involved steps with each chapter ending with a summary and reflective questions. There are also breakdowns of running an agile workshop and dealing with planning, time estimation, reflection. As a whole, the book is quite useful as a beginner-intermediate approach to agile, and would likely work well for teachers & students, as a lot of the structure of the book is related to setting up and teaching agile in a classroom.
One of the more unique parts of the book is how the book references different aspects of agile using the HOT (Human, Organizational and Technological) perspectives. I found that looking at different agile concepts through these filters a useful way to see how agile works on many different levels. The book is also good at giving examples regarding globalization and how organizational culture can be dealt with in projects that deal with outsourced or contracted work, and how agile attempts to address these issues by providing additional transparency and interactions. The HOT perspectives I found were especially pertinent in those areas.
My favorite example, however, was on the the chapter on Trust using elements of game theory, and where the Prisoners Dilemma is applied to a work environment. This was applied specifically to where developers choose to cooperate or compete with one another and results in three possible scenarios:
1. If both developers cooperate they will be more likely to succeed.
2. If only one developer attempts to cooperate (by learning the others code, helping the other etc.) there may be a success of the project, but potentially the one developer that choose to cooperate may not receive as much recognition (since time was spent cooperating instead of competing).
3. If both developers compete (do not help each other, do not learn each others code) there will be no integration of efforts and the project will likely fail.
Obviously the ideal scenario is where both developers cooperate with one another and are awarded equally. As a lead or manager it is important to recognize when and where this type of scenario presents itself, and attempt to foster cooperation over competition.
The book also points to a link to code of ethics at the ACM (Association for Computing Machinery) and while I was not able to find the original link provided in the book at http://info.acm.org/server/se/code.htm I was able to find a similar document on the same site at http://www.acm.org/about/code-of-ethics
Please allow me to delve into a small tangent here: while I personally prefer to not have to mention ethics directly to my team (in hopes that everyone plays nice), there is often a significant amount of emotion that developers have for their work, and some developers can be very defensive about there work, to the point of being difficult to deal with. This attitude is unfortunate as every piece of code can be improved, every single piece of code! There is no such thing as perfect code, just as there is no such thing as a perfect poem, or a perfect painting or anything else that requires design. Things like structure, patterns, organization of the code, variable names, comments, formatting, optimization and more, are all subject to interpretation of what is good and thus can vary greatly from developer to developer. As a team lead, I need the developers to cooperate on the coding standards, but even then there can be a significant amount of hubris in some developers which can cause internal clashes. I have been lucky in my attempts to be like "lukewarm water" between "fire" and "ice", but through my experience feel like a code of ethics may also be a necessity, especially in larger teams.
Overall, the book definitely fits the niche well of being a good learning tool for those interested in Agile methodologies, and is probably best suited in a group environment as many of the reflective questions would likely garner some very interesting responses.
Until next time, I remain,
Michael Hubbard
http://michaelhubbard.ca
One of the more unique parts of the book is how the book references different aspects of agile using the HOT (Human, Organizational and Technological) perspectives. I found that looking at different agile concepts through these filters a useful way to see how agile works on many different levels. The book is also good at giving examples regarding globalization and how organizational culture can be dealt with in projects that deal with outsourced or contracted work, and how agile attempts to address these issues by providing additional transparency and interactions. The HOT perspectives I found were especially pertinent in those areas.
My favorite example, however, was on the the chapter on Trust using elements of game theory, and where the Prisoners Dilemma is applied to a work environment. This was applied specifically to where developers choose to cooperate or compete with one another and results in three possible scenarios:
1. If both developers cooperate they will be more likely to succeed.
2. If only one developer attempts to cooperate (by learning the others code, helping the other etc.) there may be a success of the project, but potentially the one developer that choose to cooperate may not receive as much recognition (since time was spent cooperating instead of competing).
3. If both developers compete (do not help each other, do not learn each others code) there will be no integration of efforts and the project will likely fail.
Obviously the ideal scenario is where both developers cooperate with one another and are awarded equally. As a lead or manager it is important to recognize when and where this type of scenario presents itself, and attempt to foster cooperation over competition.
The book also points to a link to code of ethics at the ACM (Association for Computing Machinery) and while I was not able to find the original link provided in the book at http://info.acm.org/server/se/code.htm I was able to find a similar document on the same site at http://www.acm.org/about/code-of-ethics
Please allow me to delve into a small tangent here: while I personally prefer to not have to mention ethics directly to my team (in hopes that everyone plays nice), there is often a significant amount of emotion that developers have for their work, and some developers can be very defensive about there work, to the point of being difficult to deal with. This attitude is unfortunate as every piece of code can be improved, every single piece of code! There is no such thing as perfect code, just as there is no such thing as a perfect poem, or a perfect painting or anything else that requires design. Things like structure, patterns, organization of the code, variable names, comments, formatting, optimization and more, are all subject to interpretation of what is good and thus can vary greatly from developer to developer. As a team lead, I need the developers to cooperate on the coding standards, but even then there can be a significant amount of hubris in some developers which can cause internal clashes. I have been lucky in my attempts to be like "lukewarm water" between "fire" and "ice", but through my experience feel like a code of ethics may also be a necessity, especially in larger teams.
Overall, the book definitely fits the niche well of being a good learning tool for those interested in Agile methodologies, and is probably best suited in a group environment as many of the reflective questions would likely garner some very interesting responses.
Until next time, I remain,
Michael Hubbard
http://michaelhubbard.ca
Thursday, October 14, 2010
Creating a Great Team
Comparison time: Great Hockey Team and Great Programmer Team.
While I am living in Toronto, I will instead focus on the Vancouver Canucks as a great team example. What do they have?
Star Players: Henrik and Daniel Sedin, Roberto Luongo.
Solid Reliable Players: Ryan Kesler, Alex Burrows, Christian Ehrhoff.
Good to Decent Players: the rest of the Canucks
Up and Coming Rookies: Cody Hodson, Cory Schneider
Parting ways with those that don't fit: Kyle Wellwood
Decent managment: Mike Gillis, Alain Vigneault
Some explanations:
Star Players: These are your guys leading the charge. They will have the most experience, most skill and most dedication to the project. Having a few of these guys will inspire the rest of the team to work harder and better, and will likely be the ones you have to rely upon in times of need.
Solid Reliable Players: While the stars are working their magic, these are the workhorses of the team, dependable, reliable, and dedicated. While they might not have the skill and experience of the stars, it is unlikely you can get stars in every position. The better skilled these lines are, the better chance you will have of completing the project successfully.
Good to Decent Players: These are the rest, and they should be of varying skill level, but all capable in some way, notice I didn't include any bad players. To be in the NHL, you have to have some talent, it should be exactly the same for your company. A player that has no talent will not survive in the NHL or on any good team, and your team should be no different. Give people a chance, give them training, but if they don't have the capability (or the heart), it will forever be a weak link that could be filled by someone else that would help the rest of the team more.
Up and Coming Rookies: These are your juniors and new team members, there is always potential that these could develop into your next stars, or alternatively be sent back down to the minors. A sports team will often give a person an extended tryout, but that doesn't mean they have to make the team, if they aren't getting the job done.
Parting ways with those that don't fit: Sometimes a player can have some good skills, but just not be the right fit for the position they are looking for. Sadly at these times, it is important to do what is best for the team, and that often means parting ways with those individuals who could be useful (maybe with another project at the company) but not on the team as it is now.
Decent management: Just decent management? Sure, while I like the management in Vancouver, it is really the players that are the stars, not the management team. You need smart people at the top helping make the decisions, but unless they are helping score goals (or commit bug fixes) often it is better for them to just let the players do their job.
So what does this mean? Basically the best thing you can hope to do, is hire the best people you can at every position and turn them loose. If you build a team of just rookies and a couple of fourth liners, don't expect them to be able to compete in the big leagues. In the end, you always get way you pay for.
I keep hoping that Toronto will turn it around, but can't help but wonder where their super star players are?
Go Canucks, Go Leafs!
Michael Hubbard
http://michaelhubbard.ca
While I am living in Toronto, I will instead focus on the Vancouver Canucks as a great team example. What do they have?
Star Players: Henrik and Daniel Sedin, Roberto Luongo.
Solid Reliable Players: Ryan Kesler, Alex Burrows, Christian Ehrhoff.
Good to Decent Players: the rest of the Canucks
Up and Coming Rookies: Cody Hodson, Cory Schneider
Parting ways with those that don't fit: Kyle Wellwood
Decent managment: Mike Gillis, Alain Vigneault
Some explanations:
Star Players: These are your guys leading the charge. They will have the most experience, most skill and most dedication to the project. Having a few of these guys will inspire the rest of the team to work harder and better, and will likely be the ones you have to rely upon in times of need.
Solid Reliable Players: While the stars are working their magic, these are the workhorses of the team, dependable, reliable, and dedicated. While they might not have the skill and experience of the stars, it is unlikely you can get stars in every position. The better skilled these lines are, the better chance you will have of completing the project successfully.
Good to Decent Players: These are the rest, and they should be of varying skill level, but all capable in some way, notice I didn't include any bad players. To be in the NHL, you have to have some talent, it should be exactly the same for your company. A player that has no talent will not survive in the NHL or on any good team, and your team should be no different. Give people a chance, give them training, but if they don't have the capability (or the heart), it will forever be a weak link that could be filled by someone else that would help the rest of the team more.
Up and Coming Rookies: These are your juniors and new team members, there is always potential that these could develop into your next stars, or alternatively be sent back down to the minors. A sports team will often give a person an extended tryout, but that doesn't mean they have to make the team, if they aren't getting the job done.
Parting ways with those that don't fit: Sometimes a player can have some good skills, but just not be the right fit for the position they are looking for. Sadly at these times, it is important to do what is best for the team, and that often means parting ways with those individuals who could be useful (maybe with another project at the company) but not on the team as it is now.
Decent management: Just decent management? Sure, while I like the management in Vancouver, it is really the players that are the stars, not the management team. You need smart people at the top helping make the decisions, but unless they are helping score goals (or commit bug fixes) often it is better for them to just let the players do their job.
So what does this mean? Basically the best thing you can hope to do, is hire the best people you can at every position and turn them loose. If you build a team of just rookies and a couple of fourth liners, don't expect them to be able to compete in the big leagues. In the end, you always get way you pay for.
I keep hoping that Toronto will turn it around, but can't help but wonder where their super star players are?
Go Canucks, Go Leafs!
Michael Hubbard
http://michaelhubbard.ca
Tuesday, October 5, 2010
Twitter API, tweetsharp
For me, the most interesting thing about Twitter, is it allows those with interesting (albeit bite sized) data streams as wide an audience as they can reach, without the need for any sort of friend invite/accept protocol. The fact that it is almost completely one-way communication means there are not as many simultaneous conversation threads to deal with (between two users), as most information is either absorbed by followers or lost in cyberspace. The fact there is tons of data, some of it almost exclusive (until it is linked elsewhere) and the number of celebrities, (or other famous people) that the average joe would not be able to have any sort of connection to, seemingly breaks down the barriers and allows the twitterer to get information right from the horse's mouth, or whatever the case may be. This is much different from the Facebook model, where you can only really see your friends data streams. In twitter, you could follow more people than you could potentially meet in a lifetime. Naysayers should note, if Schwarzenegger is on Twitter, that should be good enough for almost everyone :P
Anyway, the big idea would be to code something using the Twitter API, and then tweet about it.
The first thing I noticed was how many examples on the web were out of date. Twitter's implementation of the OAuth (August 16, 2010), before it was much simpler, however safe is good too.
Some links I found useful, the main stuff from twipler is especially useful, and I use to show how to do a simple post based on the tweetsharp libs:
MAIN: http://blog.twipler.com/A34_Simple_Twitter_web_client_example.html
TWITTER SETUP: http://blog.twipler.com/A32_Registering_a_new_Twitter_application.html
LIBRARY:
http://dev.twitter.com/pages/basic_to_oauth
http://apiwiki.twitter.com/OAuth-Examples
Taking the twipler example we can add a small button to tweet.
1. In the interface file add another button (called btnTweet with the following values (if placed after the timeline button it will show up at line 18 of Default.aspx and will modify the designer page as well (go through the UI interface to avoid any issues.)
<asp:Button ID="btnTweet" runat="server" Text="Tweet" OnClick="btnTweet_Click">
2. Add the following code to Default.aspx.cs:
5. Run the application and tweet away (type the message in the text box and hit tweet)!
Many will ask what this has to do with games... well, how many facebook games are there now? How many more with the Playstation Home and Mii's running around? Nearly every device will attempt to talk with every other eventually, and it will only be a matter of time before every headshot you register shows up on your twitter post, facebook wall and rss feed.
Follow me on twitter: http://twitter.com/#!/mayekol maybe I'll post something interesting sometime (but no promises :P)
Michael Hubbard
http://michaelhubbard.ca
Anyway, the big idea would be to code something using the Twitter API, and then tweet about it.
The first thing I noticed was how many examples on the web were out of date. Twitter's implementation of the OAuth (August 16, 2010), before it was much simpler, however safe is good too.
Some links I found useful, the main stuff from twipler is especially useful, and I use to show how to do a simple post based on the tweetsharp libs:
MAIN: http://blog.twipler.com/A34_Simple_Twitter_web_client_example.html
TWITTER SETUP: http://blog.twipler.com/A32_Registering_a_new_Twitter_application.html
LIBRARY:
http://dev.twitter.com/pages/basic_to_oauth
http://apiwiki.twitter.com/OAuth-Examples
Taking the twipler example we can add a small button to tweet.
1. In the interface file add another button (called btnTweet with the following values (if placed after the timeline button it will show up at line 18 of Default.aspx and will modify the designer page as well (go through the UI interface to avoid any issues.)
<asp:Button ID="btnTweet" runat="server" Text="Tweet" OnClick="btnTweet_Click">
2. Add the following code to Default.aspx.cs:
protected void btnTweet_Click(object sender, EventArgs e)3. Change the TweetSharpHelper.cs class CreateRequest method to public (instead of private).
{
string response = Helper.Request(t => t.Statuses().Update(txtBox.Text), false);
litOutput.Text = "<h3>Tweet</h3>" + response;
}
public IFluentTwitter CreateRequest()4. Set the ConsumerKey and ConsumerSecret if you haven't already.
5. Run the application and tweet away (type the message in the text box and hit tweet)!
Many will ask what this has to do with games... well, how many facebook games are there now? How many more with the Playstation Home and Mii's running around? Nearly every device will attempt to talk with every other eventually, and it will only be a matter of time before every headshot you register shows up on your twitter post, facebook wall and rss feed.
Follow me on twitter: http://twitter.com/#!/mayekol maybe I'll post something interesting sometime (but no promises :P)
Michael Hubbard
http://michaelhubbard.ca
Monday, October 4, 2010
Day in the Life of a Game Programmer/ Team Lead
In order to improve my time (and hack my life) I have to know what it has in it. Here is my breakdown of an average (quiet) day, although it is still 9:00-6:30. We have been pretty good about doing 9:00-5:00 hours and that is what most of our guys do, and I would prefer to keep it that way. For me, every day is slightly different, some days I have five hours worth of meetings. Other days I do not leave the office till 8:00pm or come in the next day at 7:00am. It is still better than the hours I have spent at other companies, and have been a member of the 100 hours a week club more times than I would like. But this is a pretty good indication of what I would consider average for now, and with the hope I can get back to more 9:00-5:00 days once the major deadlines have passed.
The day starts for me (usually) at 7:00 AM, and I also included the time it takes for each task in parenthesis.
07:00-07:09 (00:09) Wake up, and then really wake up.
07:09-07:32 (00:23) Morning routine, get dressed.
07:32-07:53 (00:21) Make and eat breakfast while checking email.
07:53-07:59 (00:06) Cleanup, brush teeth, put shoes on.
07:59-08:17 (00:18) Leave apartment start walking to bus stop.
08:17-08:54 (00:37) Get on bus to work, start reading a book.
08:54-08:58 (00:04) Get off bus walk to office and my desk.
08:58-09:29 (00:31) Update code, check email, handle admin duties.
09:29-09:45 (00:16) Stand up meeting for half the dev team.
09:45-10:00 (00:15) Stand up meeting for other half of the devs.
10:00-10:30 (00:30) Assist devs requiring clarification on tasks.
10:30-10:36 (00:06) Write emails to other departments on tasks.
10:36-10:39 (00:03) Grab a glass of water.
10:39-10:45 (00:06) Help a developer find a bug they are fixing.
10:45-11:01 (00:16) Read source code and documentation.
11:01-11:35 (00:34) Code.
11:35-11:38 (00:03) Answer a few questions on a feature.
11:38-12:05 (00:27) Code.
12:05-01:00 (00:55) Lunch.
01:00-01:57 (00:57) Code and test, submit some updated APIs.
01:57-02:10 (00:13) Discuss bug fixes and design strategy.
02:10-02:23 (00:13) Code.
02:23-02:33 (00:10) Work with developer finding bugs.
02:33-02:40 (00:07) Code.
02:40-03:01 (00:21) Work with developer solving issue.
03:01-03:09 (00:08) Code.
03:09-03:21 (00:12) Help developer fix bugs.
03:21-03:27 (00:06) Get some tea.
03:27-03:37 (00:10) Code.
03:37-03:41 (00:04) Answer questions about code base.
03:41-04:00 (00:19) Reply to email and write additional email.
04:00-04:12 (00:12) Work on bug fixes with developer.
04:12-04:28 (00:16) Code.
04:28-05:01 (00:33) Read code review from large feature drop.
05:01-05:06 (00:05) Discuss some updates to a part of the code.
05:06-05:31 (00:25) Finish code review and add comments.
05:31-05:55 (00:24) Read updates to code base from other devs.
05:55-06:24 (00:29) Code and submit.
06:24-06:33 (00:09) Shut down, start walking to bus stop.
06:33-07:15 (00:42) Get on bus, read book.
07:15-07:24 (00:09) Get off bus, start walking home.
07:24-07:31 (00:07) Freshen up.
07:31-07:53 (00:22) Check mail and email.
07:53-08:36 (00:43) Make dinner, eat and cleanup.
08:36-09:56 (01:20) Personal code, while listening to music or tv.
09:56-10:41 (00:45) Get changed for gym, pump iron and shower.
10:41-11:45 (01:04) Play around on computer, code, art or games.
11:45-11:51 (00:06) Get ready for bed.
11:51-12:05 (00:14) Read a bit in bed.
12:05-06:59 (06:55) Sleep (perchance to dream).
Breakdown:
Work:
Administration (email, delegating tasks): 1 hour 53 minutes.
Breaks (lunch, coffee): 1 hour and 4 minutes.
Coding: 4 hours and 2 minutes.
Helping Others: 1 hour and 56 minutes.
Meetings: 31 minutes.
Home:
Computing (web surfing, project coding): 3 hours 7 minutes.
Exercise: 45 minutes.
Personal Maintenance (food, shower, etc.): 1 hour 34 minutes.
Reading (including bus travel time): 1 hour 33 minutes.
Sleep: 6 hours 55 minutes.
Travel (not including bus reading time): 40 minutes.
Other Facts:
Read 39 emails.
Sent 5 emails.
Added 37 comments to code review.
A few noteworthy points to consider about the data. The travel time is actually 1 hour and 59 minutes total for me every day, but I only counted the parts I do not do anything else (i.e. not the reading time). Looking over the numbers, it is interesting to see how much time is spent on helping others and administrative tasks. When I first joined the company as a game programmer, I was able to spend almost my full-time on coding and sent very few emails. However as time went on and more people were hired, I spent more time helping the other programmers too. Still, it is interesting to see how the day breaks down like this, and on further investigation where I can improve my use of time (like maybe try exercising in the morning as part of the regular morning routine)? Or take 30 minute lunches instead of the full hour and leave at 6:00 PM? Or try and come in earlier instead of leaving later?
Another thing to consider is how long it takes a game developer to get "in the zone". Some people at work estimate it can take up to ten minutes to get in the zone, but only one second to get out of it. While it would be great to minimize interruptions, it is far better for me to help remove the other developers roadblocks whenever possible.
Anyway, I will think over the data and may update any changes I made to my day, in a future post.
Until then,
Michael Hubbard
http://michaelhubbard.ca
The day starts for me (usually) at 7:00 AM, and I also included the time it takes for each task in parenthesis.
07:00-07:09 (00:09) Wake up, and then really wake up.
07:09-07:32 (00:23) Morning routine, get dressed.
07:32-07:53 (00:21) Make and eat breakfast while checking email.
07:53-07:59 (00:06) Cleanup, brush teeth, put shoes on.
07:59-08:17 (00:18) Leave apartment start walking to bus stop.
08:17-08:54 (00:37) Get on bus to work, start reading a book.
08:54-08:58 (00:04) Get off bus walk to office and my desk.
08:58-09:29 (00:31) Update code, check email, handle admin duties.
09:29-09:45 (00:16) Stand up meeting for half the dev team.
09:45-10:00 (00:15) Stand up meeting for other half of the devs.
10:00-10:30 (00:30) Assist devs requiring clarification on tasks.
10:30-10:36 (00:06) Write emails to other departments on tasks.
10:36-10:39 (00:03) Grab a glass of water.
10:39-10:45 (00:06) Help a developer find a bug they are fixing.
10:45-11:01 (00:16) Read source code and documentation.
11:01-11:35 (00:34) Code.
11:35-11:38 (00:03) Answer a few questions on a feature.
11:38-12:05 (00:27) Code.
12:05-01:00 (00:55) Lunch.
01:00-01:57 (00:57) Code and test, submit some updated APIs.
01:57-02:10 (00:13) Discuss bug fixes and design strategy.
02:10-02:23 (00:13) Code.
02:23-02:33 (00:10) Work with developer finding bugs.
02:33-02:40 (00:07) Code.
02:40-03:01 (00:21) Work with developer solving issue.
03:01-03:09 (00:08) Code.
03:09-03:21 (00:12) Help developer fix bugs.
03:21-03:27 (00:06) Get some tea.
03:27-03:37 (00:10) Code.
03:37-03:41 (00:04) Answer questions about code base.
03:41-04:00 (00:19) Reply to email and write additional email.
04:00-04:12 (00:12) Work on bug fixes with developer.
04:12-04:28 (00:16) Code.
04:28-05:01 (00:33) Read code review from large feature drop.
05:01-05:06 (00:05) Discuss some updates to a part of the code.
05:06-05:31 (00:25) Finish code review and add comments.
05:31-05:55 (00:24) Read updates to code base from other devs.
05:55-06:24 (00:29) Code and submit.
06:24-06:33 (00:09) Shut down, start walking to bus stop.
06:33-07:15 (00:42) Get on bus, read book.
07:15-07:24 (00:09) Get off bus, start walking home.
07:24-07:31 (00:07) Freshen up.
07:31-07:53 (00:22) Check mail and email.
07:53-08:36 (00:43) Make dinner, eat and cleanup.
08:36-09:56 (01:20) Personal code, while listening to music or tv.
09:56-10:41 (00:45) Get changed for gym, pump iron and shower.
10:41-11:45 (01:04) Play around on computer, code, art or games.
11:45-11:51 (00:06) Get ready for bed.
11:51-12:05 (00:14) Read a bit in bed.
12:05-06:59 (06:55) Sleep (perchance to dream).
Breakdown:
Work:
Administration (email, delegating tasks): 1 hour 53 minutes.
Breaks (lunch, coffee): 1 hour and 4 minutes.
Coding: 4 hours and 2 minutes.
Helping Others: 1 hour and 56 minutes.
Meetings: 31 minutes.
Home:
Computing (web surfing, project coding): 3 hours 7 minutes.
Exercise: 45 minutes.
Personal Maintenance (food, shower, etc.): 1 hour 34 minutes.
Reading (including bus travel time): 1 hour 33 minutes.
Sleep: 6 hours 55 minutes.
Travel (not including bus reading time): 40 minutes.
Other Facts:
Read 39 emails.
Sent 5 emails.
Added 37 comments to code review.
A few noteworthy points to consider about the data. The travel time is actually 1 hour and 59 minutes total for me every day, but I only counted the parts I do not do anything else (i.e. not the reading time). Looking over the numbers, it is interesting to see how much time is spent on helping others and administrative tasks. When I first joined the company as a game programmer, I was able to spend almost my full-time on coding and sent very few emails. However as time went on and more people were hired, I spent more time helping the other programmers too. Still, it is interesting to see how the day breaks down like this, and on further investigation where I can improve my use of time (like maybe try exercising in the morning as part of the regular morning routine)? Or take 30 minute lunches instead of the full hour and leave at 6:00 PM? Or try and come in earlier instead of leaving later?
Another thing to consider is how long it takes a game developer to get "in the zone". Some people at work estimate it can take up to ten minutes to get in the zone, but only one second to get out of it. While it would be great to minimize interruptions, it is far better for me to help remove the other developers roadblocks whenever possible.
Anyway, I will think over the data and may update any changes I made to my day, in a future post.
Until then,
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)