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.
The disconnect is not odd for me. Developers know you will essentially pay for a sub-optimal experience. Proprietary software vendors almost always treat their users as dirt. The piece of software would almost always be better if it were open source. And developers know this.
I think this is a temporary phenomenon. We're still in some ways reeling from 2000 and 2008, where free tools came to dominate (because no one could afford the paid ones).
If you get paid to program, then your employer can pay for tooling (assuming salaried work, if you're a contractor then you need to buy your own stuff).
I think there is some bias in that younger developers are the ones with the time to share their opinions over social media, but also have the least amount of money / influence with which to buy tooling. Certainly, when I started programming, I didn't have any budget for tools. I was lucky to even have a computer. Thus, I had no choice but to use free tools. People hold on to that experience long past the point where the monetary cost of tooling is meaningful.
Influence is the biggest problem, which is why I mention the junior vs. senior divide. When you want to buy software at work, you aren't typically given a budget and a credit card with which to buy the tooling. You have to justify every case. No junior developer wants to be the squeaky wheel that's always begging for cash for tooling, so they do without. Or, if they do decide to buy tools, they're met with the "alternatives analysis" phase of approval -- you invested time learning this tool that you now want to buy, go do that three or four more times while still completing your normal work, to make sure we don't waste any money. (You can see why writing your own stuff from scratch is so popular -- no approval process. You just do it.)
Tools are also special in that they come with a time cost and a dollar cost. I have never seen a product that will save me time without any effort on my part, but would love to buy such a thing if it existed. Instead, you have to pay the fee, and then learn the software. (So the actual cost is your hourly rate * the time to learn, plus the actual dollar cost. At least free projects or writing it yourself don't have the actual dollar cost. The training cost leaves the most sour taste in my mouth. I've wasted countless hours reading, excuse the term, dogshit, documentation for something I paid a lot of money for. Every time this happens I think to myself that writing a version of this software that actually works would have taken longer, but at least I'd be enjoying myself. Never forget that your mental health has value.)
Finally, software vendors are doing a terrible job, in general, of pricing their product for the developer market. The biggest problem that I run into is per-user pricing. It gets costly very quickly, either in money or in toil. The monetary cost scales with the number of people that use it, and if you want to avoid the anguish of deciding who is a first class citizen that gets access and who is a second class citizen who has to beg someone with access to do something for them, you have to buy an account for every user. Even for things that one person may use once a year, you take a lot of autonomy and the potential for ownership away if they can't use the tool. But, they charge you like every user is using it for 8 hours a day, 40 hours a week.
Personally, that has been a recurring problem for me. The tools that take me longest to get approved are minor productivity enhancers with per-user fees. Tools that have a per-organization or usage based cost are easy. (Examples: CircleCI, Sentry.) Tools that have a per-user fee are hardest. (Examples: Github, Codecov, Cypress Dashboard, Retool.) I work on a cloud service that had a per-user charge, and it went exactly as I expected -- few people would sign up, and when they did, they shared accounts to keep the cost down. We changed it to a usage-based fee, and a month in the people that actually sign up and start using the service increased dramatically. No longer do customers hit a paywall where their 0 -> some usage costs an amount of money that requires an in-depth approval process with their higher ups. No longer do customers hit a wall where some team members have to be made second-class citizens that can't use the software. People can gradually go from a $0 bill to a $0.01 bill, and invite everyone on their team to contribute, without having to come up with some way to share accounts. It's really great, and everyone that sells per-user licenses should think long and hard about how many people they are flat-out turning away.
Anyway, my point is that developers aren't selfishly collecting money without spending it on software. I'm sure they'd love to, but there are a vast number of complications standing in their way. Remove the complications to collect their money.
Hey there, I'm from Codecov and I just wanted to say, this point is really smart. I had never thought about the challenge of per-user pricing precisely this way.
Codecov was the first per-user service that I bought successfully. I like the feature that lets you pick who to apply your license to. In our case, our office manager manages the billing, but she doesn't need to view coverage reports. So that saves us like $12, which is appreciated :)
But isn't there also the opposite effect if they must pay for usage then they start minimizing their usage, and start actively looking for free tools to do the same?
Also as mentioned by other it takes time to learn to use the tool by using it. But now you would think twice whether use it and pay for using it just to learn it.
Actual proof that not capitalism can work. Free software writers don't need a profit motive. They mainly do it for the love of creation itself. They are an implementation of the ideal un-alienated individual that marx dreamed all humans could hopefully become like.
Celebrate developers refusal to commodities their means of production. I hope it stays firmly in the GNU ecosystem.
While I support the principle, what actually happens is that the companies which make money use your work to generate that money for free. And your desire to build something useful 'for the love of creation' means people who could have got paid to support their families can't because you've undercut them in the market with your zero pricing, using the privilege which allowed you to spend significant time on building something valuable for the hell of it. Then when you try and charge for something this is viewed as somehow immoral, thus pressuring you to provide your work for free and making the multinationals even happier.
> Free software writers don't need a profit motive.
Yes until someone takes their free software and packages it as a cloud service. Then all you hear is "I want to get paid for the software I shared for free."