We’ve been building a house for my in-laws and it has been really interesting to watch things come together. I’ve been especially interested in the framing process after watching Essential Craftsman and working on leveling up my (very limited) construction skills. One big difference between a professional framer and a home carpenter is the set of tools. The framing team building the house had a large compressor, hundreds of feet of hose, multiple large nailguns and giant magazines of nails. While some DIYers may splurge on a nailgun, it is likely an electric, battery powered version that isn’t intended for constant daily use. Another potentially more expensive option would be to use screws as fasteners, while using a hammer is a totally reasonable tool for most jobs. You could argue that a nailgun is much better than a hammer, but I think if you’re not framing houses all day, a simple hammer is an ideal choice. After all, no one wants to lug in a compressor and hoses just to hang a picture.
Another element to consider is that someone doesn’t always know how to use different tools. I know I typically look to screws when I think of a fastener. This is not because of years or experience, an appreciation for the available torque in star headed screws or because I appreciate the holding power of a screw over a nail. To put it bluntly, it is what I’ve used before. I have screws laying around I can use and an electric driver. Even when I tried to use pocket holes for a project, I got sick of messing with the handy jig and just free handed the screws. Thinking back, I bet nails could have been easier, but when you have an electric driver, everything is a screw.
At work when we think about the products my team delivers on, we consistently think about this reality. There are professional teams that need the complexity of Kubernetes and other teams that are ok subcontracting out that complexity to a PaaS. But most folks are just DIYers that want to build something and see what happens. Success is relative. Our platform is just a tool. People choose what aspects of the platform based on what they know and not through some objective process that filters down a well defined set of choices to the perfect suite of services. Instead, people take their ideas and prototypes and try to make them public. If they run a program on their laptop, they want to copy that environment to our platform and run it. Success is seeing the web app or site live. It makes little to no difference whether or not that site is being served over some container networking with a Nginx sidecar to handle TLS termination. If they can go to a URL and see something, then they succeeded.
The next steps after the initial success of running something is to find an audience. Again, success is relative. Not everyone is building the next unicorn startup. Not everyone looks for an exit. In this phase, we should see people starting to get better with the tools. That doesn’t mean they will use the latest and greatest tools in the industry. Craftspersons aim to produce great work and the methodology is a personal choice. Some wood workers take great pride and pleasure from leveraging ancient techniques and extremely simple tools. Others dive headlong into CNC machines, CAD and power tools that make precision the norm. The constant is that the output is personal and the tools are simply part of the building process. There are things to learn about using chisels just like there is a wealth of knowledge how to automate cuts with a CNC. Once someone starts finding that audience, that is when success shifts, which may force reconsideration of the tools.
Success when building is a balance of output, acceptance, and expectation. Success requires output. The output can be broken, but there needs to be something. What’s more, output needs an audience to accept it. Who is the output actually for? Finally, does the audience’s perception match the expectations of the builder? For example, if someone is an exceptional programmer, quickly building a system that doesn’t have 100% test coverage, automated CI/CD, instrumentation, etc. may not be considered successful because the programmer has a high technical expectation around the system being created. The programmer may not truly care if anyone uses the system, therefore the real audience is likely programmer themself. To contrast, if someone is trying to build a business and can’t seem to find customers, then no amount of technical excellence is going to be considered a success. If these two people are working together, as a tool provider it is your responsibility to give both parties the potential to succeed. The programmer should have options to fulfill the desire for a maintainable system while ensuring the business serves its customers.
The complexity of success is why tools go far beyond hammers and nailguns. Tools reflect culture and not all cultures are complimentary. When I first started programming, I learned PHP. It was exceptionally easy to write some code, copy it to a shared web host and see the result. As I dove deeper into programming, I was drawn to other communities that had a different culture. The hoops I had to go through to deploy a Python web application were an order of magnitude more than when I copied my files to my www directory on my shared hosting account. And yet, I was OK with the pain because I enjoyed writing Python more than writing PHP. The tool was harder to use, but I found success because my output was accepted by others in the Python community and I began to live up to my own expectations around my ability.
Great tools help you find success. Your version of success is a function of the output, how it is accepted and how that aligns with your own expectations. Tools define how you build and how you build involves culture. Therefore, if your product is a tool, it is critical to understand how your tool builds culture and results in your user’s success. No tool is going to be perfect for all occasions, but understanding success means you can make a perfect tool for someone.