When I was a wee lad entering #software development (in the 1980s), most of us came from #EE and #CS backgrounds. And it was a common practice that each of us had small, pet projects—signal processing, image processing, hardware simulators, computer graphics, graph algorithms, networking protocols, programming languages, operating systems, chess engines, approximate polynomial algorithms for NP-complete problems, etc.—that we used to hone our theoretical and practical skills. These were toy problems, for sure; but they had heft, nonetheless. And we didn't just hack up the code; we studied the underlying theories, before we implemented these toy projects. And we didn't clone existing ones.
This was what I was referring to, when I posted earlier about "daily practice routine" for #programmers. I've tried to inculcate this good, life-long habit in my younger colleagues, without success.
These days, most software practitioners see themselves as mere coders, not programmers, and they feel no need to improve themselves, since they've already mastered JavaScript or Python syntax. This attitude is detrimental to the longevity of their careers.
These kids are swamped with having to maintain millions of lines of buggy code that their predecessors had cobbled together off StackOverview. There is no requirements, no specifications, no design, and no one person who understands the entire system.
Furthermore, their non-technical managers are always pounding them to keep raising their "commits", which is now the key metric used in promotion and pay rise.
As such, in just a couple of months of starting employment, eager youngsters turn into jaded code-pasters who experience no fulfilment in programming.
@promovicz I am an Electrical Engineer. Engineers, like doctors and lawyers, are members of a "regulated, learned profession" (that's a loaded term of art, not a lay term). Engineers, by definition, work in an engineering industry. And our licensure require us to act like professionals, not mere errand boys. So, you and I are in agreement, there.
Church (𝜆-calculus), Turing (A Machine), Kleene (recursive functions), and others of their ilk in the 1930s were the OG programmers. They were mathematicians. The meaning of that term degraded in the 1980s to mean "mere coders".
Software development is not an engineering discipline, because it isn't "disciplined" (to the full extent of that term) and, as such, can't be "regulated" (assessed, licensed, regulated, and so on). But just because "coders" (this is what people mean today, when they say "programmers") aren't licensed, learned professionals, it doesn't give them the right to act like toddlers, yeah?
@AmenZwa@promovicz This is too much awe for punch card priests for my taste.
I'm neither a coder nor a programmer, but I program for about 30 years. I use a wooden hammer to make the maschine do my biding, and I don't care much on how it should be done.
My code is for me and there is no other standard than mine it must hold up to.
And also with the rising amounts of computers, the more people use them, the worse it gets, naturally.
@promovicz@AmenZwa Well my code was in production, did ok. I taught some people how to program. I know the pain of marketing people tell bs about the software. The problem is not my "duty" or willingness to deliver intelectual code, but the problem are the money givers that want fast bling bling to sell to people. You get what you pay for and most companies pay crap and are very very shitty in QA, cos some "manager" thinks it's too expensive.
@kristallpirat@promovicz Software is art. Absolutely. And I appreciate your perspective about how you define your duty. I do believe the three of us on this discussion thread share a number of key positions.
I consult for defence, intelligence, government, law enforcement, banking, healthcare, and similar industries. In these sectors, we have more than funds to contend with; we have regulations that govern our technical decisions and professional conducts. My post was referring to this relatively narrow field of IT.
It's not just a hobby, I study law, and I try to apply corpus linguistic methods on the "Schrifttum" (all law related docs). That teaches you a trick or two about programming.
What I like about law is that it describes an idea of utopia.
And in utopia people have the time and money to do test driven development if they so chose.
@promovicz@AmenZwa Well you know I struggle with bringing in the cost of living. Does that make me more susceptible to sell out big if I could?
Maybe.
Information is weapon of mass destruction, and I build tools for that, so in the end I am an arms smith and kinda ok with it. We will see where the universum will let me go.
@promovicz@kristallpirat I know a group of programmers who are currently working on a multi-sensor aerial surveillance system. None of them have a background in engineering, electrical, mechanical, or otherwise. They have no qualms about taking on the job of "designing" a multi-sensor, multi-target-tracking system, although they don't know what is involved. The pay is good, they say.
@promovicz@kristallpirat You're on the mark, mate. And that damaging habit isn't confined to startups. Just look at Microsoft's software release process—what with "Patch Tuesday" and the like.
As licensed engineers, we do have the professional responsibility to say, "No!", when bad decisions come down from above. Lawyers and doctors, too.
But this is not the norm in today's software industry. I recall this wasn't the way in the 1980s. Somewhere, somehow, we lost our mooring.
Remember when we used to get once a year minor updates to OSs and once every two years a major update, if we're lucky? Well, we're doing CI/CD, today. Ouch!
Add comment