2006-07-01

 

On work and clean code

It's been like 6 months of me working on Unity. So far so good. We've done a big new release recently, so after some pre-release insanity we're a bit more relaxed. I guess not for very long though, we have more stuff planned than we can handle :)

It sure feels nice to work on an actual software product. I think it's probably the first time in my carreer that I know people are using my work and I do care about that. Having worked on projects before, it's very different - a project just comes and goes, and once it's finished you never think about it again. And most of the time you don't care about "the clients" that much either. Working on a product is much more rewarding (especially if the users seem to like it).

Another interesting here is that we are a very small software shop. So everyone has to be a one-man-army (the others certainly are, not sure about myself). Design, program, fix bugs, decide on features, do support, write docs and even do html tweaks for the website. Of course, it could be Jack of all trades, master of none (*), but somehow I feel that we are managing pretty well. And I like to be involved in various aspects of making a product.

(*) though wikipedia says that the full saying is Jack of all trades, master of none, though ofttimes better than master of one - which looks like a positive thing to me.

A completely different theme: when programming, it's always good to massage the code you're working with a bit. Remove unneccessary #includes. Write a comment on tricky code block. Fix warnings. Do small refactorings. Remove unused code paths. It does not take much time and helps to keep the codebase clean. Removing unused code is especially good - for some reason I love removing code. Could do that all day long; probably I'm some kind of anti-programmer :)

Comments
Removing code is fun because it makes the code seem more elegant, which is a description coders must love :)
 
I'm not sure if I understood the part with one-man-army and "everyone has to design, do features, etc.". So you have these small meetings or something like that every day? And, like, together decide on new features and who implements what. Or is there a single "lead" who, like, proposes the features and other team members agree, disagree, discuss, etc.? I'd be happy if you could light me a bit about how you guys work in team and what is the flow of work. Thank you!
 
Not really. My point was that in a super small team you can't be "I just code shaders, don't touch me". Just because there's not enough people to fill some 20+ roles that are required to make a product.

Just to name a few: architect, programmers (editor, grapghics, shaders, webplayer, windows, build system and other tool scripts), support (regression testing, bug tests, helping customers via bugsystem/forums/chat), documentation (general help, script docs, code examples, tutorials), website (html, server side stuff, webshop), administation (making sure build farm, bugtracker, subversion, forums and other stuff runs). And that's not including the business/marketing/PR/finances stuff.

In short, each has to take on multiple roles. E.g. I'm mostly graphics/shaders/windows programmer, but also do support, build/doc scripts, documentation and the website sometimes.

And our company is too small for any formal "meetings" to make sense. You just turn around in your chair and ask/propose something :)
 
I like the term "anti-programmer" :) Refactoring is good practise in the end.
 
How do you like working in such a small team after Alna? Any drawbacks considering the work flow?
 
Well, at Alna I only worked on projects with quite small teams as well :)

Overall, what really counts is that all people on a team would be really smart (and "get things done", to quote Joel). Add just one who's doing things in "bitikzyz" (EN: I don't care, it works for now) style and the whole experience is ruined.

So yeah, I love working here.
 
anti-programmer? Wouldn't that be a "congrammer"? :P
 
I guess so :)
 
Post a Comment

<< Home