I haven’t been blogging much recently.
I’m not quite sure why. It’s certainly true that working on Sketch is keeping me busy, and what free time I have seems to be taken up these days by ownership of an old (and leaky) house.
I’m still very engaged in the whole business of doing what we (software developers) do - plus what could be loosely described as life-and-all-that-shit - and I feel that I’ve plenty to say.
Perhaps it’s just that I’ve been spending too much time drinking from the fire hose, and not taken enough time out to reflect on what I’ve read and post my comments here.
I hope that I don’t have an unrealistic view about the likelihood of many people reading or responding in any case. This is a prime example of vanity publishing I guess, but I find the process of writing down my thoughts enjoyable and occasionally useful (or cathartic).
Note to self: do a bit less, reflect a bit more, take the time to write it down.
The independence campaign has been fascinating, with a really good level of debate. In my personal world, Twitter and Facebook have been alive with links to brilliant articles from both sides, and impassioned posts by friends and strangers.
Though I think that I’m coming down in favour of a YES, I’ve been very torn, as I can see good arguments on both sides. I say think because I’m still not 100% certain.
Quite a few people I respect have questioned why I can see the sense in many of the economic warnings, and yet still want to go ahead. I know what they mean. I know that my heart says YES, but I’d like to be sure that my head does too.
This post is an attempt to explain why I want to vote YES. You could also see it as an attempt to convince myself that I’m doing the right thing.
I’ve been pondering what to do about the house of lords for quite a while, and at some point last year I came up with a scheme that I liked. I’m sure it’s not an original idea, but I haven’t actually seen it expressed elsewhere, so I’ve been meaning to write it down.
I live in Scotland now, and so the Independence debate that is currently raging has a direct impact on my future. I’m broadly in favour, but I recently discovered that the proposal includes no second chamber. This seems like a bad idea to me, so I humbly submit the following as an alternative plan…
I’d like to try to remedy this in the coming weeks. One thing that should help is the new Bohemian Coders blog that Pieter and I have set up.
This is a companion to the Bohemian Coding blog, but where that one deals with general stuff, the Bohemian Coders one is solely focussed on the technical issues we’ve encountered.
There are an awful lot of interesting topics to discuss, relating to how we do certain things internally, how the code ended up that way, what changes we have planned, and why.
Why not head over, and check out the first few posts. Meanwhile, stay tuned for more from me, both there and here…
Marcus Zarra’s NSConference talk today - about how reinventing the wheel is ok, maybe even to be encouraged - was thought provoking. In fact, I think it was downright provocative. Which is great :)
I recognise a lot of the sentiment behind what he was saying, and have undoubtedly had that same urge to reinvent on many occasions.
I generally feel that it’s useful to understand at least one level below the one at which you are working. If you’re using Objective C, understand C. If you’re using C, understand assembler. If you’re using an open source framework, understand how it works or the technology on which it is implemented.
And yes, it’s hard to really understand a coding problem until you’ve tackled it yourself.
Also it’s quite true that generic code is never going to be as optimal as a bespoke solution.
When you use an open source library, you are typically using code that has shipped in existing products. In multiple existing products. Products that have provided the code with hours/days/months of testing with real world data. Is that worth something? Hell yes.
There is code out there which is broken, unused, or just plain rubbish. Undeniable. That’s an argument for choosing carefully, it’s not an argument for not using other people’s code.
The fact that it’s hard to understand a problem until you’ve tackled it yourself makes it tempting to rewrite. Very tempting. I have ripped out and rewritten plenty of other people’s code in my time. Many’s the time I have simplified “unnecessarily complicated code”: “what an idiot this guy is, look at all this crazy shit he’s doing…”.
That same fact is also why you really shouldn’t, most of the time. Unless you have the luxury of enough hours to rewrite the same thing more than once on the same project, or the luxury of doing the same thing repeatedly on each project. When you rewrite, you will fuck up. The fuck up rate will probably never get to zero, but it will almost certainly only reach an acceptable level after two or more attempts.
It’s uncanny how often that “weird shit” that you ripped out near the beginning makes a quiet return (with the variable names changed to protect the innocent), when the subtlety of your understanding of the problem finally catches up with that of the person who wrote the original version.
When we use someone else’s code, the trade off we’re making is to exchange that deeper understanding that we would have gained by doing it ourselves for the luxury of not having to go down all the blind alleys first.
When it comes to the risk that comes with using someone else’s code, I agree with Marcus that it’s always good to understand it.
But if you’re selling your client on the idea of doing an upfront rewrite of something now on the basis that there’s a 20% chance that they might conceivably need to do it later… well, that’s nice work if you can get it, but 80% of the time it’s stuff that they didn’t need to pay for. Sure the cost of that 20% scenario might be much worse than up-front rewrite, but there are other ways to mitigate against that worst case.
Marcus seemed to be describing a situation where you’re basically doing similar projects again and again. In that case I can also see the attraction of starting from scratch each time. Like a master craftsperson essentially making the same chair over and over again, that zen-like quest for perfection is seductive.
Most of us don’t live in that world though.
I’m not saying that we write code once and let it ossify for ever more, or that we grab the first thing off Github that looks vaguely ok and never question it again. There’s a hell of a lot of room in between that and what Marcus seemed to be advocating though.