I built a workbench

Posted on July 23rd, 2015 by The Erstwhile Developer

I've spent the last 3 months building a workbench. When I started I didn't have anything to work on except and old piece of door and the planks of wood that I'd purchased from Bunnings. By the end I had a fully functioning bench complete with dog holes, planing stops and a tool well. This bootstrapping process got me thinking about the workspace we all use on a day to day basis.

To me woodworking and software engineering are very similar: Both require an analytical mind and the ability to work round problems creatively, both require a good understanding of the medium within which you work, and both come with a dizzying array of tools to help ensure that you're doing your job quickly and efficiently. To me, the workbench is then most important tool for both woodworkers and software engineers. Allow me to explain.

The workbench (or bench) is often perceived as a glorified table, but is arguably the most important tool in a woodworkers arsenal. Without a bench joinery and cabinet making become difficult, cumbersome, error prone, and slow. The job of a workbench is to provide a stable platform on which to hold your work in a way that makes easy and efficient to create. More than that it elevates the work from the ground preventing damage and (because it's a known 'good' reference surface being both flat and square) it reduces the risk that your work will end up out of kilter.

As software engineers workbench is our IDE, it provides a lot of the same capabilities: holding our work, making it easy for us to manipulate and reducing the risk that we do something wrong. The thing is that although a lot of us use our IDE to look at and interact with our work what we don't all do is utilise that same platform to make our work faster, more efficient and less prone to error. And if we're not using our bench to it's fullest then we may as well just use a table.

To pick an example: For the Java developer, knowing that their IDE provides a way for them to automatically create getters, setters and constructors; that it can help you navigate through your codebase or that it will happily help you refactor your work is important because it reduces the risk of error and generally speeds up the development time for those repetitive and mundane tasks that would otherwise get in our way and slow us down.

Stretch the analogy a little further, as a woodworker you wouldn't use a black and decker workmate to build a dining room table and you wouldn't use a 12 foot André Roubo workbench to cut timber for a stud wall partition. When it comes to our IDE it's the same thing, we need to pick the right tool for the job.

In order for us to be effective in our work we need to ensure that our development environment is the right one for what we need to do. With a workbench the fundamentals are often the same but the size and scope of what we need to do alters. IntelliJ (for exmaple) is great for application development with Java but probably wouldn't excel at smaller scale web development in Node. Conversely you probably wouldn't use Atom, Sublime, or Textmate to do all your Java development.

Yes, this is all obvious stuff, but as developers it's easy to fall into a "When all you've got is a hammer everything looks like a nail" frame of mind. Trying to use an editor such as Atom for Java development because Atom is all you know will likely result in a sub optimal experience you'd probably be better to embrace the unknown and try intelliJ (or eclipse) which will assit you a lot more in getting things done.

Every project and every developer is unique. Sure, there are a lot of similarities between projects and the developers that realise them, but nothing is entirely indentical. It's useful to remember that the IDEs that we use can be customised to fit our own set of specific needs, whether it be plugins to make your IDE feel like our favorite text editor, or ensuring that the new templating language that you're using has appropriate syntax highlighting and code completion. It's also worth noting that our IDE's can quite often be configured at a lower level to utilise more memory, automatically download dependencies or stop performing spell checks on all our variables.

The thing to bear in mind is that your IDE should be working for you and not the other way around. If there are things getting in your way then you should invest some time into resolving them. Although this may take time away from your development work now, it may pay dividends in the future as you become more efficient. 

← back to the blog