TDD, BDD, DDD, Agile, SAFe, Scrum, Kanban, XP… there’s a lot of ways to skin a cat write code in a professional environment.

I take pride in being a person who is a non-ideologue when it comes to my code. There are many good ways of working, and they are all context-dependent.

You can’t apply the same things that worked when you were a two-person startup operating out of the proverbial garage and expect them to work once your hypothetical unicorn has reached a thousand-plus developers. Even within the same organisation, processes that work for one team can be catastrophic when applied to their neighbouring team.

Anyone writing code professionally in December 2021 will remember the “fun” of the Log4J vulnerability. For those that weren’t - this was a critical security error that allowed attackers to run any code they wanted on your servers. The root cause was a logging library, Log4J, that is used by most projects that are writting in Java.

It’s usually used to write code something like:

log.info("Process completed successfully");

which will then appear in your logs, allowing you to track your application’s behaviour. Pretty innocuous stuff.

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.

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.

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.

TDD, BDD, DDD, Agile, SAFe, Scrum, Kanban, XP… there’s a lot of ways to skin a cat write code in a professional environment.

I take pride in being a person who is a non-ideologue when it comes to my code. There are many good ways of working, and they are all context-dependent.

You can’t apply the same things that worked when you were a two-person startup operating out of the proverbial garage and expect them to work once your hypothetical unicorn has reached a thousand-plus developers. Even within the same organisation, processes that work for one team can be catastrophic when applied to their neighbouring team.

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

The rise of Whatever - eevee

This is probably the best post about LLMs I’ve read, which is probably why I’m the millionth person to share it. It really sums up my emotional reaction to their meteoric rise: “ew”, basically.

The power of the argument is that it identifies a theme that runs through recent tech changes, of which LLMs are just the latest and greatest example: the lack of care for quality, and the realisation from Big Tech that consumers mostly are fine with mediocre output.

Last week I facilitated a session at XTC, where we discussed the new product development framework from Basecamp, Shape Up, led by Thomas Ankorn.

It was a really interesting discussion with people exploring the ideas openly, guided by questions posed by Thomas to get the conversation started.

I’ve summarised the points that came up in the discussion, reconstructed from memory and the collected post-its of scribbles at the end of the evening.

1. What problems does this solve?

We started by looking at the positives of the framework, trying to identify strengths that would help mitigate problems we have encountered in our own teams.

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.

TDD, BDD, DDD, Agile, SAFe, Scrum, Kanban, XP… there’s a lot of ways to skin a cat write code in a professional environment.

I take pride in being a person who is a non-ideologue when it comes to my code. There are many good ways of working, and they are all context-dependent.

You can’t apply the same things that worked when you were a two-person startup operating out of the proverbial garage and expect them to work once your hypothetical unicorn has reached a thousand-plus developers. Even within the same organisation, processes that work for one team can be catastrophic when applied to their neighbouring team.

Coming to grips with DevOps metrics

In my team we have been considering ways to monitor our own performance, and finding some ways to contextualise our ongoing process and quality improvements. Like many other teams, we’ve landed on the DORA metrics as a good way of doing this.  These four key metrics are an easy way to understand what adjectives like “maintainable”, “reliable”, and “efficient” mean in practice when applied to software and teams, and the provide a way of comparing team performance across teams and over time.

Last week I facilitated a session at XTC, where we discussed the new product development framework from Basecamp, Shape Up, led by Thomas Ankorn.

It was a really interesting discussion with people exploring the ideas openly, guided by questions posed by Thomas to get the conversation started.

I’ve summarised the points that came up in the discussion, reconstructed from memory and the collected post-its of scribbles at the end of the evening.

1. What problems does this solve?

We started by looking at the positives of the framework, trying to identify strengths that would help mitigate problems we have encountered in our own teams.

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.

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.

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.

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

The rise of Whatever - eevee

This is probably the best post about LLMs I’ve read, which is probably why I’m the millionth person to share it. It really sums up my emotional reaction to their meteoric rise: “ew”, basically.

The power of the argument is that it identifies a theme that runs through recent tech changes, of which LLMs are just the latest and greatest example: the lack of care for quality, and the realisation from Big Tech that consumers mostly are fine with mediocre output.

Have you ever argued with someone who is seriously good at debating? I have. It sucks.

You’re constantly thrown off-balance, responding to a point you didn’t expect to. You find yourself defending the weak edges of your argument, while the main thrust gets left behind in the back-and-forth, and you end up losing momentum, confidence, and ultimately, the argument.

One of my close friends won international debate competitions for fun while we were at university (he’s now a successful criminal barrister), and he told me that the only trick in the book, once you boil it all down, is to make sure the conversation is framed in your terms. Once that happens, it’s all over bar the shouting.

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

The rise of Whatever - eevee

This is probably the best post about LLMs I’ve read, which is probably why I’m the millionth person to share it. It really sums up my emotional reaction to their meteoric rise: “ew”, basically.

The power of the argument is that it identifies a theme that runs through recent tech changes, of which LLMs are just the latest and greatest example: the lack of care for quality, and the realisation from Big Tech that consumers mostly are fine with mediocre output.

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

The rise of Whatever - eevee

This is probably the best post about LLMs I’ve read, which is probably why I’m the millionth person to share it. It really sums up my emotional reaction to their meteoric rise: “ew”, basically.

The power of the argument is that it identifies a theme that runs through recent tech changes, of which LLMs are just the latest and greatest example: the lack of care for quality, and the realisation from Big Tech that consumers mostly are fine with mediocre output.

