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.
Jam and Bees 