I was asked by a friend an colleague: "why do people crunch"? This is not an easy one to answer. I suppose for everyone it is a little different, and is often based on the person themself, their attitude, personality and history. For me, I usually enjoy the work, and like the challenge and the feeling of accomplishment when all is said and done (to a point). There are others who will feel it is their duty and responsibility to complete a task to the best of their ability. Others still will fear the consequences if they do not get their work done, and for many it is likely a different combination of all of these responses (and more).
What a crunch can be, is a way of finally pushing the efforts of your labor out into the real world. It can be a symbol of pride to get your work out there, and to finally see it stand by itself. It is hopefully something to be proud of, to feel a sense of accomplishment and satisfaction of what was achieved (often the more difficult projects are the most rewarding in the end). Hopefully along the way you have gelled with the other developers and created a great and fun team.
The opposite end of the spectrum is a situation where whips crack, and people yell. Where all of your blood, sweat and tears is just going towards making someone else richer, and everyone on the team feels that way. While some overtime is almost always expected with any sort of programming job, a ridiculous work schedule should not be accepted for any job. Do what you can, and make sure that whatever you do, you work as a team. Making games should be fun, if it is not, something is going seriously wrong.
Best of luck,
Michael Hubbard,
http://michaelhubbard.ca
Sunday, January 30, 2011
Saturday, January 29, 2011
Code Reviews in Crunch
Code reviews are important (yes, really). If you have a code review tool like Rietveld, Crucible or CodeStriker it is nice to have a central place to do code reviews, especially for a large team. But how often to do the code reviews and is there time?
The benefit of code reviews is difficult to measure and is different from team to team. In a large team with hundreds of thousands (or millions) of lines of source code, no one individual knows all the code, and duplication of code often will happen for those unaware that the functionality already exists. Code reviews are useful for both the reviewer and the reviewee as it shares knowledge and gives feedback on the code quality and implementation. Unfortunately, like many practices during a crunch, code reviews are often one of the first to go. This is understandable, but is important to maintain some form of code reviews throughout the project, especially for crucial pieces or for the more junior developers. They don't have to be as formal, but a quick sanity check of the code your tired developers is putting in will help catch some bugs, flaws in design and other aspects that happen when a project is rushed.
Some people would suggest code reviews for every check in, but I feel it depends on the team. Knowing that someone will review your work is helpful in maintaining a high standard, but at least doing a few key ones with some random spot checks will hopefully help catch a number of issues. Even if team wide the time spent doing code reviews a few hours a week, it will at least bound to catch a few things, and teach you more about the code.
If your project (for some reason) hires new people onto it while in crunch mode, one of the best things you can do is have the person on (nearly) full time code review. This benefits in a few ways. First, the new developer will learn what kind of code is expected, what is being worked on, who is working on it and how the code progresses. Second it will give you information about the new developers skill set, by what kinds of questions they ask and what kind of comments they make. Third, it keeps the new developer out of the code base for a little while, since unless there is something trivial to do, a new developer is more likely to take time away from others with questions and training then they are able to contribute. At least one senior developer should still spend some time as part of the code review, but limiting their time in a crunch is understandable.
If you aren't doing some code reviews, it is a beneficial practice. More time is often spent reading code than writing it, so giving feedback and making the code the best it can be, will help in both the short and long run.
Keep on reviewing,
Michael Hubbard
http://michaelhubbard.ca
The benefit of code reviews is difficult to measure and is different from team to team. In a large team with hundreds of thousands (or millions) of lines of source code, no one individual knows all the code, and duplication of code often will happen for those unaware that the functionality already exists. Code reviews are useful for both the reviewer and the reviewee as it shares knowledge and gives feedback on the code quality and implementation. Unfortunately, like many practices during a crunch, code reviews are often one of the first to go. This is understandable, but is important to maintain some form of code reviews throughout the project, especially for crucial pieces or for the more junior developers. They don't have to be as formal, but a quick sanity check of the code your tired developers is putting in will help catch some bugs, flaws in design and other aspects that happen when a project is rushed.
Some people would suggest code reviews for every check in, but I feel it depends on the team. Knowing that someone will review your work is helpful in maintaining a high standard, but at least doing a few key ones with some random spot checks will hopefully help catch a number of issues. Even if team wide the time spent doing code reviews a few hours a week, it will at least bound to catch a few things, and teach you more about the code.
If your project (for some reason) hires new people onto it while in crunch mode, one of the best things you can do is have the person on (nearly) full time code review. This benefits in a few ways. First, the new developer will learn what kind of code is expected, what is being worked on, who is working on it and how the code progresses. Second it will give you information about the new developers skill set, by what kinds of questions they ask and what kind of comments they make. Third, it keeps the new developer out of the code base for a little while, since unless there is something trivial to do, a new developer is more likely to take time away from others with questions and training then they are able to contribute. At least one senior developer should still spend some time as part of the code review, but limiting their time in a crunch is understandable.
If you aren't doing some code reviews, it is a beneficial practice. More time is often spent reading code than writing it, so giving feedback and making the code the best it can be, will help in both the short and long run.
Keep on reviewing,
Michael Hubbard
http://michaelhubbard.ca
Saturday, January 22, 2011
Estimating "How Long will it Really Take"
First off, I want to say I love Star Trek, especially The Next Generation, and still consider it one of my all time favorite shows. Here is a great scene from Captain Montgomery Scott (James Doohan) and Lieutenant Commander Geordi La Forge (LeVar Burton). Season 6, Espisode 4 "Relics"
Scotty: "Do you mind a little advice? Starfleet captains are like children, they want everything right now, and they want it their way. But the secret is to give them only what they need, not what they want."
La Forge: "Yeah, well I told the captain I would have this analysis done in an hour."
Scotty: "How long will it really take?"
La Forge: "An hour."
Scotty: "Oh, you didn't tell him how long it would REALLY take did you?"
La Forge: "Of course I did."
Scotty: "Oh laddy, you've got a lot to learn if you want people to think of you as a miracle worker..."
So, you have a task to do. How long does it take? The boss wants it done ASAP, you of course want to deliver it with the right estimate.
How best to estimate how long it will REALLY take?
Is it like anything that you have done before?
Do you have to learn anything?
How many unknowns in the specification?
How big is the scope of the project?
How many people have to interact with finishing the task?
How complex is the task?
What dependencies (if any) do you have for finishing the task?
How many other tasks do you have to handle simultaneously?
Is it something new, or something you have to build on?
All of these questions are important to run through your head (as well as others I've missed) and you should be realistic with your expectations. This isn't to say you should pad your estimates to give yourself a lot more time, but instead understand that giving accurate estimates can effect the direction that the project manager will take and will likely affect the direction of other tasks (and dependencies) based on your estimates.
One of the things that is worthwhile, is to document your estimates on everything you work on (both professional and at home) and keep track of how close you are to your estimates. The only real way of getting good at estimating is to do a lot of them.
Scotty also has important advice, that it is more important to deliver within the time you have given than it is to be constantly late.
It is important to give accurate estimates, but unless you are Geordi La Forge, you will likely make mistakes on your estimates. Once you have given your word on an estimate, you are responsible. Often this can have a cascading effect, where promises can be made on delivery dates that are now based on your estimate. Be careful with your estimates, it is better to deliver ahead of schedule than behind it, although right on schedule is obviously the best. Research your estimates always, and sometimes they will shift the course of the project.
From another episode "The Ensigns of Command" Season 3, Episode 2:
Riker: Gentlemen, we're giving you an assignment. The one thing we don't want to hear is that it's impossible.
Picard: I need the transporters to function, despite the hyperonic radiation.
La Forge: Yeah, but that's imp... Yes, sir.
Wesley Crusher: He wants the impossible!
La Forge: That's the short definition of 'captain'.
La Forge: Captain - we can do it. We can modify the transporters.
Picard: Excellent.
La Forge: It'll take fifteen years and a research team of a hundred...
Picard: Mr. La Forge... I believe we will postpone.
It would be really great if all my blog posts were related to TNG episodes :P
Engage,
Michael Hubbard
http://michaelhubbard.ca
Scotty: "Do you mind a little advice? Starfleet captains are like children, they want everything right now, and they want it their way. But the secret is to give them only what they need, not what they want."
La Forge: "Yeah, well I told the captain I would have this analysis done in an hour."
Scotty: "How long will it really take?"
La Forge: "An hour."
Scotty: "Oh, you didn't tell him how long it would REALLY take did you?"
La Forge: "Of course I did."
Scotty: "Oh laddy, you've got a lot to learn if you want people to think of you as a miracle worker..."
So, you have a task to do. How long does it take? The boss wants it done ASAP, you of course want to deliver it with the right estimate.
How best to estimate how long it will REALLY take?
Is it like anything that you have done before?
Do you have to learn anything?
How many unknowns in the specification?
How big is the scope of the project?
How many people have to interact with finishing the task?
How complex is the task?
What dependencies (if any) do you have for finishing the task?
How many other tasks do you have to handle simultaneously?
Is it something new, or something you have to build on?
All of these questions are important to run through your head (as well as others I've missed) and you should be realistic with your expectations. This isn't to say you should pad your estimates to give yourself a lot more time, but instead understand that giving accurate estimates can effect the direction that the project manager will take and will likely affect the direction of other tasks (and dependencies) based on your estimates.
One of the things that is worthwhile, is to document your estimates on everything you work on (both professional and at home) and keep track of how close you are to your estimates. The only real way of getting good at estimating is to do a lot of them.
Scotty also has important advice, that it is more important to deliver within the time you have given than it is to be constantly late.
It is important to give accurate estimates, but unless you are Geordi La Forge, you will likely make mistakes on your estimates. Once you have given your word on an estimate, you are responsible. Often this can have a cascading effect, where promises can be made on delivery dates that are now based on your estimate. Be careful with your estimates, it is better to deliver ahead of schedule than behind it, although right on schedule is obviously the best. Research your estimates always, and sometimes they will shift the course of the project.
From another episode "The Ensigns of Command" Season 3, Episode 2:
Riker: Gentlemen, we're giving you an assignment. The one thing we don't want to hear is that it's impossible.
Picard: I need the transporters to function, despite the hyperonic radiation.
La Forge: Yeah, but that's imp... Yes, sir.
Wesley Crusher: He wants the impossible!
La Forge: That's the short definition of 'captain'.
La Forge: Captain - we can do it. We can modify the transporters.
Picard: Excellent.
La Forge: It'll take fifteen years and a research team of a hundred...
Picard: Mr. La Forge... I believe we will postpone.
It would be really great if all my blog posts were related to TNG episodes :P
Engage,
Michael Hubbard
http://michaelhubbard.ca
Sunday, January 16, 2011
Deadlines in a crunch
Deadlines are like dominos. If you miss one, it can cascade to all the other following deadlines making it very difficult to catch up. You need to stop this from happening, immediately. If you do not catch up, it can be very difficult, or even impossible, to get on track, and you can end up being stuck in a perpetual crunch if the deadlines are always falling behind.
If the deadlines are always impossible to acheive there is a good chance that the initial estimates were not correct. How to correct this? In an agile environment where the team creates the task list for the coming weeks it can quickly be amendend to allow for time to fix the deadlines. Hopefully you find yourself in this situation, but if you are in a crunch you need to merge the deadlines together to allow any traction you have in other areas to catch up for this.
Get rid of demos, there is no time for throw away code.
Get rid of presentations for anyone involved in getting the project out the door.
Lock down everything, no feature creep, no requirement changes.
Get QA to test the daily build, anything older is a waste of time to test.
Avoid creating tools, if you don't have it now, they will have to wait.
Always try and avoid creating "throw away" code, if you are having to maintain the code or build off it, you should always do things right, it will always save you time. In a crunch it is easy to want to hack. If you really have to, make sure you document every hack with a prefix like "HACK_" infront of every variable and function that you create. At least if you do this you should be able to find these easily, and hopefully clean this up if you have time (although realistically you won't have time).
Just do your best to get it done, but there will be more code than you will have time to do. During this time the quality will go way down, and management pressures will likely push the quality even lower. You will be tired, you will not be at your best, maintenance will be difficult, but with a lot of luck you can get it out the door with minimal hacks.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
If the deadlines are always impossible to acheive there is a good chance that the initial estimates were not correct. How to correct this? In an agile environment where the team creates the task list for the coming weeks it can quickly be amendend to allow for time to fix the deadlines. Hopefully you find yourself in this situation, but if you are in a crunch you need to merge the deadlines together to allow any traction you have in other areas to catch up for this.
Get rid of demos, there is no time for throw away code.
Get rid of presentations for anyone involved in getting the project out the door.
Lock down everything, no feature creep, no requirement changes.
Get QA to test the daily build, anything older is a waste of time to test.
Avoid creating tools, if you don't have it now, they will have to wait.
Always try and avoid creating "throw away" code, if you are having to maintain the code or build off it, you should always do things right, it will always save you time. In a crunch it is easy to want to hack. If you really have to, make sure you document every hack with a prefix like "HACK_" infront of every variable and function that you create. At least if you do this you should be able to find these easily, and hopefully clean this up if you have time (although realistically you won't have time).
Just do your best to get it done, but there will be more code than you will have time to do. During this time the quality will go way down, and management pressures will likely push the quality even lower. You will be tired, you will not be at your best, maintenance will be difficult, but with a lot of luck you can get it out the door with minimal hacks.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Friday, January 14, 2011
Choosing a Game Engine for a Project
So, you have a new project, lots of shiny new game engines abound, but which one to choose?
Forget the marketing, forget the bells and whistles, forget the hype. Instead get down to the basics.
1. What do your people know? Learning a new engine is time consuming, and without experts there will be numerous "gotchas" that can crop up in even the most tried and tested engines (someone will say "you need to do it the ____ way"). If you have to hire new people, make sure there is a market for those and the budget to get some expert skill level. This can be the biggest hurdle, and often the reason that you may not be able to go with the newest engine. Having a good community that supports the engine is also important.
2. Does the engine do everything you need? Does it really? Really, really? Doing your homework on what the engine can and can't do comes back to the first point. If you don't know what the engine is capable of, you should reach out to as many people as possible to get real experience with that engine.
3. Look at the history of the engine. What kind of games have been created with the engine? What kind of timeline, investment and skill set did it require to accomplish this? A game engine is not going to do everything for you, and knowing what developers, level designers, pipeline and server developers need to do to interact with the engine will let you know approximately what the engine can do.
4. How "unique" is your game? This is often a deal breaker for which engine to choose. If you are trying something that has never been done before, or has a high level of customization of different parts, you will likely hit a wall (in some engines sooner than others) where completing that task the "right" way can not be accomplished because of restrictions on the APIs the game engine provides. If you need to do things like access internal buffers, memory or anything else to accomplish your task, make sure your engine supports this flexibility. Unfortunately these kinds of requirements happen too late, but being aware of these kinds of issues will help you choose a flexible engine.
5. Where (and on what) is your game going to run? If the engine does not support multiple platforms this can be a significant amount of effort to port over to other operating systems. Some things can port easier than others, but each platform that needs to be supported will complicate the code base.
6. Do you have the source code? It is great to have the source in order to control your own destiny (although be sure to read the license agreement), but some game engine source code is not meant for public consumption. Often times the internal workings of the game engine are very difficult to modify or extend, and touching one line of source code will make merging future updates to the engine from the distributor one more complex task to manage. Open source game engines are pretty good, but they are still a bit behind the leading engines.
There is no "perfect" engine, all have strengths and weaknesses, all can make great or bad games. Be careful with this decision though, as it can be one of the biggest decisions for the path and people that work on your game.
Good luck and do your homework,
Michael Hubbard
http://michaelhubbard.ca
Forget the marketing, forget the bells and whistles, forget the hype. Instead get down to the basics.
1. What do your people know? Learning a new engine is time consuming, and without experts there will be numerous "gotchas" that can crop up in even the most tried and tested engines (someone will say "you need to do it the ____ way"). If you have to hire new people, make sure there is a market for those and the budget to get some expert skill level. This can be the biggest hurdle, and often the reason that you may not be able to go with the newest engine. Having a good community that supports the engine is also important.
2. Does the engine do everything you need? Does it really? Really, really? Doing your homework on what the engine can and can't do comes back to the first point. If you don't know what the engine is capable of, you should reach out to as many people as possible to get real experience with that engine.
3. Look at the history of the engine. What kind of games have been created with the engine? What kind of timeline, investment and skill set did it require to accomplish this? A game engine is not going to do everything for you, and knowing what developers, level designers, pipeline and server developers need to do to interact with the engine will let you know approximately what the engine can do.
4. How "unique" is your game? This is often a deal breaker for which engine to choose. If you are trying something that has never been done before, or has a high level of customization of different parts, you will likely hit a wall (in some engines sooner than others) where completing that task the "right" way can not be accomplished because of restrictions on the APIs the game engine provides. If you need to do things like access internal buffers, memory or anything else to accomplish your task, make sure your engine supports this flexibility. Unfortunately these kinds of requirements happen too late, but being aware of these kinds of issues will help you choose a flexible engine.
5. Where (and on what) is your game going to run? If the engine does not support multiple platforms this can be a significant amount of effort to port over to other operating systems. Some things can port easier than others, but each platform that needs to be supported will complicate the code base.
6. Do you have the source code? It is great to have the source in order to control your own destiny (although be sure to read the license agreement), but some game engine source code is not meant for public consumption. Often times the internal workings of the game engine are very difficult to modify or extend, and touching one line of source code will make merging future updates to the engine from the distributor one more complex task to manage. Open source game engines are pretty good, but they are still a bit behind the leading engines.
There is no "perfect" engine, all have strengths and weaknesses, all can make great or bad games. Be careful with this decision though, as it can be one of the biggest decisions for the path and people that work on your game.
Good luck and do your homework,
Michael Hubbard
http://michaelhubbard.ca
Thursday, January 13, 2011
Book Review: Focus on 3D Terrain Programming
Short and to the point, Focus on 3D Terrain Programming by Trent Polack is a good introduction to some of the algorithms used for 3D terrains. The book works well in introducing the simplest forms and growing more and more complex. Starting with a simple brute force algorithm, it covers terrain generation of fractal terrain, geo-mipmapping and culling, creating a quadtree terrain engine, ROAM (Realtime Optimally Adapting Meshes) with some optimizations as well.
Along with the terrain it also covers loading and creating texture files associated with terrain including texture map generation, using detail maps, and light maps.
There are also a few lighting techniques: height based lighting, slope lighting and some simple graphics fx for water, skyboxes and skydomes, particles etc.
This is more of a focused primer, but really the source code is what makes this book really standout. The code is very well commented, and easy to understand, which works handily with the descriptions in the book.
All in all, if you haven't worked with terrains before this is a good starting point, with lots of C++ examples to learn from.
Best of luck building,
Michael Hubbard
http://michaelhubbard.ca
Along with the terrain it also covers loading and creating texture files associated with terrain including texture map generation, using detail maps, and light maps.
There are also a few lighting techniques: height based lighting, slope lighting and some simple graphics fx for water, skyboxes and skydomes, particles etc.
This is more of a focused primer, but really the source code is what makes this book really standout. The code is very well commented, and easy to understand, which works handily with the descriptions in the book.
All in all, if you haven't worked with terrains before this is a good starting point, with lots of C++ examples to learn from.
Best of luck building,
Michael Hubbard
http://michaelhubbard.ca
Sunday, January 9, 2011
Dunning-Kruger effect
The worst part about a crunch is the toll it takes on the people. Everyone starts to get tired and cranky (shame programmers don't have cheerleaders). Anyway, for whatever reason my mind wandered over to the Dunning-Kruger effect taken from wikipedia (I know I know, I will try and find a better site for sourcing): http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
The Dunning–Kruger effect is a cognitive bias in which unskilled people make poor decisions and reach erroneous conclusions, but their incompetence denies them the meatcognitive ability to appreciate their mistakes. The unskilled therefore suffer from illusory superiority, rating their ability as above average, much higher than it actually is, while the highly skilled underrate their own abilities, suffering from illusory inferiority. Actual competence may weaken self-confidence, as competent individuals may falsely assume that others have an equivalent understanding. As Kruger and Dunning conclude, "the miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others"
A lot of attitudes come out of a crunch, more often than not poor attitudes, with people being "thrown under the bus" or "getting yelled at". It is sad really, but such is the nature of business. The Dunning-Kruger effect is important to think about, during this time, as everyone seems to have an opinion at these times. However, it is also important to consider this related to your own abilities.
How much do you know about a subject? It has been suggested that it requires around 10,000 hours for mastering something (which in most cases is ~10 years). The game dev community is fairly young, and finding a lot of people with 10+ years in a specific field is rare, couple that with the enormous amount of research and different elements that game dev and tech art consists of and you will never find someone who has mastered it all. I always like to compare know-it-alls to the socratic intelligence, where claiming to know nothing is considered the greatest intelligence:
"I know that I know nothing"
Social gadfly · Trial of Socrates
This is a much better attitude in my opinion, as it leaves you open to possibilities that you never would have considered before. It can get a little cheesy if you take it too far, but still it is good to consider all options and occassionally the source of opinions too.
Do I know that I know nothing?
Michael Hubbard
http://michaelhubbard.ca
The Dunning–Kruger effect is a cognitive bias in which unskilled people make poor decisions and reach erroneous conclusions, but their incompetence denies them the meatcognitive ability to appreciate their mistakes. The unskilled therefore suffer from illusory superiority, rating their ability as above average, much higher than it actually is, while the highly skilled underrate their own abilities, suffering from illusory inferiority. Actual competence may weaken self-confidence, as competent individuals may falsely assume that others have an equivalent understanding. As Kruger and Dunning conclude, "the miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others"
A lot of attitudes come out of a crunch, more often than not poor attitudes, with people being "thrown under the bus" or "getting yelled at". It is sad really, but such is the nature of business. The Dunning-Kruger effect is important to think about, during this time, as everyone seems to have an opinion at these times. However, it is also important to consider this related to your own abilities.
How much do you know about a subject? It has been suggested that it requires around 10,000 hours for mastering something (which in most cases is ~10 years). The game dev community is fairly young, and finding a lot of people with 10+ years in a specific field is rare, couple that with the enormous amount of research and different elements that game dev and tech art consists of and you will never find someone who has mastered it all. I always like to compare know-it-alls to the socratic intelligence, where claiming to know nothing is considered the greatest intelligence:
"I know that I know nothing"
Social gadfly · Trial of Socrates
This is a much better attitude in my opinion, as it leaves you open to possibilities that you never would have considered before. It can get a little cheesy if you take it too far, but still it is good to consider all options and occassionally the source of opinions too.
Do I know that I know nothing?
Michael Hubbard
http://michaelhubbard.ca
Friday, January 7, 2011
Crunch together
A team in crunch has a good chance of jelling, it is often during this time that a team can really learn more about each other and bond. Working long hours after many of the other employees have gone home does not feel quite so bad when you are not alone. It gives a better feeling of teamwork if you are all sitting together working away, bouncing ideas of one another and helping solve problems that is often more personal than during the regular work day.
This time can often generate some great war stories, I remember at a previous company one time another developer and I stayed up until 2 am Saturday night (Sunday morning) working away on some sync server integration. After banging our head against the wall of a server call that was blocking us, we went to the Subway for a midnight snack. When we came back, I began hacking into some server code (totally different language and code base than what we were working on) and hooked it up to give us the parameters we needed for syncing game elements so we could continue working. It was a lot of fun, and gave a great sense of accomplishment and while it was modified and properly "fixed" by one of the other server programmers the following Monday, it was great to remove the blockage to allow us to continue working and was rewarding to overcome these kinds of challenges together.
Until next time, try not to work too hard,
Michael Hubbard
http://michaelhubbard.ca
This time can often generate some great war stories, I remember at a previous company one time another developer and I stayed up until 2 am Saturday night (Sunday morning) working away on some sync server integration. After banging our head against the wall of a server call that was blocking us, we went to the Subway for a midnight snack. When we came back, I began hacking into some server code (totally different language and code base than what we were working on) and hooked it up to give us the parameters we needed for syncing game elements so we could continue working. It was a lot of fun, and gave a great sense of accomplishment and while it was modified and properly "fixed" by one of the other server programmers the following Monday, it was great to remove the blockage to allow us to continue working and was rewarding to overcome these kinds of challenges together.
Until next time, try not to work too hard,
Michael Hubbard
http://michaelhubbard.ca
Wednesday, January 5, 2011
Crunch
Crunch, overtime, force-overtime, deathmarch. Call it what you want, no one likes it, no one wants it, and yet it seems to happen in far too many places, and far too often (will have to read that Deathmarch book soon I think).
So, how do you deal with significant amount of overtime? Well, hopefully, you are doing something fun, like a cool game, animation, film or whatever project that you are excited to go to work for, and that will get you by for a little while (if you are lucky for the remainder of the crunch). Either way here are a few tips that I have come up with, that may help you too.
1. Eat: if all you are thinking about is how hungry you are, you are not thinking about how to solve that complex problem. Eating will also give you a bit of a break, hopefully a chance to talk to a few other tired soliders about their battles, and gives your body extra energy for the next attack (managers you should be getting food for your team, variety is nice, try and get from as many different places as possible, eating pizza everyday is only fun for the first week). Oh, and yes you will gain weight during the crunch :P
2. Drink: avoid overdoing too much caffeine (use sparingly or save it for the final few days, if you need it). Too often, people ramp up too fast and can't maintain the pace. Go slow, drink lots of water as well as some other things (I like green tea, but go with whatever you like (I like energy drinks occassionally too, but use in moderation)). Remember, this isn't a sprint, this is a marathon.
3. Call your loved ones: you won't be seeing them very much, so try and call them during your lunch break or whenever you get a chance during the day, and make sure you do it, and be consistent. Too often it is easy to get wrapped up in the world of the job, but while it is taking all the time of your current life, don't let it take your future life too (a project should success should not be measured by number of divorce papers, heart breaks and forgotten kids).
4. Take some breaks: get up, walk around, stretch, do some pushups (or consider doing some pushups) to ward of some of the pizza, grab another cup of coffee or tea or water. All this sitting and you will be getting tired, having a quick break and tiny use of energy will still let your brain think on the backburner while giving your body a chance to adjust and feel more alive. Whenever you get really stuck and have been stuck for a long time, get up and take a break.
5. Sleep: you will not be able to do all the things you like to do during a crunch period. Instead, focus on getting some sleep when you get home. If you are lucky, you will have someone else who can help with things (clean laundry is nice), but only focus on the essentials and be sure to sleep as much as you can (you are taxing your body and will need the recovery time).
6. Take a weekend: sometimes things will pile up (laundry?) that you will need to take care of them. You should try and take one weekend a week if possible, or at least half a day on the weekend to see those people you have been calling, and take some personal time.
7. Try and do some work from home: if possible working from home will help, you won't be as productive or have as much team building as you would at the office, but you will at least be able to help around the house if necessary and see those people you haven't for a while.
8. Keep track of your time: it is worth knowing how much time you put in. This is time you are unlikely to get back (hopefully you will get some undertime or lieu days) but it becomes far more important for future project planning. When someone says, of course you can get that done in a month you can say no, actually it took four, 70-hour weeks to accomplish, which is more like seven, 40-hour weeks to finish, which becomes a huge difference.
All in all, crunch is usually something that should be minimized (in my experience, 3-weeks of hard straight crunch is usually about most people's limit). Extended crunch for months on end becomes a death march, and often it is not just the project that is in danger, but also keeping the team intact.
Best of luck in the crunch,
Michael Hubbard
http://michaelhubbard.ca
So, how do you deal with significant amount of overtime? Well, hopefully, you are doing something fun, like a cool game, animation, film or whatever project that you are excited to go to work for, and that will get you by for a little while (if you are lucky for the remainder of the crunch). Either way here are a few tips that I have come up with, that may help you too.
1. Eat: if all you are thinking about is how hungry you are, you are not thinking about how to solve that complex problem. Eating will also give you a bit of a break, hopefully a chance to talk to a few other tired soliders about their battles, and gives your body extra energy for the next attack (managers you should be getting food for your team, variety is nice, try and get from as many different places as possible, eating pizza everyday is only fun for the first week). Oh, and yes you will gain weight during the crunch :P
2. Drink: avoid overdoing too much caffeine (use sparingly or save it for the final few days, if you need it). Too often, people ramp up too fast and can't maintain the pace. Go slow, drink lots of water as well as some other things (I like green tea, but go with whatever you like (I like energy drinks occassionally too, but use in moderation)). Remember, this isn't a sprint, this is a marathon.
3. Call your loved ones: you won't be seeing them very much, so try and call them during your lunch break or whenever you get a chance during the day, and make sure you do it, and be consistent. Too often it is easy to get wrapped up in the world of the job, but while it is taking all the time of your current life, don't let it take your future life too (a project should success should not be measured by number of divorce papers, heart breaks and forgotten kids).
4. Take some breaks: get up, walk around, stretch, do some pushups (or consider doing some pushups) to ward of some of the pizza, grab another cup of coffee or tea or water. All this sitting and you will be getting tired, having a quick break and tiny use of energy will still let your brain think on the backburner while giving your body a chance to adjust and feel more alive. Whenever you get really stuck and have been stuck for a long time, get up and take a break.
5. Sleep: you will not be able to do all the things you like to do during a crunch period. Instead, focus on getting some sleep when you get home. If you are lucky, you will have someone else who can help with things (clean laundry is nice), but only focus on the essentials and be sure to sleep as much as you can (you are taxing your body and will need the recovery time).
6. Take a weekend: sometimes things will pile up (laundry?) that you will need to take care of them. You should try and take one weekend a week if possible, or at least half a day on the weekend to see those people you have been calling, and take some personal time.
7. Try and do some work from home: if possible working from home will help, you won't be as productive or have as much team building as you would at the office, but you will at least be able to help around the house if necessary and see those people you haven't for a while.
8. Keep track of your time: it is worth knowing how much time you put in. This is time you are unlikely to get back (hopefully you will get some undertime or lieu days) but it becomes far more important for future project planning. When someone says, of course you can get that done in a month you can say no, actually it took four, 70-hour weeks to accomplish, which is more like seven, 40-hour weeks to finish, which becomes a huge difference.
All in all, crunch is usually something that should be minimized (in my experience, 3-weeks of hard straight crunch is usually about most people's limit). Extended crunch for months on end becomes a death march, and often it is not just the project that is in danger, but also keeping the team intact.
Best of luck in the crunch,
Michael Hubbard
http://michaelhubbard.ca
Saturday, January 1, 2011
Happy New Year
Happy 2011, how time flies. Hopefully I can get on here more with something cool.
Some blog related New Years Resolutions:
- Blog about cool (cooler?) things
- Update my website http://michaelhubbard.ca
- Try and get some more demos in the blog and code snippits.
- Explore more programming techniques, managment, graphics and more.
Lets see if I can make some of them work :)
Have a great year,
Michael Hubbard
http://michaelhubbard.ca
Some blog related New Years Resolutions:
- Blog about cool (cooler?) things
- Update my website http://michaelhubbard.ca
- Try and get some more demos in the blog and code snippits.
- Explore more programming techniques, managment, graphics and more.
Lets see if I can make some of them work :)
Have a great year,
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)