Posts

The Art of Debugging: Part 0

  Prologue Why is Part 0 published after Part 1? Well I wasn’t sure yet how to write the introduction to this series/book. Books in this category often start by explaining why the problem is worth learning, which feels a bit weird to me. If I’m reading the book I’ve already decided it’s worthy of my attention. Also I’m unlikely to be swayed by an author who has a vested interest in convincing me it’s important. While I was driving to Melbourne for the long weekend an idea struck me; instead of telling the audience how hard the problem is (which you either know or will learn for yourself), I want to tell them why I think the problem is hard. This gives an insight into how I think about the problem at a meta level and sets the scene for what comes previously/next. Plus what’s more meta than a blog series about debugging with out of order execution. Good problem solving skills While Large Language Models have become almost ubiquitous in software development, capable of churning out ma...
Read more

The Art of Debugging: Part I

Image
Prologue This blog is designed to be the first of a multi-part series. If I find the motivation it will become a book. My interest with computers really kicked off when I discovered Linux, the ability to inspect and understand what was going on, including reading the source code, enabled me to gain a much richer understanding of what my computer was doing and why things weren't working how I wanted them to. I have had a pretty unusual career path for a Software Developer, I started as a support engineer for proprietary monitoring software for which I didn’t get to see the source code let alone write it. Then I became a System Administrator, debugging a lot of networking, storage, database, operating systems and more proprietary software. I, like many others, am not satisfied if I fix a problem and don't understand how. My brain has trouble letting go of that feeling. The satisfaction of understanding a bug that has stumped me and others for a long time is almost as addictive as...
Read more

I dislike the term Technical Debt

  5 or so years ago a manager at my company, Leon Messerschmidt , gave a talk to our engineering department called “Why I don’t use the term Technical Debt and you shouldn’t either” and since then I’ve wanted to write my own view on this. Before then I had felt uncomfortable with the term, it seemed very subjective. In the talk Leon described how the term debt was often viewed as a good thing by people with a financial background (as he had) and so gave the wrong impression to non-engineering stakeholders. What Leon advocated for was instead a “Tidy as you go” approach, which reflects a lot of what Kent Beck went on to describe in his series of blog posts and book : If you only have a minute to read, here are the classic software design blunders: Thou shalt not rewrite the whole system. Thou shalt not pause delivery of features for an extended period to fix the design. Thou shalt not delay the first feature to "get the design right". Thou shalt not thoughtlessly demand the...
Post a Comment
Read more