I've been writing code for a long time. I started on my friends TRS-80 when I was a small kid. I wrote code on the ZX-81, ZX-Spectrum, and the obscure Memotech MTX-512. I wrote on the school computer for my computer studies GCSE. At university I wrote stuff in APL and C on a mainframe. Then I moved on to PCs, using a wide variety of languages: assembler, Modula 2, Pascal, VB, C, c++, Java, javascript, and C#.

But the fundamentals always seem to stay the same. Software, and the development of software, is endlessly fascinating. It's rewarding and frustrating in equal measure. Not a day goes past without finding myself gaining some new insight into software engineering, or an interesting coding technique. Or perhaps discovering a new design pattern, or maybe a fresh angle on an old one.

It never really seems to get dull, and no matter how hard you try you can never say that you've truly mastered it. You keep climbing higher and higher, but the peak is always above you shrouded in mist.

I'm interested in many, many aspects of software development, but a major interest is the value of maintenance: refactoring, finding seams, getting software under test. Preventing software rot, and trying to keep code "habitable", seems to be an endless battle. In our profession we spend so much longer maintaining systems than we do creating them from scratch. When these systems have a poor codebase, working on them can be so demoralizing. This means that, quite apart from all the other benefits it brings, striving to keep that codebase good and healthy can help protect the mental health of ourselves and our colleagues. Software is hard, but there's no need to make it even harder than it needs to be!

In this blog I hope to cover all sorts of topics to do with software development and modern software engineering. I may post about some low-level code technique in C# or .NET, or about the details of a design pattern; or it might be about something at a higher level, perhaps some more fundamental and timeless aspects of software engineering. Maybe, though, there will be a slant towards the topic of maintenance and keeping code healthy.

All of us who are passionate about software development, and the processes, craft and engineering which go into it, have a voice. We all have some unique insights from our experiences. Whether it's wrestling with architecture or design, or the naming of methods or variables, or a neat technique to split up of some entangled classes, or how to get part of a gnarly system under test - all of this experience builds up into a big bag of techniques and ideas.

Many times I've watched a software talk or read something in a coding blog and felt that I could have said or written it. Equally though I have encountered many ideas and insights which might never have occurred to me, due to the unique experiences of the blogger or speaker.

And so, after gaining tremendous insights over the years from all these thoughtful and inspiring blog posts, books and talks, it's time to try to give something back. It's time to see if any insights from my own experiences - however small - can be useful to someone.