Archive

Getting back to writing, and what will happen next.

The way humans do moral reasoning is a mechanism that is often misapplied to purely technical decisions.

Not as simple as it might sound?

Can we boil it all down to non-compositional reasoning?

Generally the most important thing is thinking about which dependencies should NOT exist.

I've spent a year talking about design, let's reinterpret some common design advice in a new light.

There's more to testing than unit tests, and there's more to design than coding.

TDD is about getting fast feedback and reducing debugging effort, and typing is synergistic with those goals.

The system as a whole must be able to respond to an overloaded part.

Or: Don't accidentally implement a database.

Distributed systems must handle failure, so when a call fails, how do we respond?

Failure and time are core to building resilient systems.

Inappropriate uses of sequences and state can be exposed once once we try doing it over the network.

Performance concerns can motivate different choices for data representation, but changing representations can be extremely invasive, and OO is often of little help.

As testing practices have evolved, the role and utility of assertions has changed a lot, and I think it'll change some more.

A short case study on the effects of freezing or freeing an API.

It's 2019! One full year of writing.

Directly comparing two implementations is a powerful testing technique, and we have a second implementation for free surprisingly often.

A kernel of a good design principle, but the law leads to poor outcomes.

These are easily distinct techniques, but also deeply related.

Static or dynamic, a program's design is written in its types.

How do test suites become rigid, and impede (rather than help) design?

Some thoughts on Alan Kay's vision of getting rid of data.

How much of a problem is it to sharply distinguish between different kinds of functions?

Approaches to maximizing resource utilization.

Building concurrent programs with a minimum of fuss.

Concurrency with just one thread: embracing event loops.

The difference, and what is means to design for each.

Oh my. Design for reasoning about code. Testing isn't the only reasoning method.

Variance affects where you get guarantees and where you get restrictions.

A few case studies in designs that lacked the ability to create abstractions.

A comparison case study of a few different designs for UI libraries.

Adapting an existing design to suit new purposes.

A look back to where Model-View-Controller came from, and understanding why it's a thing.

Tight coupling between computing what action to perform and actually performing that action can make things harder than they have to be.

How do we understand what a module offers us? And what is an abstraction anyway?

Modularity is how our little human brains can contruct large complex systems.

Thinking carefully about what our goals even are.

Sometimes this is evidence of over-abstracted design, but sometimes it legitimately makes sense.

General advice about what every programmer should understand when it comes to building secure software.

It's easy to focus on the wrong things.

Types, abstractions, names, and meaning. A look at interfaces, type classes, structural interfaces, and duck typing.

Accidental and intentional complexity, and how we reason about it.

Sometimes we're so immersed in context, we don't see it, and good ideas at the time can be mistaken for universal rules.

Testing on system boundaries can aid us in making changes. Testing elsewhere can sometimes impede us. But types can go anywhere.

Complexity is sometimes the enemy, but smaller is not necessarily better.

A different perspective than I'm used to. Different paradigms offer different pieces and different ways those pieces can be put together.

Every form of useful code re-use involves some form of composition operator. We build the whole out of parts, and the seams have properties.

Composing smaller pieces into a great whole is a powerful design technique.

Property testing still applies well to imperative code. While it's usually harder to test the complete interface, this is mitigated somewhat by invariant checking (asserts).

Property tests are not just more powerful, more general unit tests. They're a different way of thinking, with a different impact on design.

We confront our design in several ways when documenting it. We have to explain our decisions, we have to understand our users, and we have to know what the system boundaries are.

Testing can affect our software design, both for better and also worse. How can we be sure it will have a positive effect?

A short case study breaking down the interesting design aspects of containers.

What can we learn from the design of build tools like Maven? A case study on what works and what doesn't.

Context matters. Sometimes we need to get things done, sometimes we need to build things to last.

A case study on how compilers decouple components from each other using data.

Adding precision, explaining some of my choices, answering 'what about...?', and more.

A fundamental question in program design: how is this type open?

A hypothetical design experiment, and a look at open recursion.

The over-hyped language feature, and how we should cope with it today.

Efforts must be focused on where the system cannot evolve gracefully.

We often mispercieve something that cannot be done as a problem. But often enough, that's a feature.

Our programming languages don't really support us in making good design decisions. They fall short of allowing us to choose appropriate representations.

A standard algorithm for programming and improving the design of our software.