I am descended from a long line of engineers. I remember when growing up that being able to use a new device without reading the directions was considered a badge of honor.
One year, I received an electronic game called Maniac. It was a four player game that consisted of four sub-games. You would play each one in sequence, earning 1 or 2 points each. When I received the game, I tossed the directions into the trash, confident that we could learn how to play. The first three games were figured out, but the fourth was forever a mystery. The most amazing thing was one year, one of my friends actually scored a point on the fourth game! We could never replicate that partial success and it is still a mystery to me as I write this.
That attitude is what makes a good engineer. The desire to systematically determine the proper solution and to rule out false trails. This is a skillset that served me well as a developer.
And yet….
The “Perfect” Coder
Back in the 90s, I had a developer working for me that wrote incredible code. I know this because it just worked. If he was given a task, he would not only knock it out on time, but it wouldn’t be stuck in testing for weeks.
Until one week, there was a problem.
There was a bug and he couldn’t figure out what was wrong. I stopped in to chat to determine what the hold-up was. It only took me a few minutes to determine the basic problem.
He had no idea how to debug code.
His code was always so well designed that errors were rare. If it compiled, it worked. He had never really had to spend time learning how to debug code. He hadn’t learned how to properly limit variables in the code or capture intermediate values that would reveal where things went kaput.
On the Other Hand
A few years later I was on a development team whose members had clearly become programmers because of the career opportunities. They could code, especially when they started with sample code, but they didn’t have any of the talent for development.
Books and the Internet had told them how to optimize code and to vary syntax, but new situations flummoxed them. They couldn’t engineer around a problem. They would pound their head against the wall seeking to solve fairly straight-forward problems.
They weren’t all like this. One person in particular had the engineering knack but not the discipline.
This got me wondering, what the hell are they really teaching these days?
Looking Back
This appears to be more normal than I would. Coding Horror asked Why Can’t Programmers..Program? a few years back. I myself saw how helpful Visual Studio 2008 was and wondered if it was actually taking the programming out of development.
As I think back on my education, debugging was never really taught. Sure, there were classes on languages, proper programming style, and algorithms. Any engineering skills were really brought by the student into the courses or were learn through lots of practice fixing bad code.
What needs teaching is a class on how to fix a problem. There should be a timed test where a student should have to break down an application and determine what module is broken and then fix it. A well designed program would have several independent issues and a few that are dependent upon fixing a previous bug.
If you are just going to be creating websites or writing simple customizations of software, then it is syntax and stealing. If you are going to be creating actual systems, then you need to think like an engineer.
And that can be taught.
Word of Pie 
“And that can be taught.”
Interesting, I would have always been of the opinion that it is an intrinsic attribute of a person. Sure you can “teach” lots of things, but some people just have a knack for things, and I believe the ability to “engineer around a problem” is a personality trait as much as an taught skill. However it is acquired, I agree that there is not enough of it about in the development world!
LikeLike
It can. You are correct, some people pick it up better than others. Just like math. Some people “get it” and others have to work at it. You can teach it, but if someone can’t learn to break a problem down without Herculean effort, then maybe they should consider something else.
I think part of the “knack” is genetic and part of it is environment. My family has it but all of my cousins and I did activities as kids that encouraged that type of thinking, girls included.
It is just like solving a puzzle. Slowly eliminate the potential issues one at a time. A simple methodical approach can win out.
LikeLike
The success of a software product has very little to do with the coding. Coding has mostly to do with maintainability and to some aspect with performance. That is all. It is those aspects that most programmers dislike. Code is good, and users are obnoxious not to understand the maginificent code they wrote. Sales people in any case always sell products too early before they are perfect. Unfortunately, coders would never think that the product is fininshed as there is always something to improve.
The real problems are however a) solution design: Which user problem is being solved and why would the user want to use it? And b) usability: How intuitive is the solution to the probelm? and c) marketing: How is the product being sold?
Most programmers have no clue about solution design and would code basically what they know, which is a compiler/debugger like SDE. Design is for them code-structure and they expect that usability and performance problems are not avoided through design but fixed in testing. They clearly hate debugging the problems they put in and find most user requests as totally irrational. They do not understand when their product is utterly non-intuitive.
The above is clearly a over-generalization, but it applies to at least 90% of people involved in coding. Software development is therefore a collaborative effort of various people and many different skills and the very good programmers are also very good team-players. How good they write code or how many function libraries they know by heart is hardly relevant.
LikeLike
Max, not really the thrust of my post as I was dealing strictly with coding. Specifically the implementation of the design, including the user interface. This was also for all development, not just products. In fact, none of the scenarios in this situation were involved with Design or Products. For several examples, the design was solid.
Still, you raise valid points. You do neglect one important thing that developers MUST focus upon, and that is security. Code must not only maintainable and perform well, but it must be secure. That is something that too many developers fail to think about. Of course, that is a separate post.
LikeLike
Thanks, Lawrence. No disagreement. If you separate design and coding then security is even more a design issue and not a coding subject.
LikeLike
First, there are multiple levels of design. The system design may not involve the developers. Component design will, though the level of detail will vary at that level. Developers should ALWAYS be part of some level of design so they understand what they are building and feel more invested in the project. Where and how depends on the size/scope/culture of the project team. My point being that design should not be separated from the developers but they may not be involved in all of it.
As for security, has to be addressed at all levels. Protecting against SQL injection and other tricks is important and more on the coding level. Of course, it also depends on where you draw the line.
LikeLike
From mistakes we gets to learn lot, this same thing is applied in software development too as developer. By having bugs only one will realize to how to debug it otherwise it will difficult for him to solve the bug as you mentioned in this blog with one of your developer.
LikeLike
I think having programming students break down a problem bit by bit is a good idea. You know it’s broken now go figure out why. And once you know why it’s broken, how do you make it work again? Problem solving is a very important skill for any developer because it helps you look at things in a different light.
LikeLike