Skip to main content

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devoid of the real world situations of what happens when a given algorithm is integrated into a larger project for performing a needed function or service.

That's what they learn (or don't) when they become engineers in the field. Here, the beautiful recursive solutions written into algorithms at University, when stuck inside a real system with input memory limitations...all of a sudden reveals the need for tail call optimization or similarly reveal very pesky to hunt down memory leaks due to improperly closed data base connections or method code that is not properly handled for catastrophic interruptions (in college development the assumption is always made that the computer running your code will not crash while your code is being executed...this is an invalid assumption in the field...where not only must that assumption be made, but it must modulate the code such that it can heal or be robust in the face of such events from the perspective of execution [continue or restart the act interrupted] and from data [recover necessary data to resume] and to reporting [tell some system process that the failure happened so that it can be troubleshooted].

The coding world of engineers is one that emerges over *experience* time building code on live distributed systems and being the victim of these types of unforeseen events despite the apparent perfection of the programmers code.

That said,

The complexities that attend different languages interacting to create complex systems make the problems of engineering balloon. So my experience would say a better approach is to gain  a high level understanding of the types of code. The classes of languages that exist to solve certain problems in the field and why they emerged and a little bit about how those types of code interact on *live* distributed systems.

Once this 10,000 foot view is had, then steeping into the minutia of coding in a particular language will make more sense as the language will now be seen not as the end to the means but as a tool in the process of *engineering* a system that performs a desired system or function.

Tangentially, this difference between University and field coding points to a problem with the engineer hiring practices of most organizations. In a very real sense software engineering is like carpentry or housing construction as well as being a mathematical and technical pursuit. To gauge the ability of a carpenter, those looking to hire one do not ask the carpenter what tools he uses.

He's not asked as to his favorite choice of table saw, or what type of levels he applies, he's not questioned as to the formulations of concrete he uses or of the type of drills and other tools of construction he uses. Instead, the question is simply "show me something you've built".

Engineering is precisely the same way, the quality of code that solves a problem that consists of multiple interacting elements is revealed by looking at the end results. A working application, game or app, a well designed UI...these are the proofs of ability as an engineer that should be placed above in my view the minutia of algorithmic function (all of which at this date are easily harnessed in seconds by consulting google or ...stack overflow!) so though it is important to learn how to do practical engineering for the field work itself...often to get into the job one must bone up on the relatively irrelevant minutia of algorithms and structures that are easily referenced during field work.

The same is true regarding the actual API's and languages used, good engineers can build just as great code with Python as they can with Java if they have time to consume the languages role in the requested design and apply it. In the same way that a good carpenter will be able to construct a beautiful home with a DeWalt drill as he can using a Craftsman. ;) Ironically, those that learn to code outside of the University setting are more likely to be aware of the dynamics involved in live environments as they tend to be learning in those environments...but for hiring purposes the minutia of college learning are what tends to be probed. Adept use of available tools (engineering) is filtered out at the interview process thus missing the opportunity of hiring brilliant engineers.

The hiring practices need to start reflecting this difference between engineers and programmers and those learning to code (either inside or outside an academic setting) need to be aware of the issues to ensure optimal success.



Anonymous said…
"Ironically, those that learn to code outside of the University setting are more likely to be aware of the dynamics involved in live environments as they tend to be learning in those environments"

I'm not sure I entirely agree on this. Most people I know who did CompSci at university, self taught themselves to program when they were at high school, and then the university experience taught them focus on top of that.

From my experience, I was self taught in Basic, C, Pascal and x86 assembler from ages 11-18, then I did Software Engineering at University once I had already written loads of software, where I had massive experience in working directly with hardware limitations.

University then took that rawness and molded me into being able to design software in an OO way, taught me how to document it and test it, as well as loads of important concepts such as how memory management, file systems and multi-threaded systems work.

When I got a development job after university, I had massive advantages over the two guys who got hired at the same time who didn't have comp-sci degrees.
Anonymous said…
This matches my experience. I have seen many people who come into engineering with little practical experience, all theory, and don't know how to apply it in the real world.

However people who have the real-world experience first, then go onto do a degree (I include myself in that category) are able to go to University and as the theory is learned say to themselves 'yes, I can see how I would use that' or even 'no, that's good in theory but won't work in practice'. Whereas others without that experience don't have the framework on which they can select what is appropriate or not, they have no choice but to accept everything.
TonyG said…
I find similar outlooks often - companies looking to fill high-end architectural type positions where that 10,000-foot view is the most important skill, but they stumble over candidates not knowing the specific language they work with (despite the fact that the candidate currently works with 4 different languages and has forgotten three times as many)

I think a lot of companies are short-sighted in this and are likely to miss out on really good people this way. I wonder what it will take for that mindset to change?
Unknown said…
Programming is combination of intelligent and creative work. Programmers can do anything with code. The entire Programming tutorials that you mention here on this blog are awesome. Beginners Heap also provides latest tutorials of Programming from beginning to advance level.
Be with us to learn programming in new and creative way.
Unknown said…
Engineering is fascinating but not easy. I dated an engineer they make alot. But a combination of an engineer who is also highly intelligent in other subjects is like a millionaire. The person i dated was both a engineer and programmer
Rose said…
article was impressive
Michael said…


Popular posts from this blog

the attributes of web 3.0...

As the US economy continues to suffer the doldrums of stagnant investment in many industries, belt tightening budgets in many of the largest cities and continuous rounds of lay offs at some of the oldest of corporations, it is little comfort to those suffering through economic problems that what is happening now, has happened before. True, the severity of the downturn might have been different but the common factors of people and businesses being forced to do more with less is the theme of the times. Like environmental shocks to an ecosystem, stresses to the economic system lead to people hunkering down to last the storm, but it is instructive to realize that during the storm, all that idle time in the shelter affords people the ability to solve previous or existing problems. Likewise, economic downturns enable enterprising individuals and corporations the ability to make bold decisions with regard to marketing , sales or product focus that can lead to incredible gains as the economic

The Rental to Mortage Flip

In this extraordinarily difficult time for our planet and country the winds of change that blow for the near future are as potentially revolutionary as they are unpredictable. In my last post on some of the consequences that have fallen as a result of sudden quarantine induced shift of many knowledge workers to working from home, I explained how the necessity of dedicated work from home practices by many companies will reveal two things, first, companies will realize that they get a lot more work out of their workers. I stated this based on much earlier analysis that I conducted as part of my invention of the action oriented workflow paradigm nearly 20 years ago. Second, the office will be seen for  the excessive cost center that it is, it will see continued shifting to open plan and generalized usage with the end of cubicle farms and the available space will be drastically reduced as rental of floors in down town city centers is absurdly expensive. Offices will remain for executive

Deconstructing Landmark Forum

Deconstructing Landmark Forum: Prologue: Recently I was introduced to the Landmark Education organization by a girlfriend, she was effusive about the many lessons she learned and the "breakthroughs" she had while taking their "forum" and other self help and improvement seminar programs. I was immediately credulous, as a student of science I often find myself playing the advocate of reason when discussion emerges over any particular topic. Often the subjects that provide the most fuel for application of this reason based approach to information analysis are seemingly difficult to quantify without descending into machine gun fire ejaculation of "ideas" with little but anecdotal support behind them. The books of experience that people in various areas serve as the guide for their views a priori of new evidence, this bias against the future by correlation with the past often serves to hold people back from changing their views to suit new observations