"sam is typing..."

The toolbox is a metaphor used often in software development. It refers to a persons knowledge of approaches they can apply. This refers to more than only literal software tools. It is also meant to represent all of the patterns, libraries, techniques and, well, everything that you know.

Software dev is full of metaphors. I think this is because they're a good way to talk about huge ideas without too much jargon. While there's nothing wrong with jargon in the right context it's usually a bad idea to assume everyone knows it, which makes metaphors a popular choice. Using metaphors like this is a way to condense big ideas into something smaller that we already understand.

The toolbox is useful for a few reasons. It shows us that there are different approaches to the same problem, which isn't always obvious. There's a reason the saying 'everything looks like a nail when all you have is a hammer' exists. Our toolbox will help us get around that by showing us how many tools we have to choose from. It also makes it okay to spend some time investigating the right tool, and lets us recognise if we don't have it yet and need to go look for a better one (or even make our own, fit for purpose). The toolbox lets us compare tools and talk about their tradeoffs. I mean, everything is a tradeoff for devs, and tools are no exception.

The toolbox also lets us learn new things without having to use them right away. A common criticism of some devs is that every new project they do is different and filled with only new shiny approaches and tools. This can sometimes be a fair criticism, especially in the JavaScript scene. This lets us put the new approach in our toolbox for later, knowing we can take it out when the time is right.

The toolbox isn't a perfect metaphor. No metaphor is, and it's important to look at the places it fails. We don't want to fall into the trap of thinking the toolbox metaphor should be applied everywhere. For one, software is way closer to an organic system than the toolbox metaphor suggests. Pieces of the codebase grow while others die back. Things morph and change subtly over time. It isn't built once and then 'done'. Using a tool is also closer to selecting an approach, rather than a literal tool. In some cases, like when the right aproach is to use a pattern in your code, that 'tool' sits there in the codebase plain to see until it is deleted or changed beyond recognition. It isn't just used and put away.

Overall, it's a good metaphor to use during the design process and during the initial part of implementation, and gets less useful during the actual implementation stage. It works well as a planning metaphor. Keep your toolbox in good shape, don't use tools that arent appropriate for your situation, and you'll do well.