Things Every Programmer Should Know(programmer.97things.oreilly.com)
programmer.97things.oreilly.com
Things Every Programmer Should Know
http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book
13 comments
Hey - go talk to someone about that! I've had similar issues when I was going through a stressful time and I figure it was by brain's weird way of keeping me away and distracted from the stressor. It takes a while sometimes to figure out exactly what it is though. What you said did help though, especially #3, and also getting regular and enough sleep. But tackling the issue at its heart helps more.
A big help for me has been trying to fall in line with the natural circadian rhythm of sleep. Try to get to bed early, and make sure your room is as dark as possible. Turn off your computer and/or TV some time before bed (I hear recommendations of 30 minutes, I just try to go for ~15). Try to wake up with light, whether that's with a sunrise alarm clock that emulates the dawn, or the natural sunrise.
I really enjoyed this article on sleep optimization that was posted on HN recently: http://brianmartinek.com/2013/08/22/three-simple-ways-that-i...
Finally, working out is a tremendous help. Especially if you can try to do a workout that maximizes the release of hormones like endorphins and testosterone.
I really enjoyed this article on sleep optimization that was posted on HN recently: http://brianmartinek.com/2013/08/22/three-simple-ways-that-i...
Finally, working out is a tremendous help. Especially if you can try to do a workout that maximizes the release of hormones like endorphins and testosterone.
Here's a cache of it if it's still down:
http://web.archive.org/web/20130914013327/http://programmer....
Using that cache is a good idea. The site linked to was used to gather the original content rather than broad consumption. (I wrote two of the chapters in this book, and this was where we revised them.)
Lots of good articles in there, though.
Lots of good articles in there, though.
Nice work Ryan. I've been reading through these, and "Code is Design" is roughly similar to something I was trying to explain to my manager not too long ago, but I couldn't quite put it into words. I just sent him a link haha.
The parallels between software and physical construction are pretty amazing.
The parallels between software and physical construction are pretty amazing.
Jack Reeves essays on software design are also worth a read http://www.developerdotstar.com/mag/articles/reeves_design_m...
Yes, these are excellent, and goes into much more depth than the brief article I wrote.
Very kind of you to say! I came up with the metaphor when needing to explain this to a semi-technical person as well, so we've had similar needs there.
Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel.
http://programmer.97things.oreilly.com/wiki/index.php/Hard_W...
http://programmer.97things.oreilly.com/wiki/index.php/Hard_W...
Not sure I like #17 (http://programmer.97things.oreilly.com/wiki/index.php/Commen... ). While I would prefer working this way, my colleagues probably won't. Reading code you haven't written yourself is tough and time consuming. If the code is accompanied by the 'natural language explanation' of the code, you get into the code quicker. The downside to this is making sure they stay up2date, which was probably why the author wrote the section.
That's why it's worth having short methods that do one thing and are meaningfully named.
And from a personal point of view I'd prefer several lines containing short expressions that are then assigned to meaningfully named variables etc, rather than 1 really long hard to parse line of code.
This is how I originally felt a few years ago doing Ruby, and I have tried to make all my code human-readable since.
Yeah, nothing wrong with that, and if you do have a longer/more complex equation (like a C# LinqToSql where statement), you can always make it formatted multi-lined instead of in-line to improve readability. My point was mostly about not using comments that describe the code.
Occasionally I get asked to add comments in for standard language features that others might not know. That to me seems like a waste of time.
I have no problem emailing people to let them know of a feature they may not be aware of, but now that language feature is documented right there in our code base.
I have no problem emailing people to let them know of a feature they may not be aware of, but now that language feature is documented right there in our code base.
Comments also frequently repeat what is obvious and don't illuminate the bigger picture. Ie a Pythagorean theorem function would have a comment about squaring numbers and adding them instead of for what it's used in practice.
By extension that's something that often goes for documentation comments (Javadoc, doxygen, etc.). When reading those I find it not really useful to learn that the frobFoo(Foo f) method frobs a foo and leaving the use of that method, what frobbing is and what a Foo is out of that documentation. Figuring out how to use something larger is much easier when classes come accompanied by usage samples and some notes about how they fit into the larger picture.
It says: > Any shortfall between what you can express in code and what you would like to express in total becomes a plausible candidate for a useful comment.
This is a good way of looking at it... as long as you remember that this shortfall is often gigantic, and usually includes why this approach is being used instead of other techniques (which may have been used and abandoned for good reason).
Code does not exist in a vacuum. You should write code not just to compile, but to be read by others. And many times, the actual code might be only 30% of the important stuff. A good project may very well be 2/3 comments, 1/3 code, because it should include the reasoning behind coding decisions, which is often quite complex, but crucial to understanding why the code is written as is, and to understanding how to properly extend it.
Without that kind of documentation, you're doing a tremendous disservice to future programmers who seek to maintain or add to the code -- or to yourself, often times, when you pick up code you wrote yourself two years ago.
This is a good way of looking at it... as long as you remember that this shortfall is often gigantic, and usually includes why this approach is being used instead of other techniques (which may have been used and abandoned for good reason).
Code does not exist in a vacuum. You should write code not just to compile, but to be read by others. And many times, the actual code might be only 30% of the important stuff. A good project may very well be 2/3 comments, 1/3 code, because it should include the reasoning behind coding decisions, which is often quite complex, but crucial to understanding why the code is written as is, and to understanding how to properly extend it.
Without that kind of documentation, you're doing a tremendous disservice to future programmers who seek to maintain or add to the code -- or to yourself, often times, when you pick up code you wrote yourself two years ago.
This book is intended for beginning developers.
Tips like "put everything under version control" or "resist the temptation of the singleton pattern" or "floating point number are not real" are not exactly rocket surgery (pun intended).
(I own a copy, and consider it to merely be a shelve filler)
[deleted]
Here are the 97 contributions compiled in one gist : https://gist.github.com/pauletienney/6639605
Pull request are welcome for text formatting, linking, etc ..
Pull request are welcome for text formatting, linking, etc ..
I may be stupid, but how do I issue a pull request for a gist?
Also, http://www.amazon.com/Things-Every-Programmer-Should-Know/dp... for the dead tree version which supports its production.
created a readlist for this: http://readlists.com/36fc6507
HN Effect. Checking back when the crowds have died down.
Pretty sure that already has a name: http://en.wikipedia.org/wiki/Slashdot_effect
yeah except now Slashdot hopes to get "Hacker news'd"
One of my favorite bathroom books.
But a little too much OO-centric, and imho, a little out of date.
Why was the title of this submission changed? I clearly remember what i entered. Odd
Also available on Safari if you have it.
I spent the last few days inside putting together a website, and I feel like crap. My normal aches, and pains are turning into something serious in my hypochondriacal mind.