Slashdot Mirror

← Back to Stories (view on slashdot.org)

Learning About Software Engineering-Where to Start?

Posted by Cliff on from the broaden-your-knowledge dept.

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."

1 of 12 comments (clear)

  1. Admittedly opinionated answer... by rjh · · Score: 5

    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!