This is why I don’t want employees…

It’s something that one of my mentors says a lot. “Employees are people who come to work late, leave early and steal while they’re there. I don’t want employees. I want team members. I want teammates. People who are committed. People who are all in. People who want to be here. People who have to be reminded to go home at the end of the day.”

GDC Plans

Nothing personal, Jeremy and Mike, but the attitude in this comic irks me. I get the attempt at humor and maybe you need to look for somewhere to work where you won’t feel that way… It’s certainly not what I’m looking for in future teammates.

Amusing, but accurate, code quality metric

In a code review, the lower the number of WTFs/minute is as good a metric as any other. The highlighting in the quote below is mine.

Which appears facetious at first, but perhaps hints at a deeper truth: high quality code should not surprise us; we should be able to quickly and easily discern the structure and intent of the code. But doesn’t this then place software quality in the eyes of the beholder? What if the person evaluating the code isn’t familiar with the patterns used by the original developer? (Or – to be more cruel – what if they just aren’t competent enough to recognize the patterns used?) Are they not likely to harshly judge the code based on miscomprehension? (A similar suggestion to this measure is that software quality is inversely related to the amount of time required to make a modification; again the major problem with this is that it depends on the capability of the person making the change).

On Code Quality « Project ogsa-dai

Too many developers are overly impressed with their own cleverness. I’ve found this more often in “classically trained” developers than self-taught developers, and I’ve found it in myself, too. Regardless the source, resist the temptation to implement cleverly… you’ll wind up writing bugs you can’t fix. Ask me how I know. Heh.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

"The Elements of Programming Style", 2nd edition, chapter 2, by Brian Kernighan

Not a good plan. A better plan (to paraphrase Einstein) is to write the simplest code possible, but no simpler.

Where did the first quarter go?!

Last time I looked up, we had an ambitious plan for the first quarter of 2011…

Hrm. I’ve learned some important lessons as 1Q11 flew by. The most important of those lessons is that we need a new plan. Heh. Also, I’ve [re]learned that it’s important to have flexible goals and flexible priorities. More on that in the coming days/weeks/months/years.

One of my “plans” that I have been keeping up with (unlike blogging) has been reading what other people have to say on the subject of training and hiring. I like what Peter has to say in this post:

I think many skills can be learned outside of school and the quality of a programmer has more to do with determination and time spent practicing their trade every day and spending time constantly learning. Sometimes education is a crutch that people know they can fall on and they become lazy. Whereas those who don’t have that degree are incentivized to spend much more time and effort honing their trade which can make them better in the long run. I see these two situations happen all the time.

Self-Taught Programmers vs CS-Educated Programmers – Adventures in Entrepreneurship

Wish I would’ve read that post in January…

Every. Single. Day.

This post has been percolating in the back of my head for the past week since my three-week “vacation” ended and went back to the day job fulltime… One of the big lessons that I learned that I [re]learned was that practice is crucial for every single skill from interview skills to skills that make the bread that needs buttering. Practice is even more crucial than talent, IMNSHO.

What prompted me to get off my virtual derriere and type the random thoughts that finally coalesced this afternoon was Steve’s maundering on practicing programming:

I doubt we or any company is likely to set up organized daily practice for their engineers. In fact I personally don’t think it should be necessary. The most important thing you learn in college is how to learn on your own. They teach you how to research, and how to apply the scientific method and question your own findings, and they give you the fundamentals of math/language/social sciences/etc., so that when you want to learn something, you know how to figure it out for yourself.
practicing-programming – steveyegge2

Unsurprisingly, I sort of agree and disagree, at the same time.

  1. I concur that practice is vital. Blogged that opinion a while back. It’s absolutely necessary to sharpen your tools and improve yourself as a professional (whether you are a programmer, modeler, writer, whatever). Practice is not just for professional athletes, SWAT team members and rocket surgeons.
  2. I believe that the successful, creative companies already create an environment where daily practice is the norm. My current day job @ Microsoft is like this already, and I will make certain that Glacier Peak will always be as well.

My premise for #2 there is that your daily work should be precisely this sort of challenging practice. I realize that somebody has to have the really boring jobs doing the same old-same old every day… but I refuse to work there! I’ve always tried to choose positions at each stage of my career that force me to learn new things, to challenge myself and in essence, force myself to practice. Every. Single. Day.

Which is what lead me to my personal learning and my new self-imposed mission: Create. Something. Every. Day. It may not be huge (still have that day job to do!), but whether it’s modeling a prop, painting some textures, sketching some concept art or drafting a level layout or a drawing a map… I need to create something every single day. Sometimes, it may just be contributing to a hobby project, but it needs to be something that stimulates the creativity and it needs to be something new.

The challenge for any professional is to avoid reaching a level of proficiency that allows you to begin phoning it in. Don’t. Fight that natural, human tendency with a vengeance. Make every like of code count. Make every word mean something. Make every polygon matter. To do otherwise is to just treat creating what could be your masterpiece like it’s just a job. Life’s too short to phone it in.