Software engineering, as a profession, is terrible at refactoring. A hot-take I know, but I think I can convince you. After writing about [skill acquisition and up-skilling](https://barryosull.com/blog/growing-other-developers-as-a-staff-engineer/) I wanted to reflect on refactoring, a skill that is core to software development, many dev assume they have, but few can actually demonstrate. # My journey with refactoring First a little about myself. For the last 7 years I chose to specialise in legacy web apps (which baffled so many people), and rather than pitching rewrites that typically fail, I opted to focus on improving these sys...
Read more »

I was recently asked how I, as a staff engineer, work with and upskill other developers on my team. It was a great question, and I thought I'd write down a longer form version of the answer I gave. A core part of staff engineer's role is to grow the team. A staff engineer who doesn't up-level other engineers is a bottleneck. Staffs look to accelerate their team and their growth, so training and upskilling is incredibly important. It is also not really talked about, with most staffs picking up the skills haphazardly. Is there a better way to do it? Well, if you want to help someone improve, the first step is to figure out their lev...
Read more »

Today I'm going to explore a question that's been rattling around in my head, "Why does software inevitably get worse over time?". Every software systems I've worked on inevitably decays and becomes difficult to work with, despite everyone's best intentions. Why is this? Well, I've come to believe that this is a systemic effect, resulting from the businesses hyper-focus on immediate profit, causing a mis-balance between exploitation and exploration. ## Exploitation vs Exploration: The [exploitation vs exploration dilemma](https://en.wikipedia.org/wiki/Exploration-exploitation_dilemma) is a key factor in any decision that factors in...
Read more »

I've been talking a lot about Domain Driven Design (DDD) lately, be it at meetups or with clients, so I thought I'd write down my thoughts and see if it helps. Now, lots of people have written about DDD from a technical perspective (see the end for links), so I'm not going to do that, instead I'm going to discuss DDD from a non-technical perspective. This is DDD for everyone else. ## Solutions Always Overrun Designing and building a solution is not a trivial problem. It never goes smoothly, and even if it's completed on time (which is never) the solution is usually ineffective and needs to be changed, often drastically. This lea...
Read more »