Blog Closed

This blog has moved to Github. This page will not be updated and is not open for comments. Please go to the new site for updated content.
Showing posts with label Engineering. Show all posts
Showing posts with label Engineering. Show all posts

Wednesday, October 28, 2009

CS Education

Let me preface this post by saying that I don't have a CS (Computer Science) degree. I majored Electrical Engineering for my undergrad and Computer Engineering for my masters degree.

Yesterday I read a very interesting series of blog posts about the state of CS education. First up was "Joel of Software" with a post about how lousy CS education is. Next up was "Stochastic Geometry" with a post rebuking Joel. Finally, Ovid had a nice post about his reactions to them.

I can tell that the state of computer engineering education is lousy, and I have heard enough from professors and students to know that the state of computer science education is lousy too. It's hard to really put a finger on what exactly is wrong with the system, however. First, let's distill the good points of what Joel has to say:
  1. Students aren't doing enough team work
  2. Students aren't good at time management
  3. Students don't write large programs
  4. Students don't have to spend much time debugging, stabilizing, securing, or maintaining software in the long term.
These points are all true, and go largely unaddressed by Stochastic Geometry. However, in the flip side, let's look at what the response had to say:
  1. Any particular tool is unimportant compared to learning a class of tools
  2. Learning the theoretical fundamentals is important, because it allows the student to learn specifics more easily.
  3. Teaching one particular methodology is harmful, because there are no standards and no proof that any one methodology is beneficial or even widely used.
Since joining my job, I've had the privilege to participate in a few interviews of new applicants. Most of the jobs we've been looking to fill are entry-level, so many of our applicants were fresh out of school. We had one candidate in particular with a dual major in CS and CE from a school that, I thought, had a decent program. He had a nice resume and a decent GPA, so we were hopeful.

We started with some low-ball sanity questions. First up: "How many bits are in a word?" There are a few good ways to answer this one, and while it may seem esoteric it is profoundly important when talking about embedded systems. Savvy readers will realize that this is sort of a trick question. The term "word" in computers has a number of different meanings depending on context. An acceptable, though naive, answer would have been "16". A better answer would have been something like "it depends on the system. 32-bit computers have a 32-bit word, 64-bit computers have a 64-bit word, etc". A great answer would have included the previous one, and included "though in some programming spheres, 'word' is defined to always mean 16-bit and double-word (32) and quad-word (64) are defined to mean other things, regardless of the size of the machine word". All of these would have been acceptable. His answer: "I don't know."

We were stunned, and tried to give him some help, but he simply didn't know the answer. So we moved to a less-difficult question, to try and coax some information that was buried a little too deep: "How many bits in a byte?". He didn't know that either. Thanks for coming in today, but the interview is now over.

Without fail. Without any exceptions, the best potential applicants I've seen for my place of work, and the best software developers that I've known from other contexts, have significant programming experience outside of school. Sometimes this comes some independent learning and small personal projects. Sometimes this takes the form of Open Source Software contributions. I make no secret of the fact that my participation in Parrot has had one of the biggest beneficial effects on my skill as a coder. I am far more influenced by my work in Parrot then I was by anything I did in school. I'm more influenced by it then I am from my full-time job. It really is an immeasurably wonderful environment to work in, and gives that kind of practical immersion that a university degree really can't provide

One applicant we talked to listed PHP on his resume. I asked, "Where did you learn PHP, in school?". To which he replied, "No, I taught it to myself."

"Why?"

"Just because I was interested in it and wanted to know how it works."

That applicant got the job, and has proven to be very successful at it. It didn't hurt that he knew how many bits were in a byte.

There was a time when people went into computer programming for the money. Back in the heyday of Silicone Valley and the .Com Bubble, there was money to be made hand-over-fist for any programmer who was able to dip into it. Reality has set in now, and this isn't the field to get into if you're only looking for some easy cash. In fact, if you don't stand out from the crowd in some way, you're more likely to be unemployed. I graduated with a lot of other EE and CS majors who settled for jobs in sales or marketing when they couldn't find a tech-related one. I knew one Masters degree recipient who had to work at Target for a while because there were no jobs for him whatsoever.

Every recent college graduate will tell you that almost every single job listing they find requires at least one year of experience. The naive will say "How am I supposed to get the experience in the first place, if I can't get a job that requires prior experience?" In some cases internships can go a long way towards greasing those skids. However, the bigger question is this: If you're fresh out of school and have all the fun facts and theory fresh in your mind, why do you need experience? You need it because school doesn't really prepare you for a job at all: it prepares you to prepare yourself to get a job.

I don't want to scare anybody away, but I do need to make this point: If you aren't good at it, you won't easily find a good job programming or web developing. Coming out of college you will not be any good at it if you don't have any other experience. This is an undisputable fact, a college education simply does not and cannot prepare you for a real job in the real world of computer programming. You're going to have to put in the extra effort yourself. You're going to have to fill in the gaps yourself. You're going to have to learn the important lessons yourself. College made you capable of learning, now the onus is on you to actually learn. Going back for a masters degree is a good idea. Internships are good. Doing little contracts for small local businesses can be good too. Classes and training courses are good, and they happen in all sorts of places at all times of the year. Participating in an open-source software project is, in my estimation, the best.

The last option is my favorite, but so many people shy away from it: "I don't want to spend my free time writing code". To this I have two replies. First, if you don't want to write code, why are you pursuing a career in it? Second, what are you going to say when your future boss hands you a blackberry and tells you that you are on-call 24/7 and are expected to jump anytime the system goes down? Or when your boss tells you that the entire team is expected to put in 10-20 additional hours of overtime per week, every week, until the next release?

