Windows developin’

I started life as a die hard linux developer. That was all I wanted to do, and all that really made sense to me. I enjoyed looking into, calling and using various odd APIs, I love the idea of writing a little C and bob’s-your-uncle-you’ve-got-a-driver. I’ve never actually written a linux driver, though, and as such I just bought a linux device drivers book so I can get on that.

In either case, I think there’s some odd difference between linux and Windows development that I’m finding it hard to put my finger on. It seems, though, like there’s more general knowledge inside the linux camp: the languages themselves are known, rather than just the MS libraries. The kernel is studied and understood to have an exposed API, the compilation toolchain is something you’re encouraged to understand instead of just pressing build and now it’s done. And I think I’m better off for having an idea of what the individual steps that are taking place whenever I request magic from an IDE are.

However, the IDE front is really interesting. There’s something nice about a tool like visual studio, which is giving me a lot of hand-holding, rather than sitting down in front of gEdit, or Emacs or vi and being stuck with, well, with working out how the hell everything else happens. It’s a bit of a pain the first few times and visual studio takes a lot of that pain and hides it away.

Mac OS has a great IDE, too, in XCode. Interface builder could use a touch of work, and it looks like XCode 4 addresses a lot of my complaints against XCode as a whole, but it’s overall pretty neat. And the documentation, oh the documentation.

One place where the proprietary folks tend to whip the open source folks is the documentation. Now, that’s not universally true: OpenBSD has very, very high quality documentation indeed, the GNU toolchain is exhaustively documented (though documented exhaustively and documented well are two different things), but by and large the smaller stuff isn’t nearly as good. Except in the perl community, where everything on CPAN is normally really outstandingly well documented.

Something I’ve been really taking to heart, and which my colleagues at work are really pushing for, over the last six months is the idea that if I’m going to write code then everything in it has to be highest quality, no exceptions. It’s one thing to write a tracer bullet, to take an example from The Pragmatic Programmer, it’s another to then leave the tracer bullet in the system and never improve it. And if you’ve not written a high quality tracer in the first place, well, just remember that nothing’s quite as permanent as a temporary solution.

Trying to Improve

I’ve been writing a lot of perl recently, and had a few solid insights into what it means to program better than a beginner. Not like a professional, but not like a beginner.

Writing to the interface has been huge to me. Writing to the interface, not changing the interface.


Slowly working out how to keep my functions free of side effects is another. Incredibly hard to do, it’s taken me years to grok what it means for a function to have a side effect and to discipline myself to write side effect free code. I’m not great at it, but I’m better than okay.

A really interesting way to learn about side effect free code is to start writing ruby. The ruby community really encourages tons of small methods on an object, and that starts training your intuition to understand how to make one method do only one thing, and chain things together.


I have so much improvement to do, though. I don’t feel like I really understand perl or ruby or C or Objective C at all. C, I’m getting closer with: understanding how pointers and the address of operator work was crucial, as was getting a mental image of what a type is in C (think of it as a way of indicating how much memory something needs).


On another topic, Uncle Bob’s been giving some really interesting talks recently about what the new programming paradigm might include, what direction programming should be taking. His recent interview on the pragmatic programmer’s podcast is well worth checking out.