Putting the magic in the machine since 1980.

Saturday, April 17, 2010

What We Should Teach IT Students

Yesterday I attended POSSCON where I saw a talk by Andy Lester on "What We Should Teach IT Students". As the use of the word IT in the title reveals, the target audience for the talk was enterprise developers.

For readers new to the field, enterprise developer is just a type of job. The easiest way to define the term is by pointing out that Blue Cross Blue Shield and Bank of America hire "enterprise developers" while Google, Microsoft, and Valve hire "software engineers". That is, enterprise developers write the software that makes the business run smoothly—process insurance claims—while developers write the software that IS the business—the new version of Windows. From an accounting point of view, enterprise developers are often a cost center for the company while developers are a profit center.

Still, the recommendations are largely applicable to all. He recommends students learn:

  1. Source control
  2. Bug tracking
  3. Compiler (paying attention to the error messages)
  4. Make and the philosophy of repeatability
  5. Lint / splint or similar static code analyzers
  6. Serious editing
  7. DRY: Don't Repeat Yourself
  8. Defensive programming
  9. Maintenance: working on other people's code
  10. Manual testing
  11. Automated testing
  12. Efficiency and why it does not matter
  13. Thinking about the: business, project, release, deadline (getting the bigger picture)
  14. Teamwork: work well with others
Our curriculum covers all of these, some more than others, and I am in full agreement with all of them.

Some of these, however, I think must be left mostly to the student. I know that learning to use the editor is super important, but I don't think we need an actual class to teach editing! I really can't see myself standing in front of our students for a whole semester telling them "To compile your code, press F8; to indent your code press Ctrl-A then Crtl-I". They know they can just get the list of shortcuts and memorize the ones they need. Still, I do make a point in my classes to stop and explain how I got System.out.println to appear after just typing sysout. Similarly, learning to use a source control or bug tracking system is just not that hard (compared with, say, implementing a compiler). Overall, the students who have not learned to use their editor, or understand compiler errors, or DRY, are generally the few who really don't care about programming, and their grades show it.

Still, I agree that these are all important skills to have.

Andy also said all students should have read Code Complete, which is the required textbook for my 492 class. He also mentioned The Pragmatic Programmer which is also a personal favorite of mine and on my list of recommended books for 492. Of course, we all know they are good because stackoverflow says they are.


Unknown said...

I have always heard 'Code Complete' was good, but I still wonder how considering its publisher.

I mean Amazon says it has bad code examples in Visual Basic? Isn't that every code example in Visual Basic?

Lots of good books on that stackoverflow list. I've had to build my reputation so I can vote up SICP and/or 'The Little Schemer'.

I agree with you on editors. The students that care will learn one themselves. It's not like the old days though; I can seldom get into debates over the obviously superior vim versus emacs. I encounter students claiming kate and gedit are better.

Everything I've learned of git, lint, DRY, unit testing, and agile development (to name a few) has been on my own time. Then again, I'm just a junior. Maybe 490/492 will change that some?

Andy Lester said...

I have always heard 'Code Complete' was good, but I still wonder how considering its publisher.

After I emphatically recommended Code Complete I specifically said "Don't let the fact that it's from Microsoft Press fool you." It's truly a fantastic book.

My point about learning an editor isn't just "Learn a good editor", and how to compile code. Rather, I meant to get across that students should work learn their editor so that it is a handy tool in your toolbox, not just something you type code into and run builds with.

Jose, I'm glad you liked the talk. I had a great time in Columbia, and it was the first time I'd given a talk on the topic.

jmvidal said...

I enjoyed you talk Andy! It was a concise and entertaining explanation of employers' more pressing concerns.

I think my point was that some of these are not things that need to be taught as much as they are things that need to be done, by the developer.

For example, a true journeyman programmer invests the 1-hour or so it takes to learn to use svn from his IDE and then spends the rest of his 40 year career constantly using source control and thus learning how it fits within his complex deployment/QA scenario.

A BS is only 4 years, while a career in software can last more than 40 years. In that time technology will change dramatically.

I got my BS in CSE 20 years ago. That year CVS had just come out, the Web would be invented 4 years later, Java 5 years later, no one had heard of DRY, or unit testing, or agile acrobatic pair gymnastics, or whatever.