So in conclusion, my point is this: a college education, especially in the fields of CS or CE, will teach you the basics and the fundamentals, and put you into a position to learn new things and adapt to new work environments. It will not directly prepare you for a good job as a programmer. What a college education does (and this is extremely important, even if it doesn't sound it) is to prepare you to learn the new things you will need to be a programmer. You have to do the learning yourself. Joel is right to point out that students are coming out of college woefully unprepared for work. He is also right to point out the problem belongs to the students themselves. Stochastic Geometry is right to point out that colleges are doing what they should, and that teaching the fundamentals is very important. The missing link is that the students need to go through the last few preparation steps themselves. Students need to get the extra real-world experiences themselves to complement the fundamentals they've learned in college. Participating in a good open source project will teach you the necessary lessons, will look great on a resume, and will act as that final bit of preparation to get you into the good jobs you want.

Wednesday, May 13, 2009

Software Engineering Licenses

Ovid wrote a very interesting blog piece about the idea of software engineering being subjected to consumer protection laws in Europe. He is seemingly in the minority by supporting this idea. I was writing a comment to agree with him, but as the comment got longer and longer I decided it would be better served as a complete blog post.

In the USA there is a licensing for engineers called "Professional Engineer", or "PE". The idea isn't specific to the USA, but that is the only version that I am familiar with. Getting a PE license requires an apprenticeship under an existing PE and a strenuous and comprehensive exam (actually two exams, one to qualify before the apprenticeship and one afterward). Once you have it you are able to do certain jobs that you legally could not do otherwise. For instance, almost all Civil engineers must have a PE because public infrastructure work almost always requires it. Most Mechanical engineers get it as well, at least that I am aware of. For electrical engineers the number is smaller, typically only people who work on public power or transportion systems get it. I know that when I was in school for EE and looking to pursue PE licensing for myself, it was very difficult for me to find potential mentors to apprentice under, and it was even harder for me to justify the effort considering I wasn't going to be in a field that required it. However, that's not to say that it's impossible to get a PE in EE, and there are plenty of other per-project certification schemes such as Intrinsic Safety that EEs need to follow (I know we spend a lot of effort at work pursuing IS certifications for our products, and it's far more strenuous of process then any regression testing of software that I've ever experienced). In software engineering, which is where I am now, it's almost impossible to get PE even if you needed it (there are basically no PEs in software engineering to apprentice under), and I'm not really aware of any certifications for having software approved as being "safe" in the legal sense.

PE specifies a few things: First, you must demonstrate a level of competency in your work. Second, you are only approved to do licensed work in your area of expertise. A Civil PE cannot do mechanical or electrical work that requires a PE, for instance. Third, there is legal responsibility. Plans and projects need to be approved by a PE before they can be implemented, and the PE is responsible for the outcome. The PE license also specifies who can be licensed: You must have at least a bachelors degree from an accredited institution, you must pass a qualification exam, you must apprentice under a licensed PE, and then you must pass a comprehensive final exam. And the accreditation, as I will tell you, can be quite strenuous. The bozo schools get weeded out by accreditation agencies before they can graduate bozo engineers. If you picked up a degree from John's Basement University, I'm sorry but you don't get to design bridges (at least not ones that people drive on).

There's a difference between consumer software and infrastructure software. If your software can have a negative impact on a person's health or well-being, and it fails, there should be some resource and some place to lay legal responsibility. We don't want Joe Schmoe with a AS in Information Technology writing the software to control your antilock breaks. We don't want a former Mechanical or Electrical engineer who decided to "switch to software" coding the safety fallbacks for a nuclear power plant. We don't want people who aren't properly licensed writing the autopilot software on a plane or the failsafe software on a missle, or the routing software of the electrical grid. We want people who are properly trained, competent, and accountable to be writing all these things. I've seen enough shitty code written by "software engineers" already, people who don't even specialize in it can't be expected to do any better (although some certainly can do it very well indeed).

If a bridge collapses or if a power line lands on a playground, you can be damn sure an engineer somewhere will be held responsible for that. And knowing that their asses are on the line will prompt these people to be more careful, more conservative, and more circumspective before signing off on a shoddy design. Why should it be any different for safety-critical software? Why shouldn't software engineers in safety-critical industries be held accountable for their own bad designs and bad, uninformed decisions? Why wouldn't we as an industry want to cover our own asses like that?

On the flip side, if there is a legal requirement that critical software be approved by a licensed software engineer, suddenly those engineers have more power over deployment: software doesn't get shipped unless it is properly approved, and no amount of business politics will force a deployment before that. Good developers with proper licenses will be able to earn more money for their work too, because they become a legal necessity
. And there will be more job security for these people as companies won't be able to replace good licensed developers with new graduates, and won't be able to outsource all their coding needs to the bottom bidders around the world. It's both amazing and depressing the kinds of people who are allowed to write critical software in this world, and more often the costs of software development right now are treated as overwhelmingly more important then the long term costs in terms of money or public safety. We can see this same principal at work in all sorts of other industries too (Think about the banking industry where the pursuit of short-term gains brought the whole world into recession). Do we want to allow that kind of process creating the software that we all rely on?

I think that requiring software engineers to be licensed in some cases and to hold them accountable for their work will be a good thing overall. Require that important software only gets written by good software writers. Require that decisions about deployment of important software get made by the engineers, not the marketing department. Require that important software not be an exercise in "failure probability", and give people guarantees that things that are supposed to just work do, in fact, just work. It's time that software engineering graduate from a field of amateurs and non-accountable dabblers and become a field of precision, science, and results.