Live data from Hacker News

Ask HN: Books you should have read when you start a career in SE / CS?

news.ycombinator.com

11–20 of 99 posts

Re: Ask HN: Books you should have read when you start a career in SE / CS?

#12
There are many books which sound good in theory but I think my younger self would not have been able to make use of the wisdom in those books because I did not have the experience to relate to what the book was talking about. Nevertheless, if I had to ignore this factor, I too, like many others in this thread, recommend "The Mythical Man Month". However, I think, it's more important to figure out what one wants from life than to just better one's craft. Of course if that is what you want in life, then indeed pursuing that makes sense. I'm also tempted to recommend "Siddhartha" by Herman Hesse and "The Consolations of Philosophy" by Alain de Botton.

Re: Ask HN: Books you should have read when you start a career in SE / CS?

#13

I've read most of the recommended books, but as far as what I think has delivered immediate real value, I'm going to go with: 1) Clean Code 2) The Phoenix Project 3) UNIX and Linux System Administration Handbook I'm sure #2 will be something folks want to fight over shrug . If you want to sidestep years of headache it's a must-read though.

To elaborate, the best things you can do for yourself when starting your career are be easy to work with and have a clear picture of what good code/system/project/team/company organization looks like.

Don't worry about coming out of the gate skills-hot. It's a marathon, not a sprint. If you are lucky and good, you will be doing your best work late in your career, not at the beginning.

None of the other recommended books tell you how to name things, and that's always going to be the most important problem to solve anyway ;)

Re: Ask HN: Books you should have read when you start a career in SE / CS?

#14
post #7

1) The Art of Computer Programming 2) The Art of Computer Programming 3) The Art of Computer Programming 4A) The Art of Computer Programming

Has anyone really read these books from page to page?

Also, are they really relevant when you are starting your career? These seem more into the category of making you competent in the field of algorithms research, rather than something a person starting a career should read.

Re: Ask HN: Books you should have read when you start a career in SE / CS?

#15

Three boks I'll recommend you read as soon as possible. 1) The Mythical Man month 3) The Pragmatic Programmer 3) Code Complete. The thing about these books, well atleast 1 and 3 is that when they were written they broke new ground. Or if that phrase bother you, they were the first mainstream publications that brought their core ideas to developers. Reading these books early in your career will help cement these best…

I always started and stopped reading Code complete book. The most recent strategy that really worked for me was. I googled summary notes for that book to recognize the topics that I wanted to learn and ditched the ones that are redundant.

This rejuvinated my interest and productivity for reading that book.

Re: Ask HN: Books you should have read when you start a career in SE / CS?

#17
post #6

1. Mythical Man Month - obvious reasons 2. Deathmarch: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects- also a classic. 3. Thinking fast and slow - a great introduction to biases that will affect your thinking in any project. 4. The Art of War - strategy and tactics for attacking any problem. My personal favorite translation is by Thomas Cleary.

It's next to impossible to find a soft copy of "Deathmarch", except for in Russian. I tried but I haven't found yet.

Re: Ask HN: Books you should have read when you start a career in SE / CS?

#20
Don't Make Me Think by Steve Krug and The Design of Everyday Things by Don Norman.

While they're not strictly software or programming related, I really like the concepts of making interfaces that require minimal thought to use and empathizing with your users. I've seen an unfortunate amount of "programming machismo" where a confusing or poorly engineered system is used and accepted because "that's just how things work in the real world". And whenever someone struggles with the process, it's obviously because they're wrong, not the system. But more often than not, if more than one person has trouble understanding your system, whether it's an API, a website, a build process, the design is the issue.

Post reply on HN