Warren Seen

Update: If you think I’m being arrogant, I assure you, I’m just trying to be assertive

(For the background that inspired this post, see here, here and here.)

Why are you reading this post? Perhaps you’re thinking of becoming one of my clients. Perhaps you’re a freelancer yourself, or thinking of becoming one. Perhaps you feel that I’m just an insufferably opinionated t**t with whom you disagree and are keen to let me have it in the comments (Feel free by the way, provided you have a reasonable argument, and aren’t just going to call me an insufferably opinionated t**t).

Why a manifesto? I know, I know, it’s an overused term, but I wanted to describe something of my approach to freelance software development, one which has been successful for me so far. I’m not deliberately setting out to be controversial, but no doubt I will be, and as long as it starts reasonable debate, that’s a good thing.

So without further ado…
(more…)

Interesting article about the use of the “Committer Model” in commercial software development, borrowed from the open source community.

The committer model solves a few problems of open source distributed development, but the primary one is that of trust: in a developers intent and in their competence. There are other issues that push different buttons depending on the project, but in the end, these are just indicators of intent or competence.

Personally, I think this is a bit of an extreme approach in the average commercial development project - certainly for teams under 10 developers I would call it excessive - as the same issues don’t apply in a commercial project.

Firstly, you must implicitly trust the intent of the developers which you are paying to write the software - and if you don’t, why are they working for you to begin with? Secondly, if you’ve hired them, then you already have made a decision based on their competence.

(more…)

My initial post was going to be a snark-filled venting of all that ails me with my “day job” at the moment. Specifically, the woes of maintenance programming when dealing with a codebase from 2000 and ported from Windows to Linux.

If JP Sartre was a coder, he would have actually said:

“hell is other people’s (undocumented) code.”

So for your amusement, here is the list of simple mistakes I’ve seen of late. Consider these some simple C++ programming sins you may use to torment those that will follow you for eternity. (more…)

I’ve been too busy lately with real work to keep up with the Ruby spider project, but I’m hoping to get back to it real soon.

This is a vent/rant/gratitude post, based on what I’ve spent my last 2 weeks dealing with.

I’ll start with the gratitude, but it’s all downhill from there. I am immensely thankful for the developers responsible for the following tools which, IMO, no Linux developer should be without:

• Valgrind - helped me track down a bunch of obvious memory errors in the code
• dmalloc - helped me track down those which valgrind couldn’t
• gdb - the more I use gdb, the more effective a tool it becomes to me. Why aren’t you using it? At least learn to get a backtrace and inspect variables if you’re at all programming anything with GCC.
• distcc - chasing memory issues into base classes led to full recompilation more often than I would have liked. distcc let me put an extra 2 idle machines to work compiling the code.

What started as a rather curious crash in our dev branch a couple of weeks ago turned into a major audit of how we allocate, use and free memory in our codebase. When I did get to the bottom of the crash, it turned out not to be a memory issue, but a library dependency inherited from libstdc++.

So here’s a little nugget for you right off the bat:

If you use STL containers (or any code which uses STL’s default allocator) in a dynamic library which has been compiled with -MT, you must link any executable that dlopen’s said library with libpthread.

In hindsight this sounds fairly obvious, right? (more…)