“Programming” is a wierd job category if you work for a place that relies on software as either *the* revenue stream or is a large part of it. The reason is that the job requires the essential skills of how to do the technical end *and* a complete knowledge of the problem you are setting out to solve. So if your company sells paint robots you have to know everything there is to know about the physics of paint so that the robot can be user configured to do not only paint odd shapes but also different mixtures and application densities and a massive boatload of details that may not be readily apparent at first blush. And that’s just about paint itself, much less the knowledge required of how the robotic movements are made; e.g. a typical (smooth DC motor) robot arm movement can be graphed as a trapezoid. It comes up to speed slowly, runs 70% of the intended distance at full speed, and then at the 85% marker starts to slow down and come to a nice reliable stop.
But… how reliable *is* that stop, anyway? Is it really reliable or are we to take the word of the mechanical engineer that that it is? What do you do with your paint mixture in the ramp up/ramp down times? The ideal is to have the mixture spraying for the correct density/spread pattern at full speed, but how does the speed change impact this? Can we change the ramp attack/decay without overshoot? And here’s the $64k question — what do we do about paints etc. yet to be created? Making a system that can’t adapt isn’t worth a damn.
And so on and so forth. None of these issues have a thing to do with the ability to sling code, but rather the ability to solve the problem and then use code (taken as a given skill) to apply the solution. By the time you’re done you know pretty much all there is to know about paint and getting a robotic system (at least this particular model) to apply it.
This is one of the reasons software is still considered Art as opposed to engineering in a classical sense; the problem to solve is rarely limited to the problem presented but must be solved as a model of the problem as an archetype — which ultimately allows adaptation. There is no clear cut rule that governs how well a model must emulate reality. As such much of this stuff is neither clear nor necessarily repeatable, thus it’s Art.
No other job function in the world is like this. If you do accounting then yeah you may have to learn to use a given software system but your main function is still accounting. In the world of software design you have to be an expert at your ostensible function (coding) but then to design say an accounting system, you have to know every blasted thing an accountant knows to make it work. Four years down the road you may have to then learn everything a bricklayer knows, or an aircraft designer so that you can create a flight simulator, and so on. In other words, it’s the only job around where you have to be an expert in coding and also that which you are writing code for.
And good designers don’t exactly fall out of trees. It’s a bit rare.
Anyway the design is the key, and designers aren’t subject to the same whims that plague other jobs where what you do is easily replaceable or is an expense (or both, such as IT.)
Posted by randomengineer 