The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Saturday, December 13, 2008

I want an apprentice

I want an apprentice.

I want a junior program who can work with me. Not necessarily pair programming.

An apprentice at my beck and call, who I can call over to my screen when I realize "Here is a little bit of automation that needs to be doing" - who I can explain, verbally, what needs to be done, and whose job it is to make enough notes, and then just do it.

There are always a lot of little programming tasks that need to be done, but which I deliberately neglect in the rush to get urgent, quick and dirty, results. Darn! That may be a career limiting admission: sometimes I do not go and clean up the code or write utility functions when I see the need. Most people would accuse me of not being quick and dirty enough.

It's hard to balance "Getting to the answer as quickly as possible" and "programming well".

part of the problem is that, as a computer architect, my output is not really the simulator. My output is the hardware recommendation, the perf data, the simulation results. The simulator is just a tool, and if it were throw-away, that would be great. But, the simulator is not thrown away, except maybe once a decade. It is an asset that is constaly built upon.

And it is hard to balance getting the answers vers keeping the simulator clean.

Many programmers don't have this problem.

Usually because they simply just aren't as good programmers as me. They don't know how to do things right.

But sometimes because they don't know some of the really fancy quick and dirty programming tricks that I know.

I.e. because I am a pretty good programmer, better than most, I can write really good code -or really quick and dirty code.

The balance is hard. Sometimes I am rushed.

Hence the apprentice. If I had two apprentices, one could be devoted to pair programming, and the other to "doing the right thing". Basically dedicating 50% of apprentice resources to making the code better.

Plus, the apprentice making the code better does not have to thrash. His job is to make it better. Period.

No comments: