Learning About Software Engineering-Where to Start?

slick_rick asks: "I'm a junior in the CS program at a very horrible university. I just completed my junior level "algorithms" class where the teacher covered linked lists and binary searches. I would really like to learn something before I graduate that I didn't already know...like how to structure a significant piece of C++ code. I have looked at a few books on software engineering, and poked around the Web a bit, but I was hoping for some guidance from the master coders in the Slashdot community on who to believe."

Comments

Admittedly opinionated answer...

[rjh]

1. YOU DON'T KNOW AS MUCH AS YOU THINK YOU DO.

Nobody does. This is the first and most important rule of software engineering; most badly engineered projects I've seen got that way because people thought they knew more than they did, whether on the engineering, managerial or executive level.

Mark Twain said that what people don't know rarely gets them in trouble--what gets them in trouble is what they know that ain't so.

2. GOOD DESIGN CANNOT BE TAUGHT.

Good design is kind of like skydiving--it can't be taught. You don't really know beans about skydiving until you're headed toward the ground at terminal velocity, fumbling around for the D-ring (or lollipop, or throw chute, or what-have-you for your particular parasail). At that point, it all becomes crystal clear in the way that only being confronted with imminent mortality can make things.

Software design is much the same way. You don't know beans about software design until you're actually designing. See a project through from conception to fruition, and then take a look back on it. If your first experiences with real software design are anything like mine were, you'll be embarassed that your name is on it.

3. GOOD SOFTWARE IS GREAT, BUT BAD SOFTWARE TEACHES YOU MORE.

It's always nice to make software that doesn't suck, but you don't learn very much from doing it right. You learn from screwing up, then assessing your screw-ups and making different choices in the future.

4. THE BEST WAY TO LEARN SOFTWARE DESIGN...

... is by doing it. Find your itch and scratch it. Sit down with a notebook and sketch out how you think it should work, then sit down and code the monster. With luck, your design will suck. Print out your code, compare it against your design, and see where reality fell short of your goals.

Then re-code the monster. Make different choices this time; see how much more (or less) elegant your code appears.

Repeat this process ad infinitum until you get some code that you're moderately proud of. At that point, move on to a different project and start over again.

Before too long, you'll find your design skills improving by leaps and bounds. Remember: your goal here is not to make perfect software, but to learn about software. Don't be afraid to experiment, to fiddle around, to intentionally break your software just to see how it falls apart.

And finally, the most important rule:

5. HAVE FUN!

One more bit...

[trims]

I heartily agree with the preceeding posters' recommendations. They all have very valid points, and I suggest you listen to them.

A couple more on my own:

• As was stated before, being a true Software Engineer is less about coding, and more about project management, interpersonal relationships, human management, and other fuzzy details. For you, I wouldn't worry; the best way to pick up on these skills is by working in the industry, and observing your superiors. Some will be good, some horrible, and a few amazing. I've gotten lucky and have worked with more than my share of amazing.
• What your question really is asking has to do with software design. I agree that this is critically important - a huge amount of what the industry deals with today is shoddy design. Besides doing small projects yourself (as a previous poster suggested), I would look at some other people's code. I suggest the GNU code, in particular. Several packages have been long stable (such as bison), and are really solidly designed. I would look at some of the pre-1.0 Gnome code (it's still floating around) to see some messy stuff (I like Gnome, but hey, it was really early code). Look at how they put the stuff together, and try to improve it (not functionality-wise, but style-wise). Learn by doing.
• My final recommendation are several books I've found really helpful:
  • Structure and Interpretation of Computer Programs (Abelson and Sussman) - this is the intro CS book at MIT. While it concentrates alot on programming methodology (and uses Scheme), it's really a great refresher on stuff.
  • Abstraction and Specification in Program Development (Liskov and Guttag) - this is the core Software Engineering book at MIT. It's great - covers all the random things you should be thinking of when starting a project. It uses CLU as a language, but the concepts translate directly to other languages. Unfortunately, it's out of print, but you can still pick up copies all around. The replacement for it (Program Development in Java: Abstraction, Specification, and Object-Oriented Design (liskov)) won't be out for another couple of months.
  • Finally, read Introduction to Algorithms (cormen, leiserson, rivest) - this is both a great book on all sorts of algorithmic methods, but a good software design book as well. It's used as the core CS algorithms book at a large number of colleges (like, maybe in 40% of all CS people I know used it in college).

The books above can be found at the MITPress, including how to get out-of-print stuff.

Handouts and other stuff for classes at MIT that used to above books (6.001, 6.170, and 6.046J) can be found from the MIT Course Catalog here - you might explore a couple of the other 6.0xx series (ie, look at the web pages associated with them) as they have useful stuff there too.

Best of luck!

-Erik (an MIT dude, if you missed that...)