Learning About Software Engineering-Where to Start? 12
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."
Extremely good advice... (Score:1)
TAOCP (Score:2)
Apart from that, I'd say that the only way to learn to program well is - well, d'uh - by programming. Ditch C++; get acquainted with a high-level language environment - Squeak or DrScheme are good - where you can program, test and debug interactively. Start with small stuff - individual classes and functions - and then pick a project or two to put together, something which is useful but which doesn't require a lot of black magic and programming voodoo. Then release its sources on a site like like Sourceforge, so you'll learn from other people who may be more familiar with the subject than you.
So, good luck!
(*) I'm using the term "concrete mathematics" to refer to the field of research that most people call "computer science". Why? Because it's neither really a science, nor really about computers. If you have a better name for it, drop me a line.
SE is a very broad discipline (Score:1)
Re:TAOCP (Score:2)
The Hard Way (Score:2)
For another year, I still wrote lousy code by cut-and-paste. Slowly, I began to recognize the places where I could use objects and abstraction to clean up the code and make maintenance/revision easier. By the time I got to doing my thesis, I was able to make a reasonably well-built program. (It'd have been even better if the STL worked on the machine I was using.)
Reading the key books will certainly help. However, your code also needs to mesh well with your thought patterns, so that you can work with it easily. Therefore, the majority of becoming a good software engineer is sitting down and integrating the theory with your own style and getting used to thinking for a while before you type. By making mistakes and suffering for them, you will eventually develop an instinctual understanding of good style.
Theory (Score:2)
I'm not quite sure what you expected from your university, but if you thought Software Engineering or Computer Science to be about neat C++ structuring or writing a Quake3 engine, then think again. Sure these are all part of it - but just a tiny bit.
In the end, it's all about understanding Information Technology - what it is capable of and how to apply it. A Quake3 engine is not much different from Oracle 8i in that they both use complex datastructures to maximize the efficiency in throwing data around and presenting it as information to the outside world.
The same is true for C++, COBOL and Basic. They are just tools, nothing more. It doesn't matter whether you give a construction engineer a bulldozer or just a simple hammer to take down a house - it is the knowledge he has about the way houses are built and how they are structured that decides how he approaches the problem. Some tools are better in some places though - the bulldozer is probably better for tearing down a house, the hammer is most likely a better choice for putting a nail in the wall.
The same is true for Software Engineering: it's all theory, but once you master it, you'll be able to do anything. So have some patience with your university - or find another one.
Check out Steve McConnell's "Code Complete" (Score:2)
Check out the reviews at Amazon for Code Complete : A Practical Handbook of Software Construction [amazon.com].
Admittedly opinionated answer... (Score:5)
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... (Score:3)
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:
The books above can be found at the MITPress [mitpress.com], 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 [mit.edu] - 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...)
The Impossible... (Score:2)
What you have asked for has yet to be created. There are books that try to explain software engineering and many that explain the mysterious workings of C++ but only experience can teach what you want. Here are a few books that will advance your knowledge of both C++ and software engineering to help you along your way.
Some hints (Score:1)
Apprenticing... (Score:1)
Unfortunatly, as a student there typically aren't that many experience software designers. (They usually don't teach as a primary profession...) Get a part time programming job for a local company if you can, or look for project teams formed in other university departments. (Especially teaching hospitals. They often need software comparable to anything in private industry...)
Learn from experienced people, and gain experience. The best way to learn.