6 ms·

Developers I have met rarely if ever make tools... Maybe they are more like cache-making rodents?

lpapez 3y ago
Unless you are truly pushing the envelope of tooling development, I consider learning to use an existing tool well far more important than inventing a new one. The developer tooling has become so complex that it takes a truly exceptional individual to build a tool on their own, and the vast majority of tools are built by teams of people. That is why you rarely meet developers who build their own tools, it's a often futile effort usually better spent elsewhere. In fact I would go on to say that in my personal view people who do roll their own tooling usually do so due either to ignorance of existing tools or as a fun little side-project. Woe be to those who push their opinionated tools onto their teammates...
- Swizec 3y ago
  Every abstraction is a tool that we build for ourselves. If you’re not building those, wtf are you even doing? Please assume the lowest possible bar for “abstraction” in my argument. A function that calls 2 other functions is an abstraction.
  - hyperthesis 3y ago
    True. But the quality of an abstraction is also significant. A poor abstraction is costly in complexity. In a chain of tools, even modest complexity multiplies, and quickly becomes unmanagable. Whereas a clean abstraction (ideally) resets complexity to zero.
- OJFord 3y ago
  If someone shows you how to take a stick and a stone and make a hammer, and you imitate, you're certainly not 'pushing the envelope of tooling development', but you're still making a tool. As the most prevalent & familiar here modern example, I'd suggest writing to .bashrc & using ssh-keygen are 'making tools' in the relevant sense.
  - trashtester 3y ago
    Attaching a the stone to a stick makes a very advanced hammer. While we've been using hammers without sticks for over 2 million years, hammers with sticks only came around 30k years ago.
    - undersuit 3y ago
      And none of the improvements on hammers for specific actions count. The orientation or prongs on a modern hammer isn't going to stymie a neanderthal unless they are destudding drywall.
- CoffeeOnWrite 3y ago
  You define tooling too narrowly. That custom script that the team uses to cut a release branch and notify people with contributions on the branch that it's being deployed? That's a tool, that itself uses off the shelf tools/products (eg. perhaps Python, GitHub, Slack). And it could possibly be a very helpful tool that saves manual effort and improves results, for a fairly low cost. Sure you can spend too much time and effort building tools, rather than focus on meeting the most important business objectives, and we've all met developers that do that. But you can certainly build too few tools, as well.
  - eternityforest 3y ago
    Somewhere there's probably something that already does that though, and it probably also does 5 other things currently done by a custom script.
    - CoffeeOnWrite 3y ago
      If your coworker wrote such a script, would you respond positively or gloomily? Maybe they researched and found actually all the options out there have whatever drawbacks that they don't fit the bill. Maybe they didn't bother to research because it only took them 10 minutes to script that manual process we perform multiple times a week, and they were curious to see if they could improve that. Maybe some of the 5 were pretty good actually, but the coworker has some specific ideas how their "6th" new tool could be better in certain important ways. The good off the shelf tools make it easy to build on them with custom tools to fit your purpose. I really don't mind if people lean a bit one way or the other in their inclination toward custom tools. But I do expect people to be supportive of attempts to build nice tooling, and show a curiosity toward the trade offs, and willingness to try an experiment. Don't be afraid of building a tool, hacker friends. If nobody else displays an interest in what you build, or it doesn't turn out to really save time, or it costs too much to maintain.. you can ditch it! You are a professional with good critical judgment whose ability to improve the productivity of your group and provide repeatable "executable documentation" will carry you far in your career. Let your creativity shine, and have fun.
simonh 3y ago
Software isn’t a tool?
- Koshkin 3y ago
  Well, the hominins made their tools for themselves. Software engineers making tools for themselves is a rare exception.
  - AlotOfReading 3y ago
    Pretty much all of programming is constant toolmaking, usually much more abstract and sophisticated than anything in the article. Every subroutine, utility function, library, and interface, for example.
  - mr_toad 3y ago
    I doubt most tool makers make tools for themselves. The guy at the hammer factory isn’t using all those hammers.
- NoMoreNicksLeft 3y ago
  It is, but most developers I know (including myself), spend more time in meetings talking about what the tool should be except in the concrete details that would allow any of us to craft the tool while never actually getting around to making it. Occasionally, we'll spend time criticizing broken tools that someone made in ways that let us feel like we're getting better at making non-defective tools. However, we definitely know theoretically what an acceptable software-as-a-tool look likes, and we're constantly the lookout for one if someone were to stumble upon it. In the meantime, we make mock tools sort of like how the Allies made inflatable tanks, and we deploy those in places to keep the enemy... er, customer, guessing about our true intentions and position within the market.
  - intelVISA 3y ago
    > most developers I know (including myself), spend more time in meetings talking And as things fell apart, nobody paid much attention.

