I think a big part of the problem can be attributed to tool makers and the lack of true innovation in that arena. As a developer tool maker (HiveMind: crudzilla.com) I am almost always disappointed when I come across a "new" development tool and find that it is the same tired code editor tricks (key bindings, syntax highlighting, code completion, multi-pane editing) with some "flavor of the day" gimmick (git) thrown in. IDEs have been around for more than 20 yrs and the most popular IDEs have not advanced the state of software development much at all.
Compare IDEs with chip fabrication as an easy to compare example. Improvements and advances in chips can be directly tied to advances in fabrication, the same can't be said for software because there is almost no innovation happening in those products despite appearances.
Even worse plenty of jobs won't let you use the tools we do have. Right now I have to work on a Java project that only exists inside a Rube Goldberg of virtual machines and old versions of eclipse. Scrolling inside the vm is dog slow and it crashes multiple times a day. Any attempts to improve the development environment are rebuffed as not providing business value so development will continue to be slow meaning less leeway will be given for improvements in the future.
Try presenting improvements as adding easy to understand business value. Start with something easily quantifiable that you can quickly improve on. Then you can say 'while this change that will take about X hours, it will end up saving the company Y hours per developer per month'.
This would be harder to do if your company directly passes on your hours to a customer, so they don't care about making you more efficient. In this case, find something that would increase your billable hours (eg: starting/rebooting the environment isn't billable, so shaving minutes means more billable time).
I did this to get SSDs in all the dev machines where I work, as we spent ~30 minutes a day compiling, SSDs cut that time in half or more, thus netting the company 15 minutes more productivity a day per dev. I presented this to management as an investment that would pay for itself in under a month (any reasonable business should leap at something like that).
> Try presenting improvements as adding easy to understand business value. Start with something easily quantifiable that you can quickly improve on. Then you can say 'while this change that will take about X hours, it will end up saving the company Y hours per developer per month'.
This usually means spending your own time creating those improvements and typically results in an ungrateful (or even hostile) business. Companies that can't do process improvement without "heroic" efforts from individuals are too far gone to try and save.
I'd love to see some advances in IDEs, but the author is saying pretty clearly that the bulk of the time taken was in high-level decision making, not in struggling to get his ideas into the computer.
> "In a sense, programming is all about what your program should do in the first place."
Yup. I’ve been working on a project off and on for a few years now, where if I had known exactly what I was building in the first place, then it would have taken me just a few weeks. But writing it (and rewriting it) was the only way to actually arrive at that knowledge.
That statement in a way makes my point. Good tooling should help the creator offload a lot of the "thinking about your program", rather it should help you focus on what you want to do.
Also the long time taken in high-level decision making is strongly tied to the difficulty of getting even a trivial piece of software working, even if it isn't always apparent. For instance if the output of the high-level decision making was to create a spreadsheet or PowerPoint presentation, I am sure it wouldn't take anywhere as long.
I have a few long rants on this topic that I'll be putting on the Crudzilla blog (blog.crudzilla.com), stay tuned :)
Yes, good tooling can shave minutes or hours off here and there, maybe pick out a few bugs but it won't save you from spending months or years writing an ill-conceived product.
Compare IDEs with chip fabrication as an easy to compare example. Improvements and advances in chips can be directly tied to advances in fabrication, the same can't be said for software because there is almost no innovation happening in those products despite appearances.