Breadboarding is one of those concepts I didn't fully appreciate until the last couple of years. For those that never took an electrical engineering course, you may be wondering breadwhat?! I could explain, but a picture is all we need:
It's quite simple: a breadboard, also known as a protoboard, is a tool used for the prototyping of electronics, and allows you to experiment with circuit design and not worry about the industrial design needed to house the final product – the purest form of substance over style. So have I suddenly switched careers from data and software engineering to their second cousin electrical engineering? Hardly.
The idea of a "breadboarding" approach to software design has become popular with many companies, especially Basecamp. Here's an excerpt on the topic from their excellent Shape Up book:
It's quite simple: a breadboard, also known as a protoboard, is a tool used for the prototyping of electronics, and allows you to experiment with circuit design and not worry about the industrial design needed to house the final product – the purest form of substance over style. So have I suddenly switched careers from data and software engineering to their second cousin electrical engineering? Hardly.
The idea of a "breadboarding" approach to software design has become popular with many companies, especially Basecamp. Here's an excerpt on the topic from their excellent Shape Up book:
We borrow a concept from electrical engineering to help us design at the right level of abstraction. A breadboard is an electrical engineering prototype that has all the components and wiring of a real device but no industrial design.
Deciding to include an indicator light and a rotary knob is very different from debating the chassis material, whether the knob should go to the left of the light or the right, how sharp the corners should be, and so on.
We’ll use words for everything instead of pictures. The important things are the components we’re identifying and their connections. They allow us to play out an idea and judge if the sequence of actions serves the use case we’re trying to solve.
Now that we're well-versed in some electrical engineering semantics, here's where the "notebook" portion comes into play. If you work in data analytics/engineering/science, and you haven't been living under a rock the last decade, then you're well aware of one of the greatest additions to the data aficionado's toolkit: Project Jupyter. Much like the Raspberry Pi was a gateway drug to learning Linux on a cheap yet powerful computing device that fit in the palm of your hand, Jupyter Notebooks converted numerous roadblocks to speed bumps for those of us wanting to learn Python in an iterative format. While the platform has expanded to include numerous other languages and products (JupyterHub, JupyterLab), it's still one of the most low-friction entry points to create prototypes in code without initial concern towards optimization, documentation, and presentation – it's the ultimate breadboarding tool for data professionals.
There's an ironic elegance to the messiness of your code while you're in that "figure it out" phase. You don't care about unit tests or docstrings, your input cells are littered with hard-coded variables, and there's a steady trail of Stack Overflow copypasta from start to finish. During that exploratory analysis, the only priority is to create that next input cell and move one step closer to the desired outcome. And when you finally get there, boy does that adrenaline rush feel good. You finally crossed the chasm, so enjoy that victory, and afterwards you can shift gears and focus on packaging your code into a shiny box stuffed with software engineering best practices.