Archive for the ‘life’ Category

On hiring (developers)

Tuesday, August 17th, 2010

First off, we’re hiring. You should apply. Even if you don’t apply, check out the spec. This post will make more sense if you do, and I’d love it if you were to forward it to anyone you know who would fit.

We’ve yet to see if it will produce the right results, but one interesting thing has emerged from writing this job spec is that we’ve not done it as a collective. It’s largely been my doing, with editorial feedback from the rest of the team.

There are a couple consequences of this. Some good, some bad, some still in a superposition of the two.

we’re looking to hire someone who can do this job better than me

The part of it I especially liked is that the way the job requirements (both in the spec and as we’re viewing it) is that we’re looking at the person who currently is doing / would do the job and saying “You need to do the job better than him”. We’ve done this a bit less formally previously when hiring our new sysadmin, and it just sortof emerged naturally this time as a result of the fact that I was the one pushing the hardest to get this job spec done and posted. Whatever happens, I would very much want to retain this aspect of the process: Pick a person in the company who would do the job if you don’t hire for this role, make them responsible for speccing out the job and make them the primary decision maker on whether the person gets hired – other people get to veto, but they’re the one doing the initial approval by saying “Yes, I would rather have this job done by this candidate than done by (a perfect clone of) me”. I think this is very much the right way to do it.

15 years of BBQML

The fact that I wrote it brings with it a certain authorial style. This is both good and bad. If you’re reading this blog you probably are familiar with that style by now – whimsical, fairly abrasive and decidedly non-traditional. All of that comes through in the job posting.

Personally, I think that’s ok. Everyone in the company seems to have liked the posting (Well, they laughed. That’s good, right?), so enjoying the style is probably a good sign of a compatible personality. On the other hand it may turn out to be a bad thing – it may scare off some people who would actually work well for the role (I have at least one friend who is giving me a hard time because he thinks the posting is unprofessional and makes me sound like a wanker), on the other hand it may attract too many people who self-describe as rockstar ninja cyborg artist programmers.

If it turns out not to work, I will modify my style for postings in future, but I am hopeful.

we don’t want yet another [REDACTED]

The biggest feature of this posting that may or may not work in our favour is its honesty. It’s very much “This is who we are, this is what we’re looking for”. There are some tensions you can see behind it as a result. Will they scare people off? I hope not. As a company, we’re very much not perfect. No one is, and if you expect the company you’re applying to to be perfect then you’re in for a bit of a shock whomever they are. I hope that being up front about this is a good thing, and a nice departure from the whitewashed corporate-speak you get in a lot of job postings.

and…?

All in all, it’s been an interesting experiment. I look forward to seeing the results.

Let me know what you think.

Teaching

Tuesday, July 27th, 2010

Another IRC conversation. alaric is Alaric Snell-Pym.

20:27 <@alaric> I am a dark master at taking a bespoke requirement, and coming up with a generic yet easily-implemented solution to it, that can be resold in future
20:27 <@DRMacIver> Teach me your ways, master alaric
20:27 <@alaric> I’ve been wondering how to do that, actually
20:28 <@alaric> Most of my software design-fu is intuition, but I know it should be extractable into a series of principles
20:28 <@alaric> So I’ve been wondering what they are…
20:29 <@DRMacIver> Extracting things into a set of principles is the wrong way to teach something anyway.
20:30 <@DRMacIver> You’re taking a thought process, creating a set of steps that you don’t actually use in that thought process, and then expecting people on the other end to somehow recreate the original process
20:31 <@alaric> Agreed, but in order to teach something, you need to know what it is
20:31 <@DRMacIver> Disagreed.
20:31 <@alaric> And my issue right now is that I have these Intuitions, which aren’t very communicable
20:31 <@DRMacIver> Knowledge is a very overrated feature for teaching and learning.
20:31 <@alaric> The best I could do right now is to set people a design exercise, look at their solutions, and point out how they could be done better
20:32 <@alaric> Which would get the point across eventually, but it’d take a while
20:32 <@alaric> Or I could list examples from my past
20:34 <@DRMacIver> Both of those sound more useful than a set of principles.
20:35 <@DRMacIver> I think interactive learning is really the best way though. Either set someone a problem or have them work on their own ones and interact with them as they do – ask and answer questions, point out alternatives, etc.
20:35 <@DRMacIver> Of course this is very time consuming.
20:36 <@DRMacIver> Which is why no one is never taught anything properly and has to learn it for themselves.
20:37 <@DRMacIver> There might be good ways to parallelise this though: e.g. give twopeople two different lessons, stick them in a room together and tell them to solve the problem together.
20:38 <@DRMacIver> This of course only works on motivated students.
20:38 <@DRMacIver> But unmotivated students can fuck off as far as I’m concerned :)
21:39 <@alaric> I’d like to figure out what principles I use, though, even if only to make sure that exercises I set end up covering them all
21:42 <@DRMacIver> Teaching people is also a good way to codify your knowledge I think.
21:42 <@DRMacIver> i have a friend who refers to my rules of interviewing.
21:42 <@DRMacIver> Thing is… I don’t *have* any rules of interviewing. I have a general body of advice and knowledge, which upon relating has become slightly more formalised.
21:43 <@alaric> Yes
21:43 <@alaric> That is a valid process, IMHO
21:43 <@DRMacIver> Agreed.

