> Finally, if you have senior anywhere in your title or job description: an implicit part of your job is to make the people around you more effective. Diving i

> Finally, if you have senior anywhere in your title or job description: an implicit part of your job is to make the people around you more effective. Diving into – and fixing – tools should be a meaningful use of your time. This, 100x. The internal tools function is often forgotten by other teams when dealing with things like ongoing education, professional development, code quality initiatives and even hiring practices. (Ironically, because a lot of those things end up leveraging tools that the tools teams own!) The tools team should be a rotation or an area for open contribution, not a permanent destination or specialty. > There are downsides, of course. Toolsmiths are at least one step removed from the actual work that's going on – it can be hard to explain what we built to anyone without context (or violating NDAs). Depending on how enlightened your management is, your team might also be severely underfunded for what it needs to accomplish, mainly because the effect of good tools isn't generally easy to measure. The other downside to tool building is that when you build something, you're competing against "there's no tool for this that fits our need", but when you're maintaining and evangelizing the tool your competition is often "open source software on the internet", which can outdevelop you by sheer weight. So you should always bias heavily for buy/download over build, and you should always minimize how much you fork and customize those tools let you get left behind by the broader community.