[rwhitman]

It guess the counterpoint to this is that tools are fun to build and it can be easy to fall into the trap of spending too much time building tools instead of other priorities. I've seen a lot of developers over the years use tool building as a way to procrastinate on more important tasks (myself included), or build things that just become obsolete and useless within weeks

[hcarvalhoalves]

You can avoid the trap applying the usual rule of three [1]. You do something manually once or twice - once you find you need to do it the third time, it's a good indication you should automate.

[1] http://en.wikipedia.org/wiki/Rule_of_three_(computer_program...

[AnimalMuppet]

But don't short-circuit this. If you build after the first time, you may well not know enough to build the tool right. After you've done the process more than once, you have a fair idea of what the tool needs to do.

[blowski]

Exactly - the Agile Manifesto came to mind as soon as I read the title. i.e. "Individuals and interactions over processes and tools"

[AnimalMuppet]

I don't think the Agile Manifesto is saying "Don't build a bash script, type it in by hand each time." I think it's saying "Don't assume that a vendor can sell you software to make agile happen - it's up to the people to interact with each other in less-burdensome ways."

[mooreds]

Or a tool can suck up more time than it saves.

http://xkcd.com/1319/

[badman_ting]

Yes, anytime you're working on something that's supposed to be for a business and you're going "wheeee!" and "wow so cool", you should be questioning whether you're building it because it's needed, or because it's fun to build. Engineers have a way of doing things they enjoy, and then retconning it as important and necessary, even noble.

This is also my problem with people who talk about being "builders" and "makers". Are you building and making things that need to exist, or sating your need to build and make? Not that that's inherently wrong, but it is certainly not inherently noble or impressive.