Software Engineering Books To Read

[Barbro Faries]

Ive read a lot of resumes, some good, some bad, and they've never had a list like this. Honestly, it would indicate to me a candidate who has extremely little hands-on experience and is desperate to pad a thin resume. And a candidate who hasn't bothered to research common resume formats. Such a resume would most likely be circular-filed. By me, anyway.

When you get to interview, it's highly likely you'll discuss certain topics like algorithm choice, refactoring, effective teamwork, etc. This'd be the time to discuss your experiences and optionally give references to widely-recognised books on those topics.

As an employer, I wouldn't be able to tell from listing the books on your CV whether you'd read them or just pasted them into your CV after copying from a 'recommended reading list' on Programmers/StackOverflow.

I see it as very tacky and opening yourself to a lot of problems you can avoid. For example, say you list Programming Pearls as a read book. What if the interviewer happens to remember something very specific in that book because he has also read it.

Having read books on the subject is an added bonus... something that shows you are interested in learning from the experts. You don't just copy & paste code or write code that seems "good enough." You went out there and read about why certain solutions are better than others, etc.

Should you put C++ for Dummies on your resume? Of course not. If those are the books that you've read, then the answer is definitely not. However, if you've read some of the more respected books, then I would say yes.

My guess is that it just depends -- though when ranking knowledge over experience, experience always wins. I'd suggest focusing on mapping and expanding the real world experience you have, instead of the books you're read.

Considering most programmers out there haven't read any programming books it might not be such a bad idea. Maybe a favorite programming book section, would certainly make for a good conversation in an interview.

But what I think would be a good thing is to mention how you read something in a particular book, and did something interesting with it: maybe you applied Chris Okasaki's Purely Functional Data Structures to Java, or something.

This could work if you have inside information about the person or company with whom you are interviewing. If you read on LinkedIn that the hiring manager is a big fan of a certain book, then putting that on your resume would be a way to get noticed by them.

I never saw a book (list) on a CV, either, but I think it's a good idea. People I interview regularly list languages even though they only learned them for fun, so why wouldn't you list books, if you read them throughly, did all the exercises, etc. Judging by the other answers here, it would probably depend on the person who reads the CV, though.

Another option would be to mention books in the cover letter. For example, if you apply for a job at a company that creates speech recognition software, you could write that you've read [insert standard literature about speech recognition here] and that you found it very interesting and would be excited to work in this field professionally. Of course, that only works for books that have some connection to the job you're applying for.

Not on a resume. I could picture there being a case of it making sense in a cover letter or interview to make a point from a book if it seems applicable. For example, if a company mentions refactoring in a job description and you know a good quote from the book "Refactoring" by Martin Fowler, it may be useful to demonstrate this. Resumes generally are more for showing what experience you have rather than just having some knowledge on a subject.

Like most of the other respondents, I think it's a bad idea. What I would do is start a blog and review the books. Or write reviews on Amazon and come up with a clever way to link them on your blog. Mention the things you learned from the books and try to tie it back to your experience or side projects.

If you really need some resume filler, how about taking some of the knowledge that you learned from all those books and making a cool application. You can probably squeeze in personal projects somewhere on the resume.

I think it depends how you present that books on your resume.If it just a list, than it can smell like you have nothing to add or don't know what to add to your cv.But if you add it more like IT courses or certificates, it can be interesting.

Don't do it. It won't make your CV look more impressive. You can mention the books that you have studied (in contrast to "read") during your interview. But be prepared to answer which parts did you like and which you didn't. An answer like "it's the best X programming book" is not sufficient and will make things worst.

All kidding aside, I'm one of the people who finds reading to be very difficult. If I'm working my way through a very large book, I try to read early in the morning, when I first wake up, when my mind is free of distractions. I find that I'm able to get engrossed much easier at that time of day and I retain more.

Then, there are books that are just so dry that they will be painful no matter the reading circumstances. I try to avoid them whenever possible, or find another book with the same information that is written in a different style. If reading a book is so painful that you can barely keep from putting it down, you are wasting your time because you probably won't retain much anyway.

Additionally, though sort of digressing, I really enjoy it when people take time to write book reviews on their blog or personal web site. That helps me to find books that are best suited to me. So, if you love or hate a book, consider publishing a review. It will turn up to people who might be interested in whatever book you are discussing.

Time, effort, and persistence. For example, it took me months (maybe 6 months, 30 minutes per day) to crawl through Code Complete initially. Be sure to highlight important things and make personal notes so that you can revise the essential points later on. You won't learn much by merely staring at the text.

Start by prereading the manual, i.e., do not start by reading the manual cover to cover, but start by reading the title of the manual, the publisher's blurp (if there is any), the preface or introduction, and then study the table of contents. Then start reading parts of the sections that you discovered are most relevant to you (summary paragraphs at the beginning or end of chapters are especially good to read when prereading).

I'd highly recommend How to Read a Book. It gives general advice on how to get the most out of your reading by taking notes, asking questions, determining the authors goals, etc. It also gives advice on how to make the most of your time by determining what can be skimmed or skipped early on.

It's not aimed specifically at technical books, but the advice certainly applies. And it's a fairly easy read itself, though lengthy. But a number of the chapters on specific types of reading can be skipped.

Also, talk to others/even yourself about what you've read. Most techies are interested in hearing summaries of interesting books, and will provide their own summaries of things they've read, resulting in interesting technical conversation.

What I do is kinda "Breadth-first read": first the table of contents, then I try to read the chapters in order but not so in-depth, skipping big chunks of text and going straight to code, backtracking a little if necessary to understand it. Having a better idea of the book, I fully read the interesting chapters and left the rest of the book to be read "on demand".

I often skim the book a couple times, reading sections that catch my eye. After that I have a good idea what's in the book and can grab it later when I need to learn more about something. Then, as time permits, I'll read through it more methodically.

I've been developing over 30 years, and taught myself the majority of what I know by reading and trying what I've read. I'm very much a hands-on learner and like to tinker and tweak as I try out sample code if I'm unsure about something.

It's essential to keep learning if you want to make a decent living in programming. What technologies you know now and think are hot will be stale and over crowded in five years so you have to keep learning. Developers don't have the luxury of learning one thing and then relaxing. That's partly good and partly bad because the burden is on us to keep learning, but I think most developers love the creative challenge so we accept that price.

What I've found important is to read the preface. Often the author(s) will give you some suggestion on how to read the book. Also, I try to read the introductory chapters straight through, even if I think I already have the necessary background. I find that it often helps familiarize me with the book's vocabulary (e.g., "When we say 'server', we mean the physical hardware; when we say 'Web server' we mean the application server instance.").

I also have to fight the urge to skim. Reading for comprehension is different from reading for reference. Slow down, and take a break every couple of pages and review what you've just read. Re-reading challenging sections often feels like a waste of time, but it pays off in the long run because it helps me comprehend later sections faster.

If I get one of those big ol' reference type books, I read it as a reference. Meaning, I skim it looking for the key points, and trying to learn the book so that I know where to look something up when I need it. A good example is my C reference manual. I have read it through, but I couldn't quote the C specs to you. However, I know most of the important things, and I can look up anything I need to quickly because I'm familiar with the layout of the book.

If I'm reading a how-to or introductory book, I generally do it in front of the computer so I can try the stuff as I go. My favorite intro books have lots of code in them to try - and I'm telling you, Don't use the code samples on the CD!!! You'll gain much more practical knowledge by typing it yourself.

3a8082e126