What will be the must-have skillset in 20 years? I don't know, but the journeyman programmer will have it because he is always learning.

So, what we really need to be teaching is the journeyman mindset: never stop learning. I hope we do that. But, then again, that is also something that needs to be done more than it needs to be taught.

Unknown said...

That does sound like a good presentation. I didn't make it out of the dev track room. It is a shame I can't be in two places at once (yet). I hope Andy posts the slides of his talk and links from his blog that I now read ((hint,hint) if Mr Lester is still reading).

I think Andy may have sat in front of me at Yehuda's Rails presentation and mentioned something about Catalyst Framework to me, since I had mentioned to the guy sitting next to me how different Rails felt from the way we did things in Perl in the 90's. So many people; it's easy to get mixed up.

Andy had a workshop that I was REALLY sorry to miss also. It sounded great, but they moved him up against 'maddog'. The first rule of POSSCON for me was: 'maddog > ALL'.

On the bright side, Andy's book is inexpensive enough on Amazon for me to add it to my $20 or less Christmas wishlist from the family!

Obie Fernandez had a great presentation in the dev track about it taking something like 10000 hours of practice to achieve technical mastery in anything and how you need a lifelong commitment to learning and expanding your abilities. He had a slide that showed some of the stuff that he expects his developers to be adept in or become adept in that included things like vim, DRY, agile, svn, and all sorts of other stuff (there was like 30-40 things). I came in pretty much expecting something about rails, so the talk he gave was as unexpected as it was great! I like the way he thinks and am tempted to read his Rails book when 2nd edition comes around.

Andy Lester said...

For example, a true journeyman programmer invests the 1-hour or so it takes to learn to use svn from his IDE and then spends the rest of his 40 year career...

I agree. Are you teaching your students that, Jose? Explicitly, in those words? That if they're not constantly learning new skills, they're going to be left in the dust? I hope all schools do. I hope that part of what's instilled in students is an understanding of just how short-lived their skillsets are.

Jed said...

it was nice to meet you this weekend. And while I did not see Andy's talk, I would say this about what I wish I was taught (in school) that isn't on this list: Test Driven Development. I say this because the majority of the stuff on the list is a technical tool that is subject to change. But TDD (and likewise Behavior Driven Development) is a paradigm shift in development that will make a similar impact to development as OOP did. It fundamentally changes both the design process and the expectations given to the developer himself/herself. Also, for clarity, I see automated testing as reactionary to design rather than driving design (although automated testing could be running the existing Continuous Integration test suite that is created during TDD/BDD). I don't know what you mean by 'manual testing'.

On the editor's thread:
Quite frankly, I think that educational institutions should avoid teaching within the context if IDE's in general. This should be left to some certification for a given language or toolset.My colleagues and I use vim, others on my team use emacs. Coming from a job where I was required to use Eclipse, I absolutely loath it. Instead of IDE's teach how to do more with less using meta-programming, enforcing DRY, YAGNI, and other agile principles, and teach to write in a functional style. i will leave you with one of my favorite tweets of all time.

"IDEs are crutches for the features that are missing in the language" by @olabini

jmvidal said...

Teaching students to be lifelong learners is one of the top goals of every major University. But it is easier said than done.

I love that we now have people like Andy, and Jeff Atwood and Scott Hanselman: professional developers who happen to blog and constantly remind us that it is a process. It really helps to show kids that it is not just me being pigheaded about them writing unit tests for their homework program which only I will ever run.

However, I also have to be careful about how I phrase the half-life situation. Most freshmen believe that learning your second programming language will be just as hard as the first. They think its like learning Chinese after learning Italian. This then leads them to conclude that a career in CS is a waste of money as everything they learned in the first 4 years will be obsolete 4 years later. This is not true, but it is what many conclude.

jmvidal said...

Hey Jed!

The editor recommendation is to learn to use your editor, whichever one you choose, well. It just saves one a lot of time to know that with a keystroke you can do global search-replace, or properly indent all code, etc.

My favorite Tip is macros (C-x ( in emacs). I often get large text files (data for homeworks) that are in just the wrong format and I have to change them to something easier to parse:

C-x (

...do what I need to re-format the first line(s)...

C-x )
C-u 10000 C-x e.