Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 19, 2018
arrowPress Releases
  • Editor-In-Chief:
    Kris Graft
  • Editor:
    Alex Wawro
  • Contributors:
    Chris Kerr
    Alissa McAloon
    Emma Kidwell
    Bryant Francis
    Katherine Cross
  • Advertising:
    Libby Kruse

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Opinion: Coder, Leave Your Ego At The Door

Opinion: Coder, Leave Your Ego At The Door

July 15, 2011 | By Amos Laber

Amos Laber, a senior Flex developer and consultant for LetoSoft Corporation, warns other coders about how their egos can affect coding and architectural decisions, in this #altdevblogaday-reprinted opinion piece.

One of the rules that I made for myself as a developer is not to get attached to my code. Really, we tend to love our creation once it takes shape, but I find that it can go too far and have negative effects on the job.This problem is less apparent with personal projects, more to do with projects I do for clients, typically within a team.

Almost anybody who does creative coding considers code as a craft, of fine art. It starts as a rough idea with a vision, and then you construct it piece-by-piece with careful attention, tackling problems during the process. Now you own that code, and over time you develop a sense of pride and confidence in the tools and techniques.

This is where things can go wrong. Pride and confidence boosts your ego, which can grow over time and cloud your judgment. I find it far too easy to cross the line from professional confidence to being defensive and territorial about a certain piece of code (or architecture), and eventually becoming over protective and standing guard against any changes.

In the life cycle of a project there is a point right after a stage is delivered and 'sealed' when developers tend to protect their creation. "Don't touch it," I tell my client, the risk of breaking functionality is too apparent. Is that being over protective, or simply good risk management?

Remember, any code has an expiring date. In our dynamic field, technologies change rapidly and what might have been cutting edge two to three years back can look ineffective today. Not to mention code that was not so good in the first place and contains many TODO comments and is still waiting to be replaced. Rewriting and refactoring is part of our reality as coders, and no code is perfect at least not for long.

Also, at some point any technology starts reaching its limits, and the existing code or framework simply does not support certain requested features. By then, the common line I give is "No, we can't do it that way". Oops. Line crossed. Managers never like to hear about things that can't be done, and rarely care about some technical mumbo-jumbo. By then, its not long before they lose respect for you and start looking for some other developers to do that job.

But there is a way out, or rather a way to avoid these kinds of situations.

Don't let your ego overtake your willingness to try new ideas keep a balance between what works now and what might be a good solution down the road. Start by not getting attached to your code, as beautiful as in may be, since it could always use some improvement. Seriously, don't fall in love with your code. The best way to prevent that is asking for ideas and criticism from within your team and being open to hearing their opinions. A fresh look can give new insights you never considered.

The same goes for entire technologies and frameworks. Being open to look at new technologies at all times to solve existing problems is always important. Try to be dynamic. Don't marry into a single platform or technology or you will probably end up being confined to its limits. Keep your eyes open for possible alternatives, and when the time comes, break free and move on.

I'd like to hear if other coders face the same problem. What is your approach?

[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]

Related Jobs

Velan Studios
Velan Studios — Troy, New York, United States

Lead Producer
Digital Extremes Ltd.
Digital Extremes Ltd. — London, Ontario, Canada

Environment Artist
Plarium Michigan Studio LP
Plarium Michigan Studio LP — Portage, Michigan, United States

Senior System Game Designer
Plarium Michigan Studio LP
Plarium Michigan Studio LP — Portage, Michigan, United States

Senior General Game Designer

Loading Comments

loader image