Skip to main content

How To Teach Software Development: Why Good Developers Should Care - Part One

How To Teach Software Development
  1. Introduction
  2. Developers
    Quality Control
  3. Businesses
  4. Students
  5. Schools

Doctors and lawyers in the United States have the American Medical Association and the American Bar Association, respectively, and surely have analog organizations in other countries. As representatives of their professions, they work collectively with their colleagues at a reasonable and useful goal: quality control. It is in the interest of doctors that their med students are not idiots. It is in the interest of lawyers that their opponents are not (more) unethical. There are other, perhaps less admirable uses of these controls (too many doctors would lower all their salaries).

There is no such quality control in our industry. We have individuals at the lowest end of the ability spectrum and at the highest peaks of skill, and, we have the teaches of many years of expensive higher educations on some of our shoulders and only the passion of self-teaching for others. Neither dimension seems an accurate predictor of the other, and this should raise an automatic red flag. What is our education doing for us, if it doesn't let anyone trust your ability without first hand experience, evidence, and other proof you could give them as easily without that education?

I'll own up to my fair share of complaining about the problem in exchange for anyone to agree with me to do something about it. This isn't just an annoying situation that crops up in forums from time to time or can explain why a silly "newbie" asked a silly question. No, this is something costing the economy billions (trillions?), making all of our jobs more difficult, and actually killing people in the rarest situations. We aren't just being elitist snobs when we complain about someone taking a route seemingly inadequate compared to what we think we can do. Further, it shouldn't be considered bad to tell them so. If any of us have any difficulty being told we could improve, we don't have the dignity in our job that it deserves.

Of course, this might seem pointless. Do you think I'm just venting? If so, you may either believe there isn't anything we can do to improve the situation or that there isn't any point in improving it. Either way, my aim is to convince you.

Next: How To Teach Software Development: Developer Motivation
  1. Introduction
  2. Developers
    Quality Control
  3. Businesses
  4. Students
  5. Schools


Sparks said…
There is no such quality control in our industry.

Except for the IEEE CSDA and CSDP programs and the Chartered Engineer (C.Eng) accreditation and the various vendor-specific certifications (though I'll grant you, some of those are out-and-out stupid), and of course the usual internationally accredited computer engineering and computer science university degree courses.

Nonetheless, yes, a program which promotes CPD such as the C.Eng program, would be a good thing. That's why they already exist.
Calvin Spealman said…
I don't pretend organizations don't exist. I'm a card holder myself in some, but that isn't what I said. I said "there is no such quality control" not no such organization. We don't enforce a quality of the members of our industry or the education they get.

Look at a resume from anyone who took an 18 month "become an extreme video game developer!!!!" program and you'll see what I mean.

It would be great if any of these existing groups were more active and direct in this area, but overall we need to take it into our own hands to influence the directions we all need to benefit from.

Still, I'll take your correction into edits. Thank you!
Sparks said…
But we can't set minimum standards for anyone who wants to get into the industry like that. Nobody can - take your examples. The AMA can't stop homeopathy or chiropractors or vaccine critics. They can say that they're daft, or not as useful as claimed, or outright vindictive liars, but they don't have the legal power to stop them unless those people try to practise medicine in a hospital or similar setting, and even there, the level of quality control is minimal from the AMA and mostly is imposed by the hospital itself looking at references and qualifications.

Similarly, the Bar Association can stop a lawyer from practising law in court; but can't do anything about one giving legal advice outside of court or running a practise or acting as a paralegal. Again, minimal quality control, only one specific arena is controlled, and caveat emptor rules the day.

For our industry, and for the wider engineering industry, the same is true. We do have proper, recognised training and accreditation programs, and there are regulations in some countries as to who can use terms like "engineer", but for the main part the onus falls on the company doing the hiring to hire qualified and accredited professionals instead of someone who speed-read a Sam's book and skipped the exercises. And, should they decide to cut corners and hire someone like that to do the software that controls your anti-lock braking system, then they're liable for that negligence.

So maybe what we need to do is start sueing more companies who deliver broken software because of bad hires...
Calvin Spealman said…
I agree.

I'm not advocating anything as enforced as what the AMA or the ABA does, nor saying they have perfect quality control levels. I am saying they are good things to look at when discussing improving the quality of one's own industry. This is something to work towards and all examples are useful, even if they don't apply directly, because we take care to know what to take from them and what to leave.

I didn't originally intend this writing to stretch out like it seems to be doing, so go ahead and read the next post, because I think I'll clarify some of that. You're giving me a lot to think about with how I've paced this, because you're responding to things before I get to the same points.
Anonymous said…
One challenge is that almost any "big" solution -- such as a new organisation, certification or improvement to education across the board -- will be met not merely with skepticism but active resistance. The Python, and indeed IT community, isn't exactly thrilled by anything which is deemed 'orthodox', or attempting to exert power. For whatever reason, respect and credit (by developers, as opposed to by non-developer employers anyway) is given to people who have put their money where their mouth is, and not otherwise. I don't know if you can change culture like that. I think the challenge is to work with that culture -- to harness the exactitude demanded by the community of those who make code or opinions public.

The communities of practise are also very isolated, generally. There is not as much cross-pollenation between, say, open-source, systems development, scientific programming, web programming, applications programming etc as there (IMO) should be.

The major exception to this is conferences. If I were to come up with 'the answer', it would be to run a body to publish statistics on who is publishing the best open-source code, how much, who is presenting at what conferences, validating/reviewing conference presentations etc. However I think that anyone who really is 'in' the community would be best-served by going to conferences and being a part of everything. Making contacts and getting involved with things is the best way as an individual to make opportunities for yourself, and I'd suggest that any employers get involved in supporting this kind of grassroots effort also.

It doesn't take a lot of money to support conference activities and local user groups, and it would greatly assist with recruitment too.

I think. :)
Unknown said…
Computers are now invariably used in every area of business. It is being seen as a symbol of pride and if activities are automated it will save the much needed time and energy. Your article highlighted the importance of developing Software for minimizing Users intervention. We also understood the various issues associated with software development like portability, reliability, response time etc.

Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this.

CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…

Announcing Feet, a Python Runner

I've been working on a problem that's bugged me for about as long as I've used Python and I want to announce my stab at a solution, finally!

I've been working on the problem of "How do i get this little thing I made to my friend so they can try it out?" Python is great. Python is especially a great language to get started in, when you
don't know a lot about software development, and probably don't even know a lot about computers in general.

Yes, Python has a lot of options for tackling some of these distribution problems for games and apps. Py2EXE was an early option, PyInstaller is very popular now, and PyOxide is an interesting recent entry. These can be great options, but they didn't fit the kind of use case and experience that made sense to me. I'd never really been about to put my finger on it, until earlier this year:

Python needs LÖVE.

LÖVE, also known as "Love 2D", is a game engine that makes it super easy to build small Lua…

Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck …