Newbie programmer: Focusing on getting the job done

So I've started work for the first time as a full time developer at a popular software company recently, and I've been jotting down some notes on my first impression on how to get stuff done and be as productive as possible. It might be totally wrong, its primarily from the perspective of a newbie - but might be an interesting read none-the-less.

If you have your own ideas of getting things done, and you have more experience then this spring chicken, feel free to comment.

Prototype first, optimize later

Premature optimisation is actually an anti-pattern according to Wikipedia, and I'm starting to realise why. With the amount of backwards and forwards one can do in code during a design phase - it makes sense to optimize later once the prototype and design has been agreed on.

I find though doing this in chunks once you feel you have a feature working enough is a good idea. Leaving optimisation late can make it feel like a less interesting task, so wrap it up in chunks.

Style

Get style issues out of the way early. Write using good style all the time, it can avoid a lot of unnecessary chatter with your colleagues. Programmers I know have a special aversion to bad style and its not worth the hassle I assure you. Getting to know their style and sticking to it saves time.

Task Tracking

Use a micro task tracker to keep track of tasks that don't really belong in a major task tracker. I use OmniFocus but any GTD style tracker is probably adequate.

Music

Get yourself some playlists for music - something that runs for many hours so you don't have to break concentration to switch tunes. I use Youtube for my music on my spare Ubuntu desktop here, but if the ads nag you, get something on ITunes or whatever is your favourite poison.

I also have different play-lists for different moods. I have slower music for concentration and thinking about problems, and faster music for just hammering things out.

Distractions in the Workspace

Sort out distractions early, don't let background noise linger - make it clear to people around you that you are in a sprint and you don't want to be disturbed.

I work from home a lot. My kids know now that I need my peace and quiet during 'work hours', and I try to make it up to them when I'm out of work mode.

Socialising Specifications and Design

Get your specifications out in the open earlier, if you are designing a website, protocol or otherwise - write the design early, and get the feedback loop happening earlier. This saves you having to rewrite a lot of code later on.

You might presume that the design is 'obvious' and follows standards. The truth is probably far from it. Once you put it on paper (well - google docs or whatever) you'll find your assumptions shattered. This is a good thing.

Fussing over old code

When looking at new features you want to add to existing code, you may find you are not happy with the existing code. Mostly, this is due to your initial understanding of the objectives of this code as written at the time - that will pass. But regardless, its not worth fretting or pondering why code was written in such a way. If you find yourself wanting to adjust the code - just do it and move on, but make sure you understand the overall objective before destroying someones dream.

You're probably wrong

When socialising your work amongst your colleagues, you may get opinions that don't make sense to you. Welcome to the real world. I've learnt that the best thing to do is to understand these needs and try to meet them if they are reasonable, chances are the person has a good perspective. I think as a programmer you will have to get used to outside influence - I think embracing with good debates and discussions is easier then rejecting it.

Also - be humble. Be prepared for being wrong. As a user you were always right ... as a programmer, you have to listen to your users.