Your favorite snowman and mine, Dr. Drang, has responded to
Brent Simmons’ observation that software engineers don’t really have a code of
ethics. Certainly not like traditional professional engineers from
old and boring tangible disciplines like civil engineering.
In his post, Dr. Drang makes an observation:
Not that long ago, Daniel [Jalkut] couldn’t be a licensed engineer, because there was no licensure procedure for software engineers, but that changed a couple of years ago. Now there’s a licensing exam for software engineering, although I don’t know how many states currently accept it.
…which he follows with a question:
(I am, by the way, curious what programmers think of the topics covered by the exam.)
programmer software engineer, and I’m happy to weigh in. But first,
When I landed my first job out of college, I was writing software that ran bingo games that masqueraded as slot machines. When I arrived, I immediately realized that despite graduating from a top-10 public undergraduate engineering school, that I had no clue how to write software. We were using crazy things like “source control” and "issue tracking software" that I had never heard of before.
I had to learn quickly. I had to take all the theory that I learned in school and turn it into practical knowledge.
Fast forward a couple years and I’m working for a defense contractor. The firm was, at the time, CMMI Level 3. That means, in short, that we were pretty good at writing software reliably. Our estimates were nearly always on the mark, and our releases were nearly always bug-free.
Here again, I had to learn quickly. I had to learn how to be a good participant in code reviews — both as a presenter and as a contributor. I had to learn what a quality assurance department was, and how they are friends, not foes. I had to learn that, in that environment, waterfall is your friend.
With this knowledge in mind, that brings me back around to Dr. Drang’s question: what do software engineers think of the topics covered by the exam?
I think they make perfect sense, and I like them.
The topics were clearly written from the perspective of someone who takes software engineering seriously. Not the fire-from-the-hip startup world, where failure is an option. Instead, this was clearly written to encourage real, true, software engineering. Development that is predictable and reliable. This is abundantly obvious in the first 10 lines of the topics list:
I. B. Requirements elicitation
I. C. Requirements specification
I. D. Requirements analysis
I. E. Requirements verification
I. F. Requirements management
Perhaps I’m allowing my perspective to be skewed by a career mostly in consulting, but these topics being part of a software engineering exam makes me smile.
The catch about software engineering — about development in general — is that to be a great developer is to be great at the un-sexy stuff. To be a great software engineer is to be great at the entire process of writing software. It begins with defining the problem, and flows all the way through ensuring changes to a deployed system do not break the system:
VI. C. Configuration status accounting
VI. D. Release management and delivery
In this environment where the new and exciting are fetishized so heavily, the reality is that writing code that’s “boring” is actually a good indicator that you’ve done your job well. Having a sign like this, while funny, means we’re probably not doing our jobs right.
Discovered this sign at the W3C headquarters... pic.twitter.com/M9XJ2nW6rW— James Ward (@_JamesWard) February 11, 2015