Hacker News Reader

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.

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.

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.

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.

>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.

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.

> 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.)

Purify was glorious. As was Saber-C before it.

My employer paid for both. But we sold even more expensive development software ourselves, and bought very expensive workstation and server hardware to run it on, so we were accustomed to the price points.

I like that great software is now open source, and most any kid or adult around the world can run it on a cheap decade-old PC. But I do miss some things about that software development era.

The barriers are things like integration effort, carrying cost (keeping up with updates and the toil to keep the tool going), poor signal / noise ratio and subsequent triage and debugging effort, additional feedback to dev team (valuable!) but often with no additional time to address it (demoralising), driving workflow changes for whole dev team (not just 1 or 2 enthusiasts) is hard, training & learning costs, and finally an inertia effect - the business shipped successful product without $tool in the past (otherwise there would likely be no money to buy it) and this is a trivial proof that $tool is not "essential".

You must be in a line of work absolutely foreign to high level programming. In language ecosystems like Java, C#, JavaScript, and so forth people live and die by tools. You are not hired as an employee for your ability to program, but for your years of mastery on some bloated tool. Just look at any job board.

Jobs posted to HN by start ups are frequently comical in this regard. On one hand they claim to be solving tough problems and hiring only the sharpest people around, but more than half the time the hiring criteria just the same tool insanity as the corporate world. If I can make more doing half the work and dealing with the same stupidity in the corporate world then why would I want to work your start up? Maybe I just like being punished.

Talking bad about some tools often brings upon the same emotional fire as burning holy scripture in public. For many developers if not for certain tools, for example Java Spring or the big JavaScript frameworks, they could not program at all. They simply lack the skills to practice without such tools.

In these cases tools are more than valued. They are as essential to air and food. Its unfortunate, because economically that value is entirely artificial. An employer can easily eliminate these large tools, eliminate half the associated jobs, retrain the rest of the staff to move forward without those tools and pocket the difference without lose of productivity.

Purify was a fantastic tool and I would have cheerfully paid $100K in late-90's dollars. We demoed it and the amount of memory errors it found in our legacy C and nascent C++ code stack was simultaneously depressing and exciting. We bought licenses and went to town. There was a markable product quality improvement as a result, at a time when our sales were exploding. I've never found a memory tool since that was as capable. We were running SGI IRIX boxes at the time.