5 ms·

My head is nodding at the intention here, but it's important to remember this reactionary attitude can be damaging as well. That is missing from the post. Spec

My head is nodding at the intention here, but it's important to remember this reactionary attitude can be damaging as well. That is missing from the post. Specifically, reactionary conservatism about tools and services can be a competitive disadvantage. In several workplaces I have seen this attitude co-mingle with pride in original code, and result in a counter-productive NIH (Not Invented Here)[0] attitude (reinventing wheels). Macho/heroism makes it worse. While trend-following can be inefficient, if the engineers are both excited and humble and ready to weigh many trade-offs, this inefficiency might be "cheaper" than reinventing wheels for all problems. Cue platitude: it takes balance :) [0]: https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here --------------------------------------------------------- EDIT: To clarify I'm talking especially about _uninteresting problems,_ for which there may be an obvious off-the-shelf solution, such as when I've seen engineers invent a build system from scratch (and then cost _lots_ over years as that custom thing needs maintenance) ... when their needs could have been met by the language's standard tooling and using its plugin architecture. Or, when "just use sticky notes and a whiteboard" gets so stubborn that a growing team stays in chaos for lack of organization. On the other hand, it is quite bad when trend-following causes not just churn (switching tools), but overkill that introduces tons of cost and risk. i.e. distributed systems where you didn't need one. Relevant on this point: You Are Not Google by Ozan Onay https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

jmull 8y ago
I took this maybe in a different way. I don't think the point is, "no need for so much software tooling" but rather, "software tooling by itself isn't sufficient." (And that "underlying hard-work, the focus on stuff that matters, and courage to make a decision" are much more significant.)
nine_k 8y ago
The point of the text is that a need, and an understanding precede the use of any tools. The use of a tool without a need or an understanding does not help at best, and is harmful pretty often. You do not become a photographer by buying a lot of gear. You train your eye, study, and maybe buy gear eventually when you know why you need it. You do not become a software developer buy buying a bunch of supercomputers. You study, you start with smallest things, and maybe you buy hardware eventually, or deploy a lot of cloud instances, when you know why you need it. You do not become a successful company by quickly raising tons of capital. You study, learn about the markets and the needs of your prospective customers, start with building rather simple things, and maybe eventually you take hefty investments, when you know why you need it. You can go on and on. The old adage is to use the right tool for the job. This begins with understanding the job, and understanding the need of tools. Then you can choose the tools. Starting with tools, especially expensive tools, and believing that the use of these tools will automatically help achieve success, is a mistake.

jmull 8y ago

I took this maybe in a different way. I don't think the point is, "no need for so much software tooling" but rather, "software tooling by itself isn't sufficient." (And that "underlying hard-work, the focus on stuff that matters, and courage to make a decision" are much more significant.)

nine_k 8y ago

The point of the text is that a need, and an understanding precede the use of any tools. The use of a tool without a need or an understanding does not help at best, and is harmful pretty often. You do not become a photographer by buying a lot of gear. You train your eye, study, and maybe buy gear eventually when you know why you need it. You do not become a software developer buy buying a bunch of supercomputers. You study, you start with smallest things, and maybe you buy hardware eventually, or deploy a lot of cloud instances, when you know why you need it. You do not become a successful company by quickly raising tons of capital. You study, learn about the markets and the needs of your prospective customers, start with building rather simple things, and maybe eventually you take hefty investments, when you know why you need it. You can go on and on. The old adage is to use the right tool for the job. This begins with understanding the job, and understanding the need of tools. Then you can choose the tools. Starting with tools, especially expensive tools, and believing that the use of these tools will automatically help achieve success, is a mistake.