Crack - Yes, sarcasm I guess. The point was even if you think that since you want to be a designer or artist, you may not need to know math and physics, the truth is to be in games you do. Not to the level of a coder who works on the physics but math is the common language we use in every part of game work. So if you are comfortable with it, you will be much better off.
Stoic -
1. Having more education is never a bad thing. Particularly if you mix it up with some practical work like you are doing with your engine. I would say the response to a MFA in Interactive Media Design would be, what is that like? what did you do? And the answer you have is perfect, you wanted to learn to collaborate with artists and designers more and be more creative. The business is all about multi-discipline collaboration. That doesn't mean at a game company if you are hired as a coder, you will be doing art or design, but it means that you may know better how to work with a team. Show some results of your collaborations and you are good to go.
2. It is all important but the industry is getting more specialized. So there are roles for graphics and animation specialists, tools programmers, etc. As far as your game engine, being able to make tools that enable the art and design to move forward is a good thing. If you are really just trying to build up resume items, I wouldn't spend a ton of time making pretty UI controls unless that is the kind of work you want to do. But make the controls necessary for you to achieve what you want. On my tech demos, I did a lot of window dialog controls and such and that meant I could adjust things easily and show things off more than if I had arcane command line arguments. It sounds like you are interested in more of the overall game picture rather than the specific engine features. More of a gameplay programmer than a engine technology guy. So I would concentrate on tools and techniques to build on that part. And level editor type enhancements are a big part of that.
Question a grizzled and not yet bitter veteran
Jeff,
First off, much kudos for starting this thread :)
I've read through most of the question and answers and I do not think the topic of burn out has been covered. I'm a programmer and after speaking to some colleagues about my interests in game developing, I get the feeling that the industry is highly stressful considering that deadlines can make or break you. How accurate is it that a developer is forced to work 80 hour weeks and how cutthroat is the industry in terms of jumping through hoops to deliver the next big game hit? I'm familiar with the software development cycle, but with the work I do, we have our highs and lows so it's not necessary that I consistently put in more than 40 hours a week to meet a deadline.
Thanks for your time!
First off, much kudos for starting this thread :)
I've read through most of the question and answers and I do not think the topic of burn out has been covered. I'm a programmer and after speaking to some colleagues about my interests in game developing, I get the feeling that the industry is highly stressful considering that deadlines can make or break you. How accurate is it that a developer is forced to work 80 hour weeks and how cutthroat is the industry in terms of jumping through hoops to deliver the next big game hit? I'm familiar with the software development cycle, but with the work I do, we have our highs and lows so it's not necessary that I consistently put in more than 40 hours a week to meet a deadline.
Thanks for your time!
Quote:Original post by ezeke1
Jeff,
First off, much kudos for starting this thread :)
I've read through most of the question and answers and I do not think the topic of burn out has been covered. I'm a programmer and after speaking to some colleagues about my interests in game developing, I get the feeling that the industry is highly stressful considering that deadlines can make or break you. How accurate is it that a developer is forced to work 80 hour weeks and how cutthroat is the industry in terms of jumping through hoops to deliver the next big game hit? I'm familiar with the software development cycle, but with the work I do, we have our highs and lows so it's not necessary that I consistently put in more than 40 hours a week to meet a deadline.
Thanks for your time!
Personally I haven't seen a lot of companies putting/having to put in more than 40 hours and do have their highs and lows even in India. However I have seen people doing more than 40-50 hours and working like an ass even when they are asked to go home and rest. And in the end its their choice to work like a dog or give themselves required break on various occasions.
Hey Jeff,
For a long time now I've wanted to become a game programmer. I finally decided to get working on it and began to research what I would need for the job. What seems to be necessary is a very good knowledge of C/C++, advanced Math, and DirectX or OpenGL. Everything necessary for the job seems to be available in college, but I won't be going to college for a few years. (I'm 14)
First I wanted to know if you need to know both C and C++ (and which is commonly used more with companies), and also if you need to know both DirectX and OpenGL. Then I'll have something to start learning ahead of time. Thanks.
For a long time now I've wanted to become a game programmer. I finally decided to get working on it and began to research what I would need for the job. What seems to be necessary is a very good knowledge of C/C++, advanced Math, and DirectX or OpenGL. Everything necessary for the job seems to be available in college, but I won't be going to college for a few years. (I'm 14)
First I wanted to know if you need to know both C and C++ (and which is commonly used more with companies), and also if you need to know both DirectX and OpenGL. Then I'll have something to start learning ahead of time. Thanks.
Hey Jeff,
Which is better: a college that offers a 3 year game programming degree such as brown college or a college that offers a 4 year degree in computer programming. Or is this college specific.
Thanks
Which is better: a college that offers a 3 year game programming degree such as brown college or a college that offers a 4 year degree in computer programming. Or is this college specific.
Thanks
Hope Jeff doesn't mind if I weigh in a little [smile]
WRT 'game' colleges versus 'programming' colleges: I would recommend the general-purpose programming degrees over the gaming ones, partly because it gives you more of a safety net in case the industry doesn't work out for you (and it doesn't work out for many people), and partly because it gives you training in parts of computing that aren't currently significant within the games industry, but may well become so in the future. An example would be multithreading; a good established programming course will have a concurrent programming module and will have had it for decades. While a games course will probably have only introduced theirs in the last couple of years.
If the programming course is good, it'll give you the skills you need to understand game-specific techniques from books and articles without needing to have it taught to you. For example, you reach an understanding that spatial subdivision techniques are generally just a way of cutting down an algorithm's dataset, instead of them being some mystical key part of a graphics engine that you cannot live without.
WRT learning C versus C++: The language isn't that important. What is important is the conceptual stuff - many ideas show up in hundreds of languages, perhaps in slightly different layouts or colours but they're the same thing. If you understand all the common concepts, you can generally pick up any language in a matter of hours - after all, you don't need to memorize the language or anything, you'll do that anyway if you use it a lot but there's always reference works like MSDN if something slips your mind. The amount of stuff you "actually know" is not as important as an ability to find the things you don't know quickly and practically.
Same goes for DirectX versus OpenGL - it's the 3D math that's important, not the API. If you were to enter the industry as a console programmer you might not end using either of them anyway.
WRT 'game' colleges versus 'programming' colleges: I would recommend the general-purpose programming degrees over the gaming ones, partly because it gives you more of a safety net in case the industry doesn't work out for you (and it doesn't work out for many people), and partly because it gives you training in parts of computing that aren't currently significant within the games industry, but may well become so in the future. An example would be multithreading; a good established programming course will have a concurrent programming module and will have had it for decades. While a games course will probably have only introduced theirs in the last couple of years.
If the programming course is good, it'll give you the skills you need to understand game-specific techniques from books and articles without needing to have it taught to you. For example, you reach an understanding that spatial subdivision techniques are generally just a way of cutting down an algorithm's dataset, instead of them being some mystical key part of a graphics engine that you cannot live without.
WRT learning C versus C++: The language isn't that important. What is important is the conceptual stuff - many ideas show up in hundreds of languages, perhaps in slightly different layouts or colours but they're the same thing. If you understand all the common concepts, you can generally pick up any language in a matter of hours - after all, you don't need to memorize the language or anything, you'll do that anyway if you use it a lot but there's always reference works like MSDN if something slips your mind. The amount of stuff you "actually know" is not as important as an ability to find the things you don't know quickly and practically.
Same goes for DirectX versus OpenGL - it's the 3D math that's important, not the API. If you were to enter the industry as a console programmer you might not end using either of them anyway.
Author
I welcome the extra input Superpig. Getting multiple perspectives is very important. That said I agree with your advice completely :)
The language and APIs don't matter. It's knowing what they are used for and how. Likewise with regard to the schools. The only problem I have with some "game" programs is they tend to teach the tools rather than the actual education. This is a particular problem with art schools that say they will teach you Max and Photoshop before you graduate. But with programming also, they might teach you how to use GL or D3D but if you don't learn how a matrix and quaternion relate and when it is appropriate to use each, it is worthless.
I always say, we can teach you the tools, but it is much harder to teach math or strong art techniques and esthetics. You have to show up with those.
For school choice, find a program where they are doing something cool that you are interested in. That way your chances of staying through and really learning are better. A school with a program that turns out good research and students that do cool stuff is likely to really know what it takes to make it.
As to the question about crunch time. It happens, some places worse than others. If you find they ask too much and it seems unreasonable, there are lots of companies out there. The teams are learning they need to keep their people happy otherwise they are always rebuilding. So as the industry matures, I think you will find it continuing to improve.
The language and APIs don't matter. It's knowing what they are used for and how. Likewise with regard to the schools. The only problem I have with some "game" programs is they tend to teach the tools rather than the actual education. This is a particular problem with art schools that say they will teach you Max and Photoshop before you graduate. But with programming also, they might teach you how to use GL or D3D but if you don't learn how a matrix and quaternion relate and when it is appropriate to use each, it is worthless.
I always say, we can teach you the tools, but it is much harder to teach math or strong art techniques and esthetics. You have to show up with those.
For school choice, find a program where they are doing something cool that you are interested in. That way your chances of staying through and really learning are better. A school with a program that turns out good research and students that do cool stuff is likely to really know what it takes to make it.
As to the question about crunch time. It happens, some places worse than others. If you find they ask too much and it seems unreasonable, there are lots of companies out there. The teams are learning they need to keep their people happy otherwise they are always rebuilding. So as the industry matures, I think you will find it continuing to improve.
First off: thank you, Thank You, THANK YOU! This thread has been an absolutely wonderful source of information!
My question is very simple: what pet peeves/disappointments have you had with "fresh" programmers? What do/do-not's would you pass on to the next generation of "grizzled veteran" hopefulls?
My question is very simple: what pet peeves/disappointments have you had with "fresh" programmers? What do/do-not's would you pass on to the next generation of "grizzled veteran" hopefulls?
I'll take a leaf from superpig's book here and chime in briefly on that one. I'm not a grizzled veteran by any means... I guess a grizzled, well-broken-in newcomer perhaps [wink]
On our team at Egosoft I'm one of the more experienced coders, and I usually am the one who ends up helping the new mission script coders get oriented with our scripting technologies. Most of them don't end up doing anything, although a few have made some very noteworthy contributions, and one has gone on to secure a position along side the rest of us on the engine development team.
I think our particular situation is very pertinent to the folks here at GameDev, because the bulk of the Egosoft DevNet people that take up quest-writing are hobbyists and/or industry hopefuls. A few, like I once did, are coming to DevNet to try and get a foot in the door in the biz, but most are just there to chip in their small part in a game they enjoy.
Personally I try to supress bad stories, and most of what has happened can't be related without getting into NDA-land, so I don't have any anecdotes to share. I can, however, offer some tips to those who take volunteer/intern style jobs or are entry-level workers looking for a career in the industry. Most of this comes from the perspective of programmers, but the principles equally applicable to other skills as well.
Know Your Limits
It is vital that you know what you can and cannot do. Be careful to think about what you currently can't do but may be able to learn. If you need to learn something, be upfront about it. Always be straightforward and honest about your abilities and limitations, with yourself especially, and with your team members as well. One of the saddest things to watch is an enthusiastic, capable newcomer show up, get in over his head, get slapped on the wrist by the leads because he isn't pulling his weight, and eventually burn out and disappear. Any team worth their salt knows that you have to start someplace, and your team should be understanding. Even the most hardcore members have their limits. You can be far more valuable to your team if you aim for 100% of your abilities, but not 120%.
Show Initiative and Self-Motivation
Game development has a lot of unique and demanding challenges. Being a timid, by-the-book back-seater is likely to get you stuck in a back-end job, or even axed. Teams in crunch mode need people with initiative and drive. Be willing to make decisions when you have to, and take some risks. Push your own boundaries and help encourage your team to push theirs. Show willingness to learn new skills, handle things that nobody else is taking care of, and so on. Just know your limits, and make sure you inform others on your team of what you are doing; if you take a huge risk at the last minute and it ends up failing, you're in for a world of hurt.
If you see something that needs to be done, and nobody is doing it, offer to do it (assuming that doing so is within your limits). If you can't do it yourself, offer to coordinate an effort to find someone who can, and trade off jobs with them if needed.
A great way to do this is to collect proposals and ideas from your team members. Get the feedback and opinions of those on the team, and take it to your lead or manager. Write it up in a concise, easily-digested, and clear manner, and deliver it in the preferred cultural format (some places prefer hardcopy, others prefer email, etc.). Show that you are always interested in helping your whole team move forward, and that you are always looking to keep yourself challenged and working to the best of your potential.
Learn and Better Yourself Independently
The ability to study, research, and acquire new skills (or new levels of refinement in your existing skills) is vital to survival in the computer industry. However, you must be able to do this yourself, or at the very least with a small number of others who are at similar positions as yourself. Always seek to try and improve your own abilities, and add new ones; even better if they are outside of programming per se. Take up some hobbies, sports, whatever interests you. The broader abilities and mental perspectives (and, in the case of physical activity, improved health) will have direct benefits on your work. I must emphasize again that being able to do this yourself or with a few (two or three) people at your level is vital. If you have to constantly be in the presence of a guru to advance your skills, you're in trouble.
Defer to the Seniors
It's true that the young and idealistic often have a lot of good things to offer in the way of new ideas or concepts. (I'm prejudiced, being a young idealist myself.) However, the guys who have been doing this for 10 years are still around for a reason. The gurus and masters know their stuff, and it is important to pick your battles when idealism is in play. If you need to disagree with The Tradition, be sure to do so respectfully, and back up your arguments. The true masters are good enough to know when you have a point, and can be persuaded - but only if you don't piss them off.
Likewise, when decisions have been made, don't argue. Once a decision is in the field, debating it is almost always counterproductive. A good team will air out decisions and allow input before the decision is set in stone - that is the time to speak your mind. Once Those In Charge have spoken, though, it is your duty as Not The One In Charge to do what you're told.
As part of the above point, be respectful of the gurus and their time. If needed, arrange ways to have the gurus mentor you in a reliable and consistent way. Code reviews, pair programming, and other similar techniques are very good here. However, the gurus have lots to get done (probably more than you) so don't prod them if they are busy. Asking questions and needing to learn things is fine (in fact, needing to learn things, and wanting to do so, is essential) but pestering is not.
This also affects proposals. If you're going to find fault with Tradition, or if you're suggesting new/different ways of doing things, features, whatever, make sure you do so respectfully and diplomatically. As cheesy as it may sound, get some books on rhetoric and persuasive writing. Showing initiative is a good thing, but being able to do it in a way that is constructive (rather than "the way you do things sucks, I should be in charge") is what will really bring in the win.
Know When to Pull the Fire Alarm
This is a generally applicable thing to all jobs everywhere. Be aware of what you are doing, at all times. Think about what you do and why. Think about this on many levels; think about the way you write code (or do your daily work), and why. Think if there are any better ways to do it, or what problems you may be leaving yourself open to. Think about whether there are worse problems you may open up by doing it differently, and whether or not you should bother changing. If you suspect that change is needed, think about the best way to do so.
Think about what you eat for lunch and where. Are you constantly going to fast-food places and coming back to eat at your desk? You may have a bad lunch arrangement with your employer; think about asking to change it. (I've done that one in Real Life. My request was turned down; see below.) Think about how you sit, what you do with the stuff in your workspace. Think about your workspace and where it is, what shape it is, what it looks like. Think about your commute, your salary, your expected duties.
Think about the particulars of your tasks, and the general essence of your life. If you find problems, think about ways to fix them. You will find far more ways to show initiative than you can ever possibly handle yourself; find others who agree and set up coalitions to change things that need changing. Explore your environment. Take some chances and learn from your mistakes. Never let yourself become a mindless automaton; as soon as you stop being stimulated by your world, it's time to change something.
If you're out of practical changes to make, pull the fire alarm.
This may take one of many forms. It might mean writing a long list of grievances, collecting some signatures, and putting it on your boss's desk. It might mean simply taking some steps to fix things, and giving everyone else that little nudge to follow suit and adapt to the improved Way. It might mean quitting and moving on to something else.
Nothing is more destructive or wasteful than spending a lot of time on something that you can't enjoy. You owe it to yourself and your team to make things as good as you can for everyone involved. Challenge what needs to be challenged, and fix what's broken. Just be careful to know your limits, defer to senior wisdom, and don't panic.
Tales from the Trenches
I said I didn't have any anecdotes, but that was a few minutes ago, and I lied. We once had a promising modder join DevNet and offer to start working on game balancing. The design leads agreed to look at his work and see what could be done. A lot of fans enjoyed this particular guy's mod, so the look was a deep and careful one. In the end, none of it was used. Why? Because the guy was, to put it mildly and kindly, an arrogant pissant. The first thing he did was start a several-hour fight with some of the senior team members over the NDA, and created some severe fuss over how his work was used. Eventually, everyone got sick of him, and he got so fed up with the team leads not yielding to his narcissism that he took his ball and went home. He wasn't missed. The moral here is that, if you're in a position to contribute something to a team, just remember your place. If you aren't in charge, don't try to be. There's a difference between taking initiative and showing leadership, and being a self-absorbed idiot.
Another story involves a great guy who's still around. He has an IT job, and is quite competent, but isn't a programmer. He took an interest in writing missions for Egosoft. I took up my unwritten post as teacher, and set him out some projects. They went very well, and he did his best to learn on his own, although (being inexperienced in general) he needed a lot of Q&A time to really get things done. We did some fun code reviews, and generally had a grand old time. Eventually, we had his first mission mostly done and only a few minor tweaks away from being release-ready. Unfortunately, Real Life turned sour for him, and he ended up having to pull out. He had a several-week nightmare at a horrible job and ended up moving back to his original post, but not without taking a serious toll in energy and emotion. He still hasn't totally recovered as far as I know. His work wasn't able to be shipped in the final game.
The last tale is one of pulling a fire alarm.
A young contractor and general schmuck once decided he needed a job, full-time and permanently. He had a decent offer from a place he'd worked with before, and decided to take it; there were some perks that made it very worthwhile, and so he didn't even bother looking for other positions. One other offer came in, from a wholly unexpected source, right after he decided to sign the contract. Slightly torn, he decided to make the situation plain to both parties, and take a stab at doing both jobs, the second on an effectively part-time basis. He stuffed his worldly crap into his car and made the move.
Within a few months, he noticed that something didn't feel right. There'd been some minor friction with the employer before, but he'd figured it was just a side-effect of the contract nature of his previous work, and was hoping it would change. Some things did, and some did not. For a while, he wasn't really sure whether to voice his concerns, or simply suck it up and deal; after all, maybe it was his own problem, and he simply wasn't accepting the way things Had To Be.
Some things he tried to change. There were some practices and habits at the company that he worked on improving, to help him do his job better, and to help make sure the product was in better shape. Most of these things worked out great. Some of them had lifesaving effects on the overall direction of the product. But something else still wasn't right. The other job was becoming incredibly demanding, and he was coming in to work exhausted and cranky. Projects started to slide, and the all-too-familiar signs of depression started to eat at him.
On the second job, he was more or less fine; he liked what he was doing, was working with some great people on a very engaging project, and in general had a great arrangement. In the day, though, he lived through hell. One of his projects became a bona fide death march, extending several months past deadline and eventually being suspended to start work on another product. There was a little bit of enjoyment to be had in learning some new skills and technologies, but for the most part he was doing what felt to him like code monkey work.
The management, to their credit, was not fully unaware of what was going on. They definitely did some things to improve the situation, but it never seemed to be enough. There were some things they simply couldn't do, for practical and financial reasons, but some things were just ignored. A few things they just didn't feel were problems. Another project became a Death March, and was finally released; it was highly successful, but needed some desperate maintenance. Some hasty fixes were thrown together, and the product was left out for the wolves. Being on an unfamiliar technological base, the product was more or less a mystery to everyone at the company, and when esoteric problems arose, customers were simply told that they couldn't be helped. Being one of the two people in the company who had any serious experience on the platform, this distasteful duty often fell to him; customer calls would get escalated to the developers, and he'd have to turn them away empty-handed.
During this time, his second employer began making some very serious and tempting pleas to join them full time. The second job's project was in major crunch mode, and it was all-hands-on-deck. So one day he took The Bosses out to lunch (at the company's expense, natch) and informed them that he'd had an offer. What he said that day was that he was tempted. Deep down, he'd already made the decision. A few weeks later, he got around to saying it plainly: he was leaving for job number two.
He just didn't want to cut and run, though; he felt like he'd been given a good shot, and the counter-offers from Job Number One proved that The Bosses knew he was worth keeping around. Something still didn't feel right, though. After some serious soul-searching, and spending a lot of time reading, he figured out the problem.
He'd tried to pull the fire alarm. When he finally found the alarm, he'd had to go find a cutting torch to unseal the box. Then he had to find a pneumatic jack to actually dislodge the handle. Once the alarm starting ringing, it was no louder than the alarm on a digital wristwatch. Management, hearing someone's watch going off in the middle of an important meeting, politely asked him to turn it off.
So he pulled The Big Fire Alarm, and now he's moving on to Door Number Two. I'd like to think he learned some things, and that I've done a good job passing them on [wink]
On our team at Egosoft I'm one of the more experienced coders, and I usually am the one who ends up helping the new mission script coders get oriented with our scripting technologies. Most of them don't end up doing anything, although a few have made some very noteworthy contributions, and one has gone on to secure a position along side the rest of us on the engine development team.
I think our particular situation is very pertinent to the folks here at GameDev, because the bulk of the Egosoft DevNet people that take up quest-writing are hobbyists and/or industry hopefuls. A few, like I once did, are coming to DevNet to try and get a foot in the door in the biz, but most are just there to chip in their small part in a game they enjoy.
Personally I try to supress bad stories, and most of what has happened can't be related without getting into NDA-land, so I don't have any anecdotes to share. I can, however, offer some tips to those who take volunteer/intern style jobs or are entry-level workers looking for a career in the industry. Most of this comes from the perspective of programmers, but the principles equally applicable to other skills as well.
Know Your Limits
It is vital that you know what you can and cannot do. Be careful to think about what you currently can't do but may be able to learn. If you need to learn something, be upfront about it. Always be straightforward and honest about your abilities and limitations, with yourself especially, and with your team members as well. One of the saddest things to watch is an enthusiastic, capable newcomer show up, get in over his head, get slapped on the wrist by the leads because he isn't pulling his weight, and eventually burn out and disappear. Any team worth their salt knows that you have to start someplace, and your team should be understanding. Even the most hardcore members have their limits. You can be far more valuable to your team if you aim for 100% of your abilities, but not 120%.
Show Initiative and Self-Motivation
Game development has a lot of unique and demanding challenges. Being a timid, by-the-book back-seater is likely to get you stuck in a back-end job, or even axed. Teams in crunch mode need people with initiative and drive. Be willing to make decisions when you have to, and take some risks. Push your own boundaries and help encourage your team to push theirs. Show willingness to learn new skills, handle things that nobody else is taking care of, and so on. Just know your limits, and make sure you inform others on your team of what you are doing; if you take a huge risk at the last minute and it ends up failing, you're in for a world of hurt.
If you see something that needs to be done, and nobody is doing it, offer to do it (assuming that doing so is within your limits). If you can't do it yourself, offer to coordinate an effort to find someone who can, and trade off jobs with them if needed.
A great way to do this is to collect proposals and ideas from your team members. Get the feedback and opinions of those on the team, and take it to your lead or manager. Write it up in a concise, easily-digested, and clear manner, and deliver it in the preferred cultural format (some places prefer hardcopy, others prefer email, etc.). Show that you are always interested in helping your whole team move forward, and that you are always looking to keep yourself challenged and working to the best of your potential.
Learn and Better Yourself Independently
The ability to study, research, and acquire new skills (or new levels of refinement in your existing skills) is vital to survival in the computer industry. However, you must be able to do this yourself, or at the very least with a small number of others who are at similar positions as yourself. Always seek to try and improve your own abilities, and add new ones; even better if they are outside of programming per se. Take up some hobbies, sports, whatever interests you. The broader abilities and mental perspectives (and, in the case of physical activity, improved health) will have direct benefits on your work. I must emphasize again that being able to do this yourself or with a few (two or three) people at your level is vital. If you have to constantly be in the presence of a guru to advance your skills, you're in trouble.
Defer to the Seniors
It's true that the young and idealistic often have a lot of good things to offer in the way of new ideas or concepts. (I'm prejudiced, being a young idealist myself.) However, the guys who have been doing this for 10 years are still around for a reason. The gurus and masters know their stuff, and it is important to pick your battles when idealism is in play. If you need to disagree with The Tradition, be sure to do so respectfully, and back up your arguments. The true masters are good enough to know when you have a point, and can be persuaded - but only if you don't piss them off.
Likewise, when decisions have been made, don't argue. Once a decision is in the field, debating it is almost always counterproductive. A good team will air out decisions and allow input before the decision is set in stone - that is the time to speak your mind. Once Those In Charge have spoken, though, it is your duty as Not The One In Charge to do what you're told.
As part of the above point, be respectful of the gurus and their time. If needed, arrange ways to have the gurus mentor you in a reliable and consistent way. Code reviews, pair programming, and other similar techniques are very good here. However, the gurus have lots to get done (probably more than you) so don't prod them if they are busy. Asking questions and needing to learn things is fine (in fact, needing to learn things, and wanting to do so, is essential) but pestering is not.
This also affects proposals. If you're going to find fault with Tradition, or if you're suggesting new/different ways of doing things, features, whatever, make sure you do so respectfully and diplomatically. As cheesy as it may sound, get some books on rhetoric and persuasive writing. Showing initiative is a good thing, but being able to do it in a way that is constructive (rather than "the way you do things sucks, I should be in charge") is what will really bring in the win.
Know When to Pull the Fire Alarm
This is a generally applicable thing to all jobs everywhere. Be aware of what you are doing, at all times. Think about what you do and why. Think about this on many levels; think about the way you write code (or do your daily work), and why. Think if there are any better ways to do it, or what problems you may be leaving yourself open to. Think about whether there are worse problems you may open up by doing it differently, and whether or not you should bother changing. If you suspect that change is needed, think about the best way to do so.
Think about what you eat for lunch and where. Are you constantly going to fast-food places and coming back to eat at your desk? You may have a bad lunch arrangement with your employer; think about asking to change it. (I've done that one in Real Life. My request was turned down; see below.) Think about how you sit, what you do with the stuff in your workspace. Think about your workspace and where it is, what shape it is, what it looks like. Think about your commute, your salary, your expected duties.
Think about the particulars of your tasks, and the general essence of your life. If you find problems, think about ways to fix them. You will find far more ways to show initiative than you can ever possibly handle yourself; find others who agree and set up coalitions to change things that need changing. Explore your environment. Take some chances and learn from your mistakes. Never let yourself become a mindless automaton; as soon as you stop being stimulated by your world, it's time to change something.
If you're out of practical changes to make, pull the fire alarm.
This may take one of many forms. It might mean writing a long list of grievances, collecting some signatures, and putting it on your boss's desk. It might mean simply taking some steps to fix things, and giving everyone else that little nudge to follow suit and adapt to the improved Way. It might mean quitting and moving on to something else.
Nothing is more destructive or wasteful than spending a lot of time on something that you can't enjoy. You owe it to yourself and your team to make things as good as you can for everyone involved. Challenge what needs to be challenged, and fix what's broken. Just be careful to know your limits, defer to senior wisdom, and don't panic.
Tales from the Trenches
I said I didn't have any anecdotes, but that was a few minutes ago, and I lied. We once had a promising modder join DevNet and offer to start working on game balancing. The design leads agreed to look at his work and see what could be done. A lot of fans enjoyed this particular guy's mod, so the look was a deep and careful one. In the end, none of it was used. Why? Because the guy was, to put it mildly and kindly, an arrogant pissant. The first thing he did was start a several-hour fight with some of the senior team members over the NDA, and created some severe fuss over how his work was used. Eventually, everyone got sick of him, and he got so fed up with the team leads not yielding to his narcissism that he took his ball and went home. He wasn't missed. The moral here is that, if you're in a position to contribute something to a team, just remember your place. If you aren't in charge, don't try to be. There's a difference between taking initiative and showing leadership, and being a self-absorbed idiot.
Another story involves a great guy who's still around. He has an IT job, and is quite competent, but isn't a programmer. He took an interest in writing missions for Egosoft. I took up my unwritten post as teacher, and set him out some projects. They went very well, and he did his best to learn on his own, although (being inexperienced in general) he needed a lot of Q&A time to really get things done. We did some fun code reviews, and generally had a grand old time. Eventually, we had his first mission mostly done and only a few minor tweaks away from being release-ready. Unfortunately, Real Life turned sour for him, and he ended up having to pull out. He had a several-week nightmare at a horrible job and ended up moving back to his original post, but not without taking a serious toll in energy and emotion. He still hasn't totally recovered as far as I know. His work wasn't able to be shipped in the final game.
The last tale is one of pulling a fire alarm.
A young contractor and general schmuck once decided he needed a job, full-time and permanently. He had a decent offer from a place he'd worked with before, and decided to take it; there were some perks that made it very worthwhile, and so he didn't even bother looking for other positions. One other offer came in, from a wholly unexpected source, right after he decided to sign the contract. Slightly torn, he decided to make the situation plain to both parties, and take a stab at doing both jobs, the second on an effectively part-time basis. He stuffed his worldly crap into his car and made the move.
Within a few months, he noticed that something didn't feel right. There'd been some minor friction with the employer before, but he'd figured it was just a side-effect of the contract nature of his previous work, and was hoping it would change. Some things did, and some did not. For a while, he wasn't really sure whether to voice his concerns, or simply suck it up and deal; after all, maybe it was his own problem, and he simply wasn't accepting the way things Had To Be.
Some things he tried to change. There were some practices and habits at the company that he worked on improving, to help him do his job better, and to help make sure the product was in better shape. Most of these things worked out great. Some of them had lifesaving effects on the overall direction of the product. But something else still wasn't right. The other job was becoming incredibly demanding, and he was coming in to work exhausted and cranky. Projects started to slide, and the all-too-familiar signs of depression started to eat at him.
On the second job, he was more or less fine; he liked what he was doing, was working with some great people on a very engaging project, and in general had a great arrangement. In the day, though, he lived through hell. One of his projects became a bona fide death march, extending several months past deadline and eventually being suspended to start work on another product. There was a little bit of enjoyment to be had in learning some new skills and technologies, but for the most part he was doing what felt to him like code monkey work.
The management, to their credit, was not fully unaware of what was going on. They definitely did some things to improve the situation, but it never seemed to be enough. There were some things they simply couldn't do, for practical and financial reasons, but some things were just ignored. A few things they just didn't feel were problems. Another project became a Death March, and was finally released; it was highly successful, but needed some desperate maintenance. Some hasty fixes were thrown together, and the product was left out for the wolves. Being on an unfamiliar technological base, the product was more or less a mystery to everyone at the company, and when esoteric problems arose, customers were simply told that they couldn't be helped. Being one of the two people in the company who had any serious experience on the platform, this distasteful duty often fell to him; customer calls would get escalated to the developers, and he'd have to turn them away empty-handed.
During this time, his second employer began making some very serious and tempting pleas to join them full time. The second job's project was in major crunch mode, and it was all-hands-on-deck. So one day he took The Bosses out to lunch (at the company's expense, natch) and informed them that he'd had an offer. What he said that day was that he was tempted. Deep down, he'd already made the decision. A few weeks later, he got around to saying it plainly: he was leaving for job number two.
He just didn't want to cut and run, though; he felt like he'd been given a good shot, and the counter-offers from Job Number One proved that The Bosses knew he was worth keeping around. Something still didn't feel right, though. After some serious soul-searching, and spending a lot of time reading, he figured out the problem.
He'd tried to pull the fire alarm. When he finally found the alarm, he'd had to go find a cutting torch to unseal the box. Then he had to find a pneumatic jack to actually dislodge the handle. Once the alarm starting ringing, it was no louder than the alarm on a digital wristwatch. Management, hearing someone's watch going off in the middle of an important meeting, politely asked him to turn it off.
So he pulled The Big Fire Alarm, and now he's moving on to Door Number Two. I'd like to think he learned some things, and that I've done a good job passing them on [wink]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement