3 ms·
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 bein
by jariel 6y ago
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.
- MattGaiser 6y ago> 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.
- jariel 6y ago"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)
- fiddlerwoaroof 6y agoI’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.
- cortesoft 6y ago> But if it makes you >1% more productive, it's worth it. Does it, though? I get paid for my time, not my productivity
- wccrawford 6y agoYou get paid right now for your time. 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.
- oxfeed65261 6y agoAn 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.
- TeMPOraL 6y agoBut 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. Meta-work is pretty profitable for individual.
- dragonwriter 6y ago> 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.