The role of a CTO

Monday, July 19th, 2010

IRC conversation with Al Davidson

< DRMacIver> I must admit to only having a relatively vague idea of what a CTO job involves (and a much stronger conviction that I don’t want one any time soon).
< DRMacIver> As I’m fairly sure that craig isn’t typical of the role.
< al_> i think you’re right on that score
< DRMacIver> My impression is that it seems to be somewhere more in the realm of “You’re supposed to get to work on the fun stuff but so much of your time is taken up by boring administrative crap that you don’t get to, but it’s still your fault if it goes wrong”
< al_> bingo
< DRMacIver> I see the old chestnut of “take rosy eyed view of the world and apply cynicism until it starts to weep” still works.
< al_> david, i think you just described the human experience in a nutshell

You Might Not Know…

Thursday, February 11th, 2010

…that Mike and I have been working on a secret project.

Some time last year a friend gave me a really good piece of advice. I don’t even remember what it was about – it was something totally minor. Useful at the time, but not something that particularly sticks in your memory. What did stick in my memory was the realisation that everyone has a pile of these little unexpected ways of doing things which plenty of people could use, yet most of them go unshared. This seems like a shame.

So, Mike and I set out to fix that. After a fair bit of work and a lot more procrastination, we give you You Might Not Know: A site for sharing those tips and tricks for life that you might otherwise not have.

I’m pretty pleased with how it’s gone so far. There’s still plenty left to do, but I find what’s there remarkably pleasant and easy to use, in no small part due to Mike being way better at user experience and design than I am.

So, do go check it out. If you’ve got something to share, great! Even if not, have a browse. Maybe you’ll learn something useful.

It’s all the same, really

Tuesday, September 1st, 2009

Daniel Lemire wrote a post recently comparing one of Paul Graham’s essays on startups with the process of doing research.

It reminded me of a book I read recently, and an observation I made on it. The book was 101 things I learned in architecture school, and the observation was that half the advice applied just as well to software development as it did to architecture. I find this is often true: At the general level, good advice is very portable.

Here are some excerpts:

61. Less is more

Minimalism is not something that’s hard to find in software design (or at least software design as we want it to be instead of the endless feeping creaturism that it often turns out as). Particularly epitomized by the Unix philosophy of “Do one thing, and do it well”.

62. Less is a bore

On the other hand, there’s a reason we’re not all still living in the command line…

32. The most effective, most creative problem solvers engage in a process of meta-thinking, or “thinking about the thinking.”

Good advice anywhere, but particularly so in software development where there’s so much capability for abstraction.

81. Properly gaining control of the design process tends to feel like one is losing control of the design process

There’s a good chunk of explanatory text in the book about this one, which I’m not going to reproduce here. In short, this is about not becoming prematurely wedded to ideas and embracing the uncertainty needed for finding the right solution.

17. The more specific a design idea is, the greater its appeal is likely to be

Tools for solving everyone’s problems tend to be tools for solving no one’s problem.

90. Roll your drawings for transport or storage with the image side facing out

Ok. Maybe not this one…