Software is a Total Mindset

Like every other team sport, software requires that everyone is pulling in the same direction.  I know, I’m shocked at the deep and original thinking that went into that one, too.  But oddly enough, it’s something that in my short and sheltered experience, that’s really quite difficult to achieve.  The more people in a given team, the harder it becomes.  Once again, no real surprises there.  But it’s something that is usually not outwardly stated.  Agile teams are usually recommended to be kept small, but the reasoning behind that is usually restricted to factorial communication network explosions.

But it’s more than that, isn’t it?  Getting software developers to all work together, try as we might, is actually a bit like herding cats.  A quote which I like to trot out every so often is “An Engineer without a problem to solve, will readily create one”.  Though I’d like to make a slight adjustment to that; An Engineer who’s bored of solving a problem will readily move on to something more interesting.  So what if a particular team is bored of solving the problem that the business has told them is the most important to it?

Read more of this post


Talking for the sake of it

Software Engineering is a group activity.  As part of this, I like to talk about the work I’m doing.  It can spark conversations about how I’m implementing a particular piece of work or even self-illuminate.  As part of that, I have a bit of a habit of talking about my work quite often.  This is especially true in my current team where I still feel like I’m quite new (as I’ve only been in it about nine months, with a five month break in the middle).  I’m sure we all agree in theory that communicating with some other person, whom we presumably consider to have reasonable opinions on such matters, is useful.  But in practice, it seems to be more difficult than that and interacting with the soft and squishy parts of software development tends to result in http-like results.  <gratuitous_geek_joke>269, 307, 413 and on particularly bad days 418.  It is almost uncommon to get a 200 straight away</gratuitous_geek_joke>  Maybe that’s unfair – the guys I work with always try their best to be accommodating, but they do want to get their work done too…

I haven’t yet formed a complete opinion on talking about my work.  It’s quite possibly something that, sigh, doesn’t have a hard and fast rule.  Sometimes, like I did this week, I needed to explain what I had seen to someone else, such that I could be certain that my levels of sanity were unchanged from normal, for a given value of normal.  And sometimes, I want to vent my frustration at the stupid code and why it’s not playing ball.  It’s not exactly asking for help, but that’s the intent that is often assumed.  And when someone sits down to pair with me, I rarely push them away.

Read more of this post

The Usual Suspects

I’ve often looked at the contents of my home directory and sighed.  I’m very good at sighing.  I have many half-started and even some half-finished projects on the go.  I’ve previously described myself as ADD when it comes to programming projects – I’m very good at starting, but find it difficult to get to version 1.0.

I can count 10 repositories on this computer, which only accounts for around the last year, give or take a couple of long-running projects which have had enough activity during that time to make it on here.  There is a raytracer (in two languages), a C compiler (well, most of a C preprocessor so far), a website and catalogue program for a family member’s business, a Tetris clone, a Serial Terminal, Personal Kanban web app and a copy of the gtkterm repository, along with a couple of work-related items.

So why is it that I have so many?  Clearly I run out of drive, but is it a problem?  I hear of other people who have got their main project that they work on day after day.  In the extreme case, there is Linus Torvalds working on the Kernel, but there are less notable examples, such as Minecraft, which was originally developed by just one person.  Is it just that these people have one main project that continues to hold their attention, along with a smattering of un-noteworthy forays?  I’d like to think so.

Read more of this post

The Third Virtue

Unit Testing is boring and tedious.  This is not just a hyperbolic opening line with the thinly veiled intent of grabbing the reader’s attention.  The only times I can remember enjoying writing a unit test were cases where there was a short setup to a not-quite-trivial problem, leading to the application crashing, such that writing out a unit test is not only less annoying than a manual scenario, but in some small way, I feel like I’m giving the buggy code the finger by not letting it inflict its full potential for disaster.  I am only four, after all.

Now is when the Hubris comes out.  How can we improve this situation?  Unit testing is not only recommended, but is indeed part of being a software professional.  If code you’ve written doesn’t have some automated testing around it, I would like you to have at least considered it, and made the conscious decision not to, for a good reason.  Otherwise, you’re not doing your job properly.  It’s really that simple.

Read more of this post