The unteachable parts of software engineering
Having the responsibility to handle the software engineering course at the ENS in spring 2007, I have started to think about the desirable qualities that make the difference between an average developer and a brilliant one. Indeed, I can’t think of a better goal for this course but to actually try to develop such qualities.
What makes a “good” software developer?
It’s an obvious fact that many qualities and skills are required to make a good developer. Smart and Get things done are often cited as the top criterions to decide whether a candidate should be recruited or not.
… a passionate curiosity for software related matter ….
I would complete those two criterions with a third one that I consider to be no less important: a passionate curiosity for software-related matters. Most well-known antipatterns such as programming by permutation, golden hammering, re-inventing the wheel, … are caused by a lack of curiosity. There is far too much to know of the subject of software engineering to trust any particular school diploma (or certification) to be sufficient to produce even a “passable” developer.
Additionally, the software world is fast-paced. Hardware and software get obsolete alike. Development methods evolve. Better tools are released continuously. The sheer (intellectual) complexity of those evolutions is beyond what a single individual can possibly handle. Curiosity when leveraged through teamwork is a strong driver to actually maintain the development practices and tools as close as possible to a state-of-the-art level.
Finally, on the long run, I do not see how it is possible to stay motivated (and therefore productive) if there is no eager interest in mastering this constant flow of evolutions.
How to train such a developer?
I have listed smart, get things done and passionate curiosity as being the top qualities for a software engineer. But this list is more than troublesome for a teacher: it’s not even clear whether any of those qualities can be actually taught
Concerning the first criterion, i.e. smart, I have simply surrendered all “academic” ambitions. The course schedule is far too short; beside I have the chance of having ENS students who are already very smart (though entrance exams have already filtered out students who were not so smart). Yet, the course can them the opportunity to apply their intelligence to a large variety of fuzzy problems that are inherent to software development.
The second criterion get things done is probably the most actionable element of the three. The French education system (highly selective and highly individualistic) usually produces people that are relatively weak against this criterion, the ENS students being no exception (quite the opposite in fact). I have planned to incorporate a student software project within the course mostly to push student develop a get things done mentality .
As for the first criterion, I haven’t much ambition to actually transmit a passionate curiosity the students. In this respect, my first ambition will be to avoid the issue that usually plagues software engineering courses: an overwhelming boredom. I do not think it is really possible to create curiosity ex-nihilo if people have no interest beforehand. But, assuming that students are at least somehow interested (well, if not, it’s going to be tough for the students and me alike), an “expand your horizons” strategy for the course might give them materials to apply and develop their curiosities.
There are two kinds of students: those who are too weak to be taught anything and those who are so strong that the teacher is totally unnecessary.
Bottom-line: out of three main qualities to make a good developer, the ambitions associated with the software engineering course I am thinking of are pretty weak. Well, considering the importance of the subject, I still believe it’s a worthy attempt (stay tuned, more on later posts … )
Reader Comments (8)
[…] The Unteachable parts of software engineering by Joannes Vermorel […]
January 31, 2007 | Jeremy D. Miller – The Shade
My coworker is very lazy indeed. Never bothers to read, has been copy pasting VBScript for years now. Meanwhile, I have tackled ASP.NET 2.0 and Ajax over the past 8 months. He never even asked how it works. I have like 50 books at home, he has none, only a VBScript pocket reference. Can you believe he has been there for years, and I am a student (graduating next month)?
February 2, 2007 | Mike
I would add being able to switch levels in their thought processes rapidly. When discussing a problem in the program with a good developer, we can move around from the top level to the detail level very quickly. One of the worst experiences I had training someone at work started with me writing code the started out something like #define false 0 #define true -1 The newbie couldn’t get past true is -1 even after I explained that it was a quick way to set all the bits. Every time we came across true he had to verbally replace it with -1.
April 19, 2007 | John Davies
I don’t think ‘get things done’ is the key trait of a good software developer. This attitude to quickly leads to somebody who just hacks things together because they believe that ‘getting things done’ is the same a good software. Eventually they make a pile of spaghetti code, quit and leave somebody else to clean up.
August 22, 2008 | Ben
Ben, I agree that quality is of an utmost importance; and that’s why you need ‘smart’ people who won’t produce hellish pieces of code. Yet, in my experience, one frequent issue with ‘smart’ people is having them thinking forever about complex problems and never ever getting close to a working solution. Such people are more likely to be great researchers than great developers. In software, there are many situations where the ‘best’ solution is brittle at best (think antivirus software). Yet, good developers are able to move forward nonetheless.
August 22, 2008 | joannes
@joannes Completely agree with you. I’m one of the people born able to pick up everything quickly but generally find myself getting stuck just thinking of all the different ways I can do something. No matter that my uni course only expects (and wants) a nice simple piece of work, I always end up making things incredibly difficult. Easy is boring but still.. Smart isn’t needed as much as the other 2 variables. Too smart and building apps isn’t what they’re cut out for. Not without someone else guiding them anyway. And antivirus products just suck by the way. Too easy to fool and too brittle to stand up to a virus. rolls eyes
October 24, 2008 | Chris
@joannes Perhaps it comes down to a definition of ‘smart’. I know very smart people who produce hideous code (for lots of different reasons) and it leads me to think that what you need is discipline and/or pride in what you are creating. In this regard I am definitely with the Pragmatic Programmers, software is a craft and you if you approach it as such you’ll do well.
October 30, 2008 | Ben
I thought the this article was somewhat helpful, iam currently a college student and im obviously taking software engineering and ive been searching topics such as this one, to figure out if i have what it takes. im currently finishing up my associates level and will be continuing onto my BA soon. i think im pretty smart but i wouldnt brag, i have a strong interest in learning new ways to accomplish tasks while taking into account that my programming skills are at Noob level. I love to program but im just hoping that i can become the best at my interest (programming). its quite hard to tell at this moment since like i said im a noob but i know one thing for sure i love to do this. soemtimes i find it hard to grasp concepts while in lecture and find myself spending a substantial amount of time figuring out the logic, while debugging my homework. is this something bad programmers do from the start or is it natural to have problems but understand the problem once it is solved? like for instance, i dont know if it is the way that the teacher explained it or my own personal faults, but im currently taking C++ and it took me a few programs to accually get the concept of Pass by reference, and the only reason why i get whats going on is because i figured out the line by line (step through) process “for debugging” not to mention this was not with the help of the professor. i had a hard time writing this program and i realized that we used the same type of debugging process while we was in our first semester studying QBASIC “by the way i dont understand why they taught us that obsolete language” so i researched if it was possible to do the same debugging technique in Visual C++ and was happy to find it because now with this i can accually see how the program accually is going thru its processes. but in my conclusion, i like your article and the responses you recieved in return to your argument, so in short thx but i think ill get a second opinion :) any one else here has a good suggestion email me at j.blaze51@yahoo.com or IM me :)
November 14, 2008 | NooB