Will these books alone make a programmer

Then read some books man.
Just don't forget to apply yourself.

I have read more than half the chapters and usually done exercises. Most textbooks aren't meant to be read cover to cover.

If you actually put effort into understanding the material you will probably become a decent programmer. You also need to actually practice programming though.

>still can't get a proper answer
The state of this board

People learn in different ways idiot

No, writing computer programs makes you a programmer, by definition and in practice.

No, you have to read all of these.

Attached: Sci CS reading list mk.III.jpg (2500x4620, 3.76M)

Books will familiarize you with a language/concept to varying degrees. They will NOT give you the experience of building a product or working in a team. What separates good devs from bad devs and more broadly good engineers from bad engineers is the ability to take in a project as a whole, make sure your code doesn't fuck it up and is maintainable by others, and the ability to communicate with others effectively so that nobody steps on each other. Experience trumps theoretical knowledge ALWAYS.

That being said they do give you insight into some obscure shit sometimes, stuff that even experienced people might not know fully.

Attached: download.jpg (210x210, 24K)

Face it user, you can't compete without a degree. Doesn't matter if you actually read them all.

Yea, just like painting or writing books for 10,000 hours makes you a good artist/writer.

Oh wait, no it fucking doesn't because you're not learning shit when you do that, you're only regurgitating stuff (or worse, reinforcing bad habits) you already know and that's not the way to improve.

lol npc

I'm actually going to go against the tide here and say, yes, there is much to be learned from the books you've posted. The question is, Are you going to read them all in full and apply what you've learned to projects / etc. Reading about a concept is one thing, applying it is another.

Lisp is useless meme
dragon book is not that good book on compilers, there are far better
best chapters of TAOCP haven't been released yet and Knuth is walking dead already
Hacker's Delight is worth it, but more of a catalog than book. But Numerical Recipes on list next to it.
Intro to Algorithms is good, alternatives are also good. Algorithms are good. Good.
ESR is not relevant. Avoid old-school UNIX, it's so dogmatic it hurts.

Anyway, to put some of my list to the thread:
- CS:APP3e is nice despite some errors like promoting use of UB in C code, definitely need to know about memory hierarchy to be any good programmer. And the books also suck at giving you real tools, only describes concepts. Don't miss their uni material and labs.
- Essentials of Programming Languages
- Types and Programming Languages by Pierce
- Engineering a Compiler
- SSA book
- Cryptography Engineering: Design Principles and Practical Application by Schneier
- Plan 9 books (nemo book and Intro to OS abstractions)
- Reasoned Schemer, Little Typer and Little Prover
- Logical Foundations of Mathematics and Computational Complexity: A Gentle Introduction
- Serious Cryptography - A Practical Introduction to Modern Encryption was bretty goot, not sure which crypto books to recommend
- Guide to Elliptic Curve Cryptography
- Professional Linux Kernel Architecture by Wolfgang Mauerer and Love's Linux books
- Low Level Programming C Assembly and Program Execution on Intel 64 Architecture
- Game Engine Architecture

and something con computer networks, but every book on this topic I've read was either garbage or tanenbaum (aka that guy you want to shut up with useless stuff and get back to relevant topic and mostly skips the tricky part regardless of his books being this as long)

Just learn webdev and then rust on the side until it's ready to replace c++.

C is the first language all programmers should learn. Period.

K&R, while an essential read, does not have enough exercises, it should be used as a reference/supplement to King.

And King (better to say C in general) should be understood by any Unix-like OS user before learning anything declarative; manual memory management is essential to understanding the function of a computer system.

Higher-level languages like Python will forever be voodoo if you do not understand how a compiler produces assembly language from an imperative programming language.

Attached: 71SGNKTA4KL.gif (378x475, 200K)

C is garbage and learning it with an idea that it's something special will make you worse

>C is garbage
>will make you worse

No interest in memory mapped I/O or actually knowing a language's semantics in great detail; just stay milk-fed library gimp. Nice man.

Do you take your Macbook with a turtleneck and a latte?

what has memory-mapped IO anything to do with C, that's OS's feature
you can do it in any other language

>what has memory-mapped IO anything to do with C
>that's OS's feature

Read what you said there again.

if there is a CPU instruction or syscall for it then it has nothing to do with C

Confirm retard

>Wants to be a programmer without actually programming

nice

Just writing code without serious study will turn you into a code monkey, like this guy: Just studding without writing code will you useless and buried in dogmatism and theory.
Practice a lot, if possible with real problems and study a lot, but start with far easier books.
(Except K&R C, this book is pretty basic)

