All the chefs I know go out to eat way more than anyone else I know (don't know any bakers, though). Graphic designers I know, buy art and graphic designs (don't know any jewelers, either). Musician friends buy tons of records and tickets to live shows, friends who brew, buy more beer than friends who don't brew.
You hit the point on the head. The chefs might go out of their way to buy their direct product (consumer software, like games or hardware, like ipads) but would not buy a shit ton of kitchen pots beyond the basics.
I have a family member who's a young musician, and he says musicians don't really care about audiophile grade speakers or headphones really.
I imagine people who like to make things but don't like to spend money are attracted to software in particular because it is one of the few things that one can make with very little investment. Many of us may have found different loves if other hobbies weren't so expensive. This, perhaps, biases the type of person you find in the profession.
The disconnect I don't think is about protecting their turf.
I think it's mostly about 1) not having an instinct for how powerful the tools are and 2) not being able to internalize the value of leverage vs. cost.
$1000/year 'feels' expensive to a developer. That's 'a lot of money'.
But if it makes you >1% more productive, it's worth it.
Some of these tools are not just productivity enhancements but multipliers.
But that takes a different kind of intuition that very few people have naturally, you kind of have to be in a position to make those decisions.
Those that have the instinct often are not programming.
I’ve paid for various tools over the years: ultimately, I’ve never really found that the commercial tools are significantly better for the problems I have. I’ve generally found that Emacs and/or Unix shell utilities make it really easy to make a tool that solves exactly the problem you have while commercial tools end up having frustrating limitations or are really hard to learn because they solve the general case instead of the 70% case that you actually have.
> But if it makes you >1% more productive, it's worth it.
For an individual, it depends on whether your compensation is tied closely to productivity or multiplication.Being 1% more productive is not going to get your average person anything in a corporate environment.
"What's in it for me? Right now? In the short term?" is not very civic posture.
The 'bigger the corp' the 'bigger the productivity gains' available to the team and customers. A 1% gain would probably be worthwhile though it's probably the purview of a director or CTO, that said, developers are part of the process.
Making little productivity gains here and there is literally how the world moves forward.
It's why we are wiping our rears with toilet paper and not seashells.
One of the commenters made the point that 'such tools are not always very useful' which is entirely reasonable, but to the extent they are, the math works.
In an adjacent area - we use Jira, which we all loathe, but it's considerably better than nothing for example, it does the job and it's worth 20x the meagre cost to us. Such is an example of productivity leverage. (And of course, it's not always the case that it works out so well)
You get paid next year a rate based on how productive you are today.
Even when companies don't give proper raises, this still ends up applying when you quit and go to another company because you've spent x% more time actually coding instead of waiting or busy work, and you can command a higher salary.
> You get paid next year a rate based on how productive you are today.
Not particularly. While highly paid developers like to pretend the industry is some platonic ideal meritocracy, no one has any real ability to measure individual productivity, or to predict it with any precision in hiring, so, no, that's not a particularly good approximation of reality, certainly not where a 1% improvement would would even be noticeable in the noise of assessment.
Realistically, you might be justified in saying that my pay 5 years from now will be affected by the aggregate productivity in the past of developers generally and the broad, easily observed factors that conventional industry wisdom assesses as individual predictors of productivity within those broad aggregates. But, with that in mind, investing time in promoting online the idea that things I already have on my resume are predictors of productivity, while unlikely to have noticeable real impact, is probably a better cost/benefit trade-off than paying for dev tools, even if my employer was going to let me use personally purchased tools, which they aren't.
Outside of corporate work, in the personal development time I spend which does have impacts on bit actual productivity and my ability to have indicia of productivity that the market values and where I do have the choice of tools, assessing and paying for dev tools is more friction than benefit. I did it more when the gap between paid tools and free tools in quality was much higher and (because the internet as an easy discovery/distribution medium was not what it is today) the friction between the two was closer. Even though at the time the financial cost compared to my means was much greater.
An interesting paradox of the programmer job market is that spending time mastering developer tools and reaping the corresponding productivity improvements at one job has zero value when confronted by a whiteboard coding interview for another job.
But they may have value once you get past the interview.
Don't forget another interesting paradox - spending time mastering tools and technologies tangentially (if at all) related to your current job has low value now, but is also what makes it possible for you to take that another job a year later and double your salary.
This is a negative approach - and the opposite of what you would want on your team.
The narrow view that some 'productivity gain' will result in 'less work' is almost entirely not true, unless you're doing commodity work, like answering calls etc..
An Engineer who can do the work 10% faster because of better tooling, isn't putting himself or peers in jeopardy, rather, moving up the stack a nudge to work on slightly more important problems.
Any company that counts technology as a pillar of competitive advantage needs to adapt responsibly and make process improvements especially as they become normative.
People that work against this are literally a drag on the company, like the kind of unions that forbid other groups from 'moving the hammer because it's not in their job spec'.
Consider that helping the company be more productive is part of your job, and that you're not going to lose work as a result of it, probably the opposite :).
Because you can’t make every tool you’ll need to program effectively. Unlike bread, which only takes hours to make, good tooling will take months to years if done yourself.
All the chefs I know go out to eat way more than anyone else I know (don't know any bakers, though). Graphic designers I know, buy art and graphic designs (don't know any jewelers, either). Musician friends buy tons of records and tickets to live shows, friends who brew, buy more beer than friends who don't brew.