I've found that being mainstream is the most important factor in choosing tooling. Being mainstream has incredible advantages. It means you're going to find lots of help, resources, answers to questions, sample code, and high quality and well maintained libraries.
Right. That's what's impressive. They built the right tools, presumably during previous projects. The tools they built were useful enough to enable future work.
You may not know what tools you will need in the future but when you need a new tool you can build it in a way that it is reusable.
In other words a good tool solves an abstract problem. I don't need an Ikea-Bergmund-chair-leg-attacher. I need a screwdriver.
Once you have a toolbox full of these basic tools you are better prepared to tackle those future projects.
I dont disagree with this, but I also see in our case that good tooling is immensely valuable in keeping things consistent and moving forward (in the same direction) without having to discuss every change.
Mastery of tooling is easily the most successful nerdsnipe you can do in an org. It abounds with metaphors to sharp physical tools that are ironically required to perform tasks safely. And, to an extent, it is obvious to see that people with more mastery over their toolchest will be able to outperform those of lesser mastery.
However, it is also easy to find evidence that quality of tooling does not translate to quality products in software. Not the least piece of evidence is Linux and the rise of free as in beer tooling.
I think it can easily diverge into navel gazing. It isn't that tooling is unimportant. But that it should not become the focus. If you want to make quality products, obsess over the quality of your product. Don't get distracted by what you know about what went into it. Focus on the product. Period.
Yes, you will at times have to settle for a proxy measure. No, they will not be perfect. Nor can they be. Don't fixate on a single metric, but collect many and constantly ask yourself what the metric is telling you about the product. Not about itself.
Really love this style of thinking. Tool building done well can have such a huge impact on everyone around you; especially if it’s easy to build good tools.
We’ve been building something with this in mind; to try to make it way easier to focus on the important parts of tooling, and abstract away all the annoying boilerplate. You might be interested in checking it out at https://ab.bot. We’re in the current YC batch and had a Launch HN a few weeks ago.
Yes, agreed, strangly underrated, as perhaps most people have their awareness of tools running in the background. We already see the importance of tools so it's not a hard leap to understand EVERY domain needs better tools to be more effective.
Your day is close enough to the action. My dad, a mechanical engineer, worked on part of the breathing apparatus used in the Apollo program. That's a part of that problem, small and perhaps not glamorous but close enough.
I'd say you're damn close. Closer than I've ever been to anything real unless you count buying a programmable robot vacuum cleaner kit instead of the normal one so I could in theory program my vacuum cleaner to do cool stuff, not to mention at modules!
If it's any comfort, had it been me, you'd have gotten a promotion on the spot. Toolmaking requires a delicate balance between realism, and sytemic abstraction. You have to simultaneously keep the view of system-as-world and end-tool-in-the-world firmly in mind simultaneously. Sadly, with programming, it can be very difficult to keep oneself from getting bewitched by overall system complexity in ways that end up having an adverse effect on the usability of the tool itself.
reply