Unless you are truly pushing the envelope of tooling development, I consider learning to use an existing tool well far more important than inventing a new one. The developer tooling has become so complex that it takes a truly exceptional individual to build a tool on their own, and the vast majority of tools are built by teams of people. That is why you rarely meet developers who build their own tools, it's a often futile effort usually better spent elsewhere. In fact I would go on to say that in my personal view people who do roll their own tooling usually do so due either to ignorance of existing tools or as a fun little side-project. Woe be to those who push their opinionated tools onto their teammates...

Swizec 3y ago
Every abstraction is a tool that we build for ourselves. If you’re not building those, wtf are you even doing? Please assume the lowest possible bar for “abstraction” in my argument. A function that calls 2 other functions is an abstraction.
- hyperthesis 3y ago
  True. But the quality of an abstraction is also significant. A poor abstraction is costly in complexity. In a chain of tools, even modest complexity multiplies, and quickly becomes unmanagable. Whereas a clean abstraction (ideally) resets complexity to zero.
OJFord 3y ago
If someone shows you how to take a stick and a stone and make a hammer, and you imitate, you're certainly not 'pushing the envelope of tooling development', but you're still making a tool. As the most prevalent & familiar here modern example, I'd suggest writing to .bashrc & using ssh-keygen are 'making tools' in the relevant sense.
- trashtester 3y ago
  Attaching a the stone to a stick makes a very advanced hammer. While we've been using hammers without sticks for over 2 million years, hammers with sticks only came around 30k years ago.
  - undersuit 3y ago
    And none of the improvements on hammers for specific actions count. The orientation or prongs on a modern hammer isn't going to stymie a neanderthal unless they are destudding drywall.
CoffeeOnWrite 3y ago
You define tooling too narrowly. That custom script that the team uses to cut a release branch and notify people with contributions on the branch that it's being deployed? That's a tool, that itself uses off the shelf tools/products (eg. perhaps Python, GitHub, Slack). And it could possibly be a very helpful tool that saves manual effort and improves results, for a fairly low cost. Sure you can spend too much time and effort building tools, rather than focus on meeting the most important business objectives, and we've all met developers that do that. But you can certainly build too few tools, as well.
- eternityforest 3y ago
  Somewhere there's probably something that already does that though, and it probably also does 5 other things currently done by a custom script.
  - CoffeeOnWrite 3y ago
    If your coworker wrote such a script, would you respond positively or gloomily? Maybe they researched and found actually all the options out there have whatever drawbacks that they don't fit the bill. Maybe they didn't bother to research because it only took them 10 minutes to script that manual process we perform multiple times a week, and they were curious to see if they could improve that. Maybe some of the 5 were pretty good actually, but the coworker has some specific ideas how their "6th" new tool could be better in certain important ways. The good off the shelf tools make it easy to build on them with custom tools to fit your purpose. I really don't mind if people lean a bit one way or the other in their inclination toward custom tools. But I do expect people to be supportive of attempts to build nice tooling, and show a curiosity toward the trade offs, and willingness to try an experiment. Don't be afraid of building a tool, hacker friends. If nobody else displays an interest in what you build, or it doesn't turn out to really save time, or it costs too much to maintain.. you can ditch it! You are a professional with good critical judgment whose ability to improve the productivity of your group and provide repeatable "executable documentation" will carry you far in your career. Let your creativity shine, and have fun.

simonh 3y ago

Software isn’t a tool?

Koshkin 3y ago
Well, the hominins made their tools for themselves. Software engineers making tools for themselves is a rare exception.
- AlotOfReading 3y ago
  Pretty much all of programming is constant toolmaking, usually much more abstract and sophisticated than anything in the article. Every subroutine, utility function, library, and interface, for example.
- mr_toad 3y ago
  I doubt most tool makers make tools for themselves. The guy at the hammer factory isn’t using all those hammers.
NoMoreNicksLeft 3y ago
It is, but most developers I know (including myself), spend more time in meetings talking about what the tool should be except in the concrete details that would allow any of us to craft the tool while never actually getting around to making it. Occasionally, we'll spend time criticizing broken tools that someone made in ways that let us feel like we're getting better at making non-defective tools. However, we definitely know theoretically what an acceptable software-as-a-tool look likes, and we're constantly the lookout for one if someone were to stumble upon it. In the meantime, we make mock tools sort of like how the Allies made inflatable tanks, and we deploy those in places to keep the enemy... er, customer, guessing about our true intentions and position within the market.
- intelVISA 3y ago
  > most developers I know (including myself), spend more time in meetings talking And as things fell apart, nobody paid much attention.