If you grew up in the 90s, chances are you owned a portable cassette player, portable Walkman CD player, or a small stereo you put in your bedroom. All this “stuff” would eventually get busted or old, and you would have to replace it with the latest and greatest gadget being advertised on TV. I relished the moment my cassette player or small radio broke. Not because I wanted to take a bat and go Office Space on my device, but rather it gave me the permission from my parents to take the device apart since it would be thrown out anyways.

The act of taking something apart back then was surprising and educational at the same time. Now that all our “devices” are digital and our data is in the cloud, it’s more difficult to do this today. When was the last time you tried taking apart your iPhone after it broke? Chances are it’s sitting in a shoebox somewhere along with your iPhone 2 and maybe a flip phone. There is something visceral and even therapeutic about unscrewing the little screws around the frame of a small radio. The noise the plastic makes when the sides unhinge from the frame to show the innards of the speaker and wiring.

The most fascinating aspect of taking apart this radio is the cognitive dissonance you experience from seeing the exterior of the device day in and day out, and what you finally see behind the curtain when the device is taken apart. You say to yourself: “so this is how the power gets distributed to the speaker.” Whether you are working on a startup in the physical or digital world, I argue the most important skill you should have as a maker is the desire to take things apart.

Not accepting face value

In The Wizard of Oz, we all know the man behind the curtain was not some big and powerful character, but rather a small person who, through deception, was able to trick all the protagonists in the story. Often the best makers and hackers out there refuse to accept the status quo, and change the world by building something that goes against the grain. Napster, Airbnb, Uber… The list goes on and on.

If we boil this down to building an app, launching a new clothing line, or recording your first track, at some point along the way you will have to “take apart” the current product or process you are trying to innovate on. Back to the example I gave about taking apart a radio, the only way you will know how to build a more advanced and cooler radio is by understanding how current radios work. One of my favorite examples of this is from AMC’s Halt and Catch Fire. The main characters take apart an IBM PC to decipher the BIOS in order to build their own version that is faster and more efficient. This scene captures the competition in the personal PC industry in the 80s and 90s:

I would call the two characters in the scene above makers. Inherent in their personalities is the drive to build something new and different, but the only way they could do this is by understanding the world around them (in this case it was IBM’s PC). From taking something apart, you learn all the patterns, nuances, and idiosyncrasies of the application or device that can spark new ideas and connections. You no longer have to accept the application or device at the exterior level since you know how the darn thing is built!

The no-code movement for makers

Colin Winhell wrote a great post about the no-code movement and why it is important to makers. I definitely agree there are many platforms that abstract the coding required for makers and startup founders who want to prototype something quickly. When I first learned how to build my own websites, I relied heavily on frameworks such as WordPress that required almost no coding to get something up and running. There are a few traps makers should avoid, however, when it comes to the no-code movement:

  • Unwilling to learn new tools and platforms outside the no-code tool you are comfortable with
  • Thinking the no-code tool is the ceiling of how “technical” you need to get with your startup idea
  • Focusing too much on the tool rather than the learning

I want to emphasize the last point since during the prototype phase, you should be trying to learn as much as you can about the process, internal operations, customer feedback, etc. so that you can iterate quickly on your idea. This famous cycle from Eric Ries’ The Lean Startup comes to mind:

No-code and know (a little) code

Makers who enjoy taking things apart to learn and to build new startups should naturally want to know how to code (a little).

When I was a financial analyst, I never thought I would be good at Excel. Seeing some of the senior members on my team create super complicated models with crazy long formulas made me feel like I would have a short career as an analyst. I always thought Excel would be easier to learn compared to what software engineers did, but at the time, Excel formulas were just as foreign to me as a Python script.

I took some classes here and there to learn Excel, but the #1 tactic that helped me learn to write formulas and build models was taking apart others’ spreadsheets. I could see how cells were being referenced; how one misplaced dollar sign could change the entire model. I no longer saw a financial model as a large complicated mess of sheets and formulas, but rather as a bunch of small building blocks working well together to create something much bigger than any single object in the model.

As I learned how to build websites, I took on the same spirit of wanting to take apart the website to see how one little CSS change would change the look and feel of the website. A website, similar to an Excel model, is a bunch of small building blocks dancing in perfect symphony to create something more beautiful than all parts combined.

The key learning here is that you don’t need to learn how to code if you are a maker, but you should want to know some code to make quick changes here and there. Knowing just a little code gives you a lot of advantages compared to going whole hog on the no-code movement:

  • Understand the basics of how any programming language can work regardless of platform
  • Being self-sufficient for small changes to your application
  • Knowing there is no limit on what you can learn

If you are not comfortable getting into the weeds just yet, there are still some amazing no-code resources out there like Colin Winhall’s No Code Zone and Bram Kanstein’s No Code MVP.

Is B2B the next big thing to take apart?

I’ve gone from taking apart Excel files to websites which I consider to be on the “technical” side of things. Going back to the section about not accepting something for face value, what if you could take apart common models of behavior? What I mean by this are things like team collaboration, project management processes, and tracking sales leads. These are common terms you’ll hear in the B2B world. At the heart of this movement is a slew of applications like Slack, Intercom, and even Gmail that are replacing:

  1. The tools we use to communicate and collaborate
  2. The social and behavioral models we have in the workplace

Today, I spend my time taking apart old business applications and software. I enjoy stripping these applications down to their building blocks to understand how these components can be put together in a way that is meant for the modern team. When I discovered Coda as a user (I currently work there now), I joined a community of makers who wanted to build tools to match their own workflows rather than having the IT department at their companies dictate what tools they had to use. It is very liberating to know that I still don’t have to know how to code, but with just the knowledge of Excel formulas, I can build a fully-functional application that rivals large SaaS applications.

On the second point, we’ve seen this happen over the years as workplace attire becomes more casual and working remotely on a distributed team becomes commonplace. What is interesting, however, is that the tools we use can cause actual change in how we work together. If you “take apart” how you communicate with your team, does it have to always be face to face? Google Hangouts, Zoom, and Webex proved that this is not the case.

Deciding your next step

If you decide to dive right in and take apart an app or some process, the maker instinct should be to learn from the experience, and take that to the next project you decide to take apart, and put back together again. Too often we take things for their surface value, but once you peek behind the curtain, you’ll see that the inner workings are not as complicated as they appear. Do you have the courage to take the next step?

This article was made possible by MakerPad, the platform to learn how to build powerful applications without code.

What's your reaction?