Kit Wilson writes in The Spectator about Facebook’s new venture into the Metaverse, a concept that most of us probably hadn’t heard of until last week. To layout the roadmap for what our journey into this new digital reality might look like, Kit joins the podcast along with Tom Renner, a software engineer for NavVis. (12:55)

Unfortunately since Elon shut down the Twitter APIs, the below method no longer works. Still, it was fun while it lasted, eh?

Gephi is a piece of software for visualising graph networks. It’s a powerful tool, and to use it fully requires significant domain knowledge that I don’t possess, but fortunately it’s still fascinating to play around with as an amateur!

As a techie, to me the obvious networks to graph are those created by the big Social Networks - YouTube, Facebook, etc. It’s not hugely surprising to find that mostly these graphs mostly aren’t available for querying, but excitingly there is a plugin that allows you to stream in live data from Twitter.

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

The rise of Whatever - eevee

This is probably the best post about LLMs I’ve read, which is probably why I’m the millionth person to share it. It really sums up my emotional reaction to their meteoric rise: “ew”, basically.

The power of the argument is that it identifies a theme that runs through recent tech changes, of which LLMs are just the latest and greatest example: the lack of care for quality, and the realisation from Big Tech that consumers mostly are fine with mediocre output.

Have you ever argued with someone who is seriously good at debating? I have. It sucks.

You’re constantly thrown off-balance, responding to a point you didn’t expect to. You find yourself defending the weak edges of your argument, while the main thrust gets left behind in the back-and-forth, and you end up losing momentum, confidence, and ultimately, the argument.

One of my close friends won international debate competitions for fun while we were at university (he’s now a successful criminal barrister), and he told me that the only trick in the book, once you boil it all down, is to make sure the conversation is framed in your terms. Once that happens, it’s all over bar the shouting.

Anyone writing code professionally in December 2021 will remember the “fun” of the Log4J vulnerability. For those that weren’t - this was a critical security error that allowed attackers to run any code they wanted on your servers. The root cause was a logging library, Log4J, that is used by most projects that are writting in Java.

It’s usually used to write code something like:

log.info("Process completed successfully");

which will then appear in your logs, allowing you to track your application’s behaviour. Pretty innocuous stuff.

Kit Wilson writes in The Spectator about Facebook’s new venture into the Metaverse, a concept that most of us probably hadn’t heard of until last week. To layout the roadmap for what our journey into this new digital reality might look like, Kit joins the podcast along with Tom Renner, a software engineer for NavVis. (12:55)

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.

“Saying the quiet part out loud” is a phrase I’ve just made up, to describe a method of building alignment on practices within a team. It’s the habit of stating why you are doing things a certain way, even when you would assume it’s obvious.

“Institutional knowledge” - the information that a company collectively knows - is a familiar concept to anyone involved in hiring processes. When an individual leaves who has knowledge the organisation needs, companies will organise offboarding sessions to keep that knowledge within the institution. Maybe they’ll even try to hire someone with similar experience.

Lots of companies similarly try to optimise for “Institutional learning”, especially smaller firms. This makes a lot of sense - smaller companies don’t have the resources to buy in extra experience, so they focus on rapidly expanding the experience of their existing employees. It also fits really well with the agile philosophy of fast development cycles to maximise your knowledge about customers’ needs.

Talk given at Codebar Festival.

If you wish to see my slides in their full glory, they are available on Slideshare.

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.

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.

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!

“Saying the quiet part out loud” is a phrase I’ve just made up, to describe a method of building alignment on practices within a team. It’s the habit of stating why you are doing things a certain way, even when you would assume it’s obvious.

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.

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.

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.

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.

Coming to grips with DevOps metrics

In my team we have been considering ways to monitor our own performance, and finding some ways to contextualise our ongoing process and quality improvements. Like many other teams, we’ve landed on the DORA metrics as a good way of doing this.  These four key metrics are an easy way to understand what adjectives like “maintainable”, “reliable”, and “efficient” mean in practice when applied to software and teams, and the provide a way of comparing team performance across teams and over time.

Unfortunately since Elon shut down the Twitter APIs, the below method no longer works. Still, it was fun while it lasted, eh?

Gephi is a piece of software for visualising graph networks. It’s a powerful tool, and to use it fully requires significant domain knowledge that I don’t possess, but fortunately it’s still fascinating to play around with as an amateur!

As a techie, to me the obvious networks to graph are those created by the big Social Networks - YouTube, Facebook, etc. It’s not hugely surprising to find that mostly these graphs mostly aren’t available for querying, but excitingly there is a plugin that allows you to stream in live data from Twitter.

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.

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.

Talk given at Codebar Festival.

If you wish to see my slides in their full glory, they are available on Slideshare.

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.

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!

Talk given at Codebar Festival.

If you wish to see my slides in their full glory, they are available on Slideshare.

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!

Your work inbox is probably not a place that sparks joy. It’s full of people asking you to do things, complaints that something hasn’t been done, and 571 messages marked urgent.

In fact email is usually considered to be a hindrance, with many productivity guides recommending simply ignoring your email for large periods of the day, blocking out that time for focussed work. The consensus is that your work inbox is just a place that generates distractions, and contains never-ending to-do lists that nag away at you throughout the day.

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.

Last week I facilitated a session at XTC, where we discussed the new product development framework from Basecamp, Shape Up, led by Thomas Ankorn.

It was a really interesting discussion with people exploring the ideas openly, guided by questions posed by Thomas to get the conversation started.

I’ve summarised the points that came up in the discussion, reconstructed from memory and the collected post-its of scribbles at the end of the evening.

1. What problems does this solve?

We started by looking at the positives of the framework, trying to identify strengths that would help mitigate problems we have encountered in our own teams.

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.

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.