Instead of ripping on what's on what list or who-read-who, here's some of what's on my shelf and why:
>The Pragmatic Programmer
This is a good book. I bought it when I was first starting in my career to better understand my craft beyond simply code. It is a swiss-army knife of ideas and techniques, from generating code to decoupling, DRY to Big O, getting requirements from users and high-level architecture. When you are new this helps navigate whole lists of issues.
Recommended
>The Mythical Man-Month
If there is a crime in our profession, it must be the lack of historical knowledge. It's silly how many times we reinvent '70s discoveries. There are many lessons to learn from post-mortems and warstories. They are also enjoyable to read on their own right.
Recommended
>Working Effectively With Legacy Code
The moment you finish writing code, it becomes legacy. It needs maintenance. It will be extended. It will be abused. This book is dedicated to dealing with refactoring said code and techniques to safely do so. If you find yourself mired in a 10+ legacy C++ project that is millions of lines of code, this book is for you. Not that this happened to me twice.
Recommended.
>The Algorithm Design Manual
About midway to now, I wanted to sharpen and refresh my foundational algorithms. I like this book because it starts off with the mathematical analysis that underpins Big O and algorithm proofs. The rest of the book builds upon this as it introduces all the familiar data structures and algorithms. It also includes the author's warstories about designing unique algorithms for special cases.
Recommended

I own SICP, Introduction to Algorithms, the dragon book, The Art of UNIX Programming and The C Programming Language and I can assure you that no amount of reading about programming will make a programmer out of you, programming is a craft, it needs practice, a long ass time and the love of the field to even get close to be a good programmer.
In the spirit of good ol' Jow Forums I only have one advice for you, DO IT FAGGOT.

>the programming language
books are the only books youll need imo

Which brings me to this book. Not only do I recommend this to other programmers, I let my non-programmer friends borrow my copy. I bought this book twice (2nd and 3rd edition) it is so good.
On page 4 there is this passage:
>The cause of failure most frequently cited by our survey participants was "politics." But now observe that people tend to use this word rather sloppily. Included under "Politics" are such unrelated or loosely related things as communication problems, staffing problems, disenchantment with the boss or with the client, lack of motivation, and high turnover. People use the word _politics_ to describe any aspect of the work that is people-related, but the English language provides a much more precise term for these effects: They constitute the project's sociology. The truly political problems are a tiny and pathological subset.
>If you think a problem as political in nature, you tend to be fatalistic about it. You know you can stand up to technical challenges, but honestly, who among us can feel confident in the realm of politics? By noting the true nature of a problem as sociological rather than political, you make it more tractable. Project and team sociology may be a bit outside your field of expertise, but not beyond your capabilities.
This book is both funny and a little too close to home. It cuts across an entire organization, with problems and solutions from the lowest grunts to the CEO; from too many meetings, opposing Open Office Plans, Hiring, turnover, being a manager as well as working for a manager, motivational posters are shit, making and braking teams, insurgent skunkworks, fighting bean-counters, furniture police, the list just goes on!
I continuously see myself in many chapters. It also helps describe problems you can only sense, but cannot put into words. Like The Mythical Man-Month, this helps describe many aspects of our profession beyond the code.
So recommended it should be on your bookshelf yesterday.

Attached: peoplware.jpg (411x600, 58K)

After you finish reading all of them you'll be just a well read codemonkey. has a point as does .

In a way it is similar to learning how to draw. You get good at it by drawing lots of garbage.

don't forget to do all the exercises

>They will NOT give you the experience of building a product or working in a team.

This is so true. I've been doing personal projects and contributing to opensource projects (~500 commits in one of them with 10k net lines contributed in the one i put most effort into) for 15 years in addition to helping people out on Jow Forums, IRC and stackoverflow.

People always comment on how good I am and shit but I've been doing freelance work for about a year and I'm still completely lost on how to handle A LOT of stuff. I don't have trouble with coding itself but coming up with good solutions.

When working with opensource software there's always many devs and a community to give you ideas, but when you're on your own or in a very small team (I have only one coworker in the current gig) it gets HARD.

FUCK

HOW DO I STOP THIS AND GET DISCIPLINE?

Best books on how to be a good programmer:
12 rules for life
How to win friends and influence people
Mastery
Art of war.

No need to thank me.

Dude, I've literally went through those books a few weeks ago. Most of them are useless coz they are based on list, Oz/mozart, pascal and other old shit
Still, I would very much recommend reading from them:
Cathedral and the bazar; the dao of programming; introduction to algorithms; the c language

>part me from the average codemonkey.
If you want to be "different" then when applying for jobs think outside the box. Nobody interviewing you will give a shit about you being able to regurgitate crap out of a book. They want to know what you can "do".
I wouldn't spend time reading most of those books outside of K&R and Sedgewick's Algorithms, because really unless you plan of being a compiler writer for open source or closed source projects you'll be wasting your time, space on your bookshelf and money.

t. shit programmer

Just admit you need hand holding and enroll in cs

Opinionated idiot