Ask HN: What should every software engineer know? | Hacker News Reader

Ask HN: What should every software engineer know?

8 pointsjmau516 comments

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?

View on HN

The IEEE would say that everything a software ENGINEER should know is in their SWEBOK guide here 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/ 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.

I'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!

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

It'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!

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

Rather 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 and in particular, you should know how to address their Top 10 Threats.

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

What do you mean by quality control innovations?

Most 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

Actually, 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.

I've read some of Joel's posts in the past and will definitely keep this in mind.

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

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.

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

Rephrase: What should every software engineer know?

Advice taken and implemented. :)

Reply on news.ycombinator.com