5 ms·
Ask HN: What should every software engineer know?
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.
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:
+ The ability to read code is possibly more important that the ability to write code.
+ Version control is a requirement, not an option.
+ Same goes for testing.
+ Writing good documentation is important.
+ Open source projects are a great way to learn and build a resume.
These are obviously very basic, but I want to extend the list. What is something you think every engineer should know?
- bmelton 13y agoIf I were limited to the one most important thing, it would be "How to handle user credentials and data securely." 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.
- jmau5 13y agoIt's interesting that you mention this, because I hadn't even considered it. This is especially important advice given the insane number of privacy issues going on these days. Thanks!
- bmelton 13y agoNo problem. I might not have even thought about it if not for another recent discussion I'd been having about authentication and permissions. Long and short of it, Github is screwing me over by not letting me get fewer permissions, and I won't release an app that takes more permissions than it needs. It's quite the quandary, really.
- memracom 13y agoRather than focus on only one aspect of security you would be better off to become familiar with everything related to OWASP https://www.owasp.org/index.php/Main_Page https://www.owasp.org/index.php/Main_Page and in particular, you should know how to address their Top 10 Threats.
- gcatalfamo 13y agoRephrase: What should every software engineer know?
- jmau5 13y agoAdvice taken and implemented. :)
- eddyparkinson 13y ago+ Top down and Bottom up: In other words, work out "What is wanted" and "What is possible". + Over 20 Quality control innovations exist, use at least 1/2 of them.
- jmau5 13y agoWhat do you mean by quality control innovations?
- chas 13y agoMost likely things like version control, static analysis, dynamic analysis (e.g. Valgrind), automated testing, and code review. The Joel Test[0] is a good starting place. [0]http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html
- memracom 13y agoActually, Joel has a lot of great blogs, not just the one on the Joel test. Browse through the titles and read any that seem interesting. He has been writing good material for many years. Of course he is not the only great blogger on the topic of software engineering, so whenever you need to google for info on a topic, click on the More... dropdown and select Blogs to find more great bloggers.
- jmau5 13y agoI've read some of Joel's posts in the past and will definitely keep this in mind.
- eddyparkinson 13y agoQuality control innovations: Requirements reviews, Test driven development, Agile. Have a read of Software Inspection by Tom Gilb. The exercises at the back of A Discipline for Software Engineering are also very good (although the main book is not that good). Edit: It is worth understanding "bugs removed per hour". Every quality control "innovation", has a bug removal rate and will improve the end product, or should do. The bug removal rate, is a calculation you can do. ... But I like to learn by doing, so the above exercises helped me understand.
- hcarvalhoalves 13y agoYou 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.
- jmau5 13y agoThis is actually the thing I dislike most about getting into software development and something I want to fix. Initially, it seems like the best approach would be to find a few well-run open source projects that would agree to mentor users in some fashion. The problem would be getting this approach to scale as the number of mentees will always be larger than the number of mentors.
- memracom 13y agoThe IEEE would say that everything a software ENGINEER should know is in their SWEBOK guide here http://www.computer.org/portal/web/swebok/htmlformat http://www.computer.org/portal/web/swebok/htmlformat If the date 2004 worries you, then download a draft of version 3 of SWEBOK here http://computer.centraldesktop.com/swebokv3review/ http://computer.centraldesktop.com/swebokv3review/ and click on SWEBOKV3_Ballot_public.pdf on the left sidebar of the page. 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.
- jmau5 13y agoI'm not familiar with the SWEBOK guide. I'll definitely look into it though, thanks! This looks like it could provide a solid foundation for the project!