Of engineers and code monkeys
This is a post that has been delayed for months while I mustered up the energy/time to write it.
When I started my career as a software engineer in the mid-90's, I was indoctrinated (by the times) to learn about engineering (not just software even though my degree is in CS) and learn how to think about a problem, identify a possible path to a solution, think that through and, only then, consider anything close to coding/implementing a solution. And then test the heck out of it before thinking of a release - primarily because I was made very aware that any bugs that showed up in the field had enormous financial consequences to the company (think $1 million/day penalties). One never wanted to be on the infamous hit-list of major bug producers - trust me. So, much thought, consideration and vetting was done prior to any software/hardware release mostly in a waterfall-ish model. These are the people I grew up calling and identifying as "engineers" and up until a few years ago, I thought that most software engineers "grew up" in some similar work environments/circumstances.
Well, I stand in the "delusional" category at this time with regards to my understanding of what "engineers" (particularly software) do and identify as.
Over the last decade or so, there has been an alarming (to me) trend in the industry towards replacing "engineers" with what is generally known as "code monkeys" under the loud, drumbeats of "coding is great, everyone should/can code".
So, what is a "code monkey"? Urban dictionary has several definitions, none of which, IMO, really convey what I mean by a "code monkey".
To me, a "code monkey" is someone, who may or may not have college degrees in EE/CS or some other engineering discipline and is solely motivated by producing reams and reams of code in their language of choice without serious, dedicated thought about the problem at hand, root cause analysis, design or testing. S/he just wants to write some "code" - in the most thoughtless, error-prone, nightmarishly-insecure, unmaintainable fashion with the express purpose of proving that they can produce voluminous amounts of "code" which may or may not actually solve a problem. For a market that will pay money for it and use it and expect it to function reasonably well.
Perhaps, I am being harsh.
But, I have run into a number of people in this category who regale me with how many LOC they could write in the shortest amount of time. And that they were great engineers because they could do that. Any questions that I might have regarding, well, things like debugging where they would stumble with their answers (or outright lie), led to the assumption that I was "old school" and "out-of-date" and whatever I was asking was irrelevant to what their main goal was (producing reams of code). And work for a startup with "pedigree", make a "killing" and "retire". Or worse, start another similar endeavor. Which, frankly, boggled my mind.
These are the people that I'm relying on to build the next-big-thing in ML and Health apps and mission-critical systems? And fix security issues in other people's code? And,
So, I am, currently, pondering what I can do to try to address this big hurdle that I see - the principle source of which is the failure of universities and schools to teach/train young, brilliant minds to think critically and holistically. And for publicly traded companies to fail to instill basic training to indoctrinate good engineering practices, thought and decision-making in their new hires. Seems to me most companies have new hire on-boarding which is pretty much a marketing fluff show and games with some current process stuff thrown in. Oh yeah, and a "hackathon" to prove how technically savvy and cool a company is - really?
I never thought I got an exemplary education when I was going through school/college - needless to say, I stand woefully corrected and wondering what happened in the last couple of decades to trigger such a great deviation in the mindset and training of school/college graduates.
Or, maybe, I *am* totally out-of-it and my view of engineers vs code monkeys is something no one else cares about or wants to address. That makes me sad.
And, no, I don't think "engineers" can be replaced by robots. I definitely think "code monkeys" can.
<< Home