The Temple of Fail
DISCLAIMER: This was not my idea - I picked it up from Jane Nicholson at an XTC event, who was introduced to it by Jess Gilbert (who in turn, I am told, got it from someone else). This post is just explaining why I believe it can be a useful exercise, not any truly original thinking!
One of the things that is really important to me is that my team and I keep learning at work. As such, fostering a learning environment is kinda key. I think we do that pretty well at Haplo – we have hired nearly exclusively early-career developers to our tech team for several years now, and one of the key points most hires mention as to why they join is that they feel it’s a good place to learn quickly, with the requisite support early on in their career.
"Efficiency" is bad for your health, and your learning
I used to stress a lot about the “efficiency” of how I was using up all the minutes in my day. I’d to cram in as much as possible into time. eg. read on a 10 minute train, write code in the half hour before bed, etc.
While I stressed about it a lot, I never found that I did the “10x” things I read about that were supposed to emerge as a result of this extra “efficiency”. For example I have only finished one of the three side projects I started in 2016, despite promising myself that those wouldn’t take long.
Offline knowledge, buses, and note-taking
In a team having knowledge that lives only in your head is a terrible thing.
- Humans are forgetful
- Humans are creative, especially when problem-solving
- Computers are not creative
- Computers are not forgetful
So we should get the computers to remember things, and allow the humans to do the creative parts.
Writing software is a creative activity. You start with a blank text file and end up convincing people to give you their identity details in exchange for the ability to poke someone over Facebook. If that’s not creative I don’t know what is.
Setting up a bottom-end Chromebook for development
I like being able to code wherever I am. “Unfortunately”, my 15" laptop bought to run simulations for my degree still runs like a dream, so I can’t really justify buying myself a replacement for it. So instead, just over a year ago, I decided to get something that is:
- Lightweight
- Cheap
- Allows me to code on the go
Looking around a bit, a budget Chromebook seemed like a good choice. I settled on an Asus Chromebook C201, which cost me £190. It has 4GB of RAM, a 16GB SSD, and weighs under a kilo.
Getting the right scale
Agile tells us that the most critical thing for getting software right is not up front design, but getting something out there and used, and then incorporating feedback. By getting feedback early, you are able to respond faster, changing your (initially incorrect) design in small steps towards a better solution. This works better in practice than designing everything at the start very carefully, which feels rigid and inflexible in the face of new information over the course of a project.
A quick guide for productive development
It is upsettingly easy to work hard without being productive. The Lean Startup includes a quote I really liked:
“[People] feel that a good day is one in which they did their job well all day.”
The point being that this doesn’t account for whether you are doing the right work. This is a really common trap to fall in to. I know I have often worked really hard on something and produced code I’m very happy with, only to talk to my boss or the client and find that nobody else seems to be nearly as pleased with what I’ve produced as I am.
The customer is always right
A theme of the last few books I’ve read has been user testing. Specifically, that it is completely unreasonable to suggest that you could produce a system that will work smoothly in production without first getting several actual human users unfamiliar with your system, from your clients or in a related industry, to road-test the system.
I think anyone can see that this is a good idea. It’s far too easy to make assumptions about the users’ requirements or use cases. Without user testing software would rarely solve the problems it was designed for.
Why am I doing this again?
Why do I want to have my own site?
Narcissism mostly. I found the domain was available, decided as a self-respecting developer I should probably buy it. But then there’s no point owning a domain if you don’t put something there. So that was it really - I had to I had to get my act together and actually write the thing.
I enjoy developing
I’m a person who finds it hard to devote time outside of office hours to write code. I suspect it’s because I hate fun. Whatever the reason, if I’m not doing something useful, I won’t bother. So having decided I would like to code more, I had to find something useful to write.
"Full-stack" and why I don't like it
Last week I went to a jobs event, recruiting for my company. I was there on my own, and recruiting is a pretty new experience for me, so I was kinda excited about it. The attendees were a mix of graduates, bootcampers, and a few more senior developers, but mostly the crowd were looking for their first or second job. I enjoy going out and talking to people about their experiences with software – I think breadth of knowledge is really valuable – so I found it interesting seeing what other people are looking for in a job. I’ve only ever had one; maybe I’ve aimed for all the wrong things!