Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

While this list is certainly educational, remember that most of these "laws" are heuristics based on personal experience.

The discipline of software development is about as rigorous as parapsychology. To learn what we really know about software, I recommend Making Software: What Really Works & Why We Believe It[1], The Leprechauns of Software Engineering[2], and browsing It Will Never Work in Theory[3].

And no matter what languages, testing frameworks, or methodologies you use, always remember:

Every "bug" or defect in software is the result of a mismatch between a person's assumptions, beliefs or mental model of something (a.k.a. "the map"), and the reality of the corresponding situation (a.k.a. "the territory").[4]

If you want your map to reflect the territory accurately, you'll need more than a few "laws" handed down as gospel.

1. https://www.amazon.com/Making-Software-Really-Works-Believe-...

2. https://leanpub.com/leprechauns

3. http://neverworkintheory.org/

4. http://lesswrong.com/lw/2rb/why_learning_programming_is_a_gr...



That's what struck me: the use of the word "laws" to describe what are, at best, "principals", seems particularly inappropriate and pretentious.

I have the image of a self-titled "software engineering consultant" trying to gain prestige (and funding) by using lots of big words (i.e. bullshitting).


Pretty sure the word choice was for effect -- like Murphy's Law.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: