3 ms·

Employers do not value tools because the employees say the cost-benefit is not worth it. The problem is that the employees do the cost-benefit calculations reme

by Veserv 3y ago

Employers do not value tools because the employees say the cost-benefit is not worth it. The problem is that the employees do the cost-benefit calculations remembering their time as a poor student when their time was worthless. When your time is worth $0, a product must be 10x better to be worth paying 10x as much. When your time costs $200,000/yr, a 1% improvement is trivially worth $2,000/yr. People in software do not internalize this because we can build our own tools. We can solve the problem given time unlike say a chemist who can not build a reaction vessel. When we were poor, we built our own tools and we keep that habit even after we have money and our time is valuable. It is absolutely ridiculous; the average janitor spends more on tools than a software developer. Truck drivers, secretarys, artists, mechanics, all spend more on tools even though their time is significantly less costly on average. In every other engineering profession companys literally spend $30,000, $100,000, and more a year keeping their high value workers productive. Only in software do we think that $3,000/yr for Visual Studio, the tool that you literally use the entire time when doing Windows development, or $99 per year to do iOS development are “steep” costs. $99 is like one hour of time; it is ludicrously cheap. $25,000/yr for a 25% productivity improvement is a no-brainer. The problem is that software people think it is obviously wrong, but the business people think it is obviously right. We do not need to struggle with hand trowels, the smart business people want to give us excavators, we just need to stop telling them no.

Mountain_Skies 3y ago
Not sure what it is like for other professions but in software development I've found getting approval for buying tools to be a cumbersome process. The most ridiculous case was a $10 license that took several months to get approved and involved multiple 'C' level executives at a company with about 30k employees. At the same company, I was denied access to a cloud service that the company already had a subscription to because my process would use $0.03 of compute time per month, which we were quite willing to pay. There were no security concerns or anything else, just two mid-level managers trying to extract resources out of each other. Those are extremes but even simple things like getting a $100 plugin to parse a particular data format ends up being a time-wasting process that far exceeds the cost of the plugin, and if drawn out enough, the savings it would have produced over building it ourselves. As a result, building it ourselves tends to end up being the default choice.
- Veserv 3y ago
  That is because the budget for you or your team has a big fat $0 for tooling. It is a shameful and degrading state of affairs. Developer time is so expensive it is insane to spend more than a few minutes thinking about a $100 purchase. Your team should have thousands of dollars of open budget per member per year for tooling or critical purchases. Obviously it needs to be rectified regularly to evaluate if the purchases are actually worthwhile, but needing complex process for trivial expenditures like $1,000 is insane. The funniest thing is that operations, cloud deployment, and data science teams do get serious tooling budget. Even though the fields are relatively adjacent and usually include some degree of software development, the fact that they are less capable of building their own tools means they get orders of magnitude more tooling spend. Everybody knows that developer time is too valuable to spend when we can just throw more machines and tools at the problem. But in actual software development, we just forget that and go right back to wasting valuable developer time by cheaping out on tools. It is amazing. It is about time we get some respect for our time and demand tooling budgets.
Dalewyn 3y ago
>When we were poor, we built our own tools and we keep that habit even after we have money and our time is valuable. This is a lesson in life that most people really only realize once they start getting old and see more and more people around them die. Time is money, and as we get older we (hopefully) have more money but we only lose and lose whatever time we have left. Money is theoretically infinite, time is finite. You can borrow money, but you can't borrow time. At a certain point in life, paying money to save your time (aka use someone else's time) is worth it no matter how expensive it is.
eternityforest 3y ago
I don't even think cost benefit is the driving factor. I think making tools is why a lot of devs maintain their interest. For any given task you'll find 5 commercial solutions that basically make it 1-click, if you're lucky a few FOSS equivalents, and 5000 abandoned github repos that implement one or two specific features in the commercial ones. Devs(In general, not myself) don't want debuggers, they want printf. They might want Linux, but they probably like their own DIY hobby OS more.
thaumasiotes 3y ago
> Employers do not value tools because the employees say the cost-benefit is not worth it. The problem is that the employees do the cost-benefit calculations remembering their time as a poor student when their time was worthless. > People in software do not internalize this because we can build our own tools. I think there's another aspect. Those tools are doing things we can do anyway. Here's a story of something I did recently: I wanted to download a series from viki.com. They have switched from just sending you the video file to sending you an encrypted video file along with the encryption key. This is "more secure". So, there's a process involving detecting your own request for the encryption key so you can replay it and get the response, decrypting the video file, decrypting the audio file, and then muxing them together with the unencrypted subtitle file using ffmpeg. After figuring this all out (which took a significant chunk of time), I could manually run the process in 5 minutes for one video. I wrote a powershell script to automate all the parts of it that weren't finding the URL of the three media streams, detecting the request for the encryption key or echoing the request and getting the key. Those stayed manual. But the script handled downloading, decryption, and assembly and it cut my time per video from 5 minutes to 2 minutes. That's a 60% decrease! But it's also easy to say "hey, 5 minutes was already pretty fast; what do I care about 3 minutes?". The payoff from automation only looks good if you're doing a lot of it. (The automation also made it obviously worthwhile to go nuts on adding metadata to the final video file, where that would have been more annoying in the all-manual process.)
ericd 3y ago
My software hand trowels don't get randomly totally wrecked by some fresh grad UX guru who decided that they needed to rework everything to justify their employment or because they felt they urgently need to chase the latest design fads, because the old ones are so last year. Most tools in those other professions don't have that problem. Once you buy them, they're generally static. But yeah, your point about devs being hilariously stingy and not valuing their time is pretty spot on. I just don't think that's the main reason they don't want to buy commercial tooling.

by Veserv 3y ago

Mountain_Skies 3y ago

Not sure what it is like for other professions but in software development I've found getting approval for buying tools to be a cumbersome process. The most ridiculous case was a $10 license that took several months to get approved and involved multiple 'C' level executives at a company with about 30k employees. At the same company, I was denied access to a cloud service that the company already had a subscription to because my process would use $0.03 of compute time per month, which we were quite willing to pay. There were no security concerns or anything else, just two mid-level managers trying to extract resources out of each other. Those are extremes but even simple things like getting a $100 plugin to parse a particular data format ends up being a time-wasting process that far exceeds the cost of the plugin, and if drawn out enough, the savings it would have produced over building it ourselves. As a result, building it ourselves tends to end up being the default choice.

Veserv 3y ago
That is because the budget for you or your team has a big fat $0 for tooling. It is a shameful and degrading state of affairs. Developer time is so expensive it is insane to spend more than a few minutes thinking about a $100 purchase. Your team should have thousands of dollars of open budget per member per year for tooling or critical purchases. Obviously it needs to be rectified regularly to evaluate if the purchases are actually worthwhile, but needing complex process for trivial expenditures like $1,000 is insane. The funniest thing is that operations, cloud deployment, and data science teams do get serious tooling budget. Even though the fields are relatively adjacent and usually include some degree of software development, the fact that they are less capable of building their own tools means they get orders of magnitude more tooling spend. Everybody knows that developer time is too valuable to spend when we can just throw more machines and tools at the problem. But in actual software development, we just forget that and go right back to wasting valuable developer time by cheaping out on tools. It is amazing. It is about time we get some respect for our time and demand tooling budgets.

Dalewyn 3y ago

>When we were poor, we built our own tools and we keep that habit even after we have money and our time is valuable. This is a lesson in life that most people really only realize once they start getting old and see more and more people around them die. Time is money, and as we get older we (hopefully) have more money but we only lose and lose whatever time we have left. Money is theoretically infinite, time is finite. You can borrow money, but you can't borrow time. At a certain point in life, paying money to save your time (aka use someone else's time) is worth it no matter how expensive it is.

eternityforest 3y ago

I don't even think cost benefit is the driving factor. I think making tools is why a lot of devs maintain their interest. For any given task you'll find 5 commercial solutions that basically make it 1-click, if you're lucky a few FOSS equivalents, and 5000 abandoned github repos that implement one or two specific features in the commercial ones. Devs(In general, not myself) don't want debuggers, they want printf. They might want Linux, but they probably like their own DIY hobby OS more.

thaumasiotes 3y ago

> Employers do not value tools because the employees say the cost-benefit is not worth it. The problem is that the employees do the cost-benefit calculations remembering their time as a poor student when their time was worthless. > People in software do not internalize this because we can build our own tools. I think there's another aspect. Those tools are doing things we can do anyway. Here's a story of something I did recently: I wanted to download a series from viki.com. They have switched from just sending you the video file to sending you an encrypted video file along with the encryption key. This is "more secure". So, there's a process involving detecting your own request for the encryption key so you can replay it and get the response, decrypting the video file, decrypting the audio file, and then muxing them together with the unencrypted subtitle file using ffmpeg. After figuring this all out (which took a significant chunk of time), I could manually run the process in 5 minutes for one video. I wrote a powershell script to automate all the parts of it that weren't finding the URL of the three media streams, detecting the request for the encryption key or echoing the request and getting the key. Those stayed manual. But the script handled downloading, decryption, and assembly and it cut my time per video from 5 minutes to 2 minutes. That's a 60% decrease! But it's also easy to say "hey, 5 minutes was already pretty fast; what do I care about 3 minutes?". The payoff from automation only looks good if you're doing a lot of it. (The automation also made it obviously worthwhile to go nuts on adding metadata to the final video file, where that would have been more annoying in the all-manual process.)

ericd 3y ago

My software hand trowels don't get randomly totally wrecked by some fresh grad UX guru who decided that they needed to rework everything to justify their employment or because they felt they urgently need to chase the latest design fads, because the old ones are so last year. Most tools in those other professions don't have that problem. Once you buy them, they're generally static. But yeah, your point about devs being hilariously stingy and not valuing their time is pretty spot on. I just don't think that's the main reason they don't want to buy commercial tooling.