I've just started working on a side project that teaches users to build software. The pain point I'm attempting to build a solution for is the programming isn't the same thing as developing software and that there is a huge gap between the two.<p>With that said, I'd like to compile a comprehensible list of things that ever good engineer should know. Here is what I have so far:<p>+ The ability to read code is possibly more important that the ability to write code.<p>+ Version control is a requirement, not an option.<p>+ Same goes for testing.<p>+ Writing good documentation is important.<p>+ Open source projects are a great way to learn and build a resume.<p>These are obviously very basic, but I want to extend the list. What is something you think every engineer should know?
The IEEE would say that everything a software <i>ENGINEER</i> should know is in their SWEBOK guide here <a href="http://www.computer.org/portal/web/swebok/htmlformat" rel="nofollow">http://www.computer.org/portal/web/swebok/htmlformat</a><p>If the date 2004 worries you, then download a draft of version 3 of SWEBOK here <a href="http://computer.centraldesktop.com/swebokv3review/" rel="nofollow">http://computer.centraldesktop.com/swebokv3review/</a> and click on SWEBOKV3_Ballot_public.pdf on the left sidebar of the page.<p>Actually, if you want to put together a plan for self study, then work through SWEBOK and Google for papers on the various sub topics covered. One thing about software engineering is that just about all research is published openly on the web particulary in CiteSeerX.
If I were limited to the one most important thing, it would be "How to handle user credentials and data securely."<p>Your app can fuck up a LOT of things, and maybe you'll lose users, or maybe you'll lose marketshare... but the one thing you shouldn't lose is user data.
+ Top down and Bottom up: In other words, work out "What is wanted" and "What is possible".<p>+ Over 20 Quality control innovations exist, use at least 1/2 of them.
You can formulate a list of best practices and advice, but I'm afraid this is the kind of situation where experience is the best school. It's hard to talk about solutions to pain points when the person hasn't experienced them personally. Consider this on your project.