Skip to content

{ Category Archives } software-engineering

Working Effectively with Legacy Code

I gave a talk to my team at ARM today on Working Effectively with Legacy Code by Michael Feathers. Here are some notes I made in preparation, which are somewhat related to the talk I gave. This may be the most important book a software developer can read. Why? Because if you don’t, then you’re […]

Full Stack

A full-stack software engineer is someone who is comfortable working at any layer, from code and systems through team members to customers.

The package management paradox

There was no need to build a package management system since CPAN, and yet npm is the best. Wait, what? Every time a new programming language or framework is released, people seem to decide that: It needs its own package manager. Simple algorithms need to be rewritten from scratch in “pure” $language/framework and distributed as […]

Dogmatic paradigmatism

First, you put all of your faith in structured programming, and you got burned. You found it hard to associate the operations in your software with the data upon which they act, and to make sure that the expectations made on the data in one place are satisfied when that data has been modified in […]

Layers of Distraction

A discussion I was involved in over on Facebook reminded me of some other issues I’d already drafted for this blog, so I stuck the two together and here we are. Software systems can often be seen as aggregations of strata, with higher layers making use of the services in the lower layers. You’ll often […]

Joe Armstrong thinks we don’t need modules in software. Instead, all functions should have unique names and be published in a global database.

The reasonable effectiveness of developer tools

In goals upon goals upon goals, I suggested that a fixation on developer tools is misplaced. This is not to say that developer tools are unhelpful, nor that they can’t have a significant impact on our work. Consider the following, over-restricted, definition of what a programmer does: A programmer’s responsibility is to turn a computer […]

Code longevity

I recently wrote about the impending centenary of applied computing; a time when we could reflect on the first hundred years to make it easier for people to progress beyond our position into the second hundred years. This necessitates looking at the things we’ve tried, the things that succeeded and the things that failed. It […]

Preparing for Computing’s Big One-Oh-Oh

However you slice the pie, we’re between two and three decades away from the centenary celebration for applied computing (which is of course significantly after theoretical or hypothetical advances made by the likes of Lovelace, Turing and others). You might count the anniversary of Colossus in 2043, the ENIAC in 2046, or maybe something earlier […]

On too much and too little

In the following text, remember that words like me or I are to be construed in the broadest possible terms. It’s easy to be comfortable with my current level of knowledge. Or perhaps it’s not the value, but the derivative of the value: the amount of investment I’m putting into learning a thing. Anyway, it’s […]