Engineering Discipline in Software Development
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.
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?
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.