Found in 37 comments on Hacker News
Read extensively, practice your craft & don't lose your focus.

These books will help you day-to-day with your general programming knowledge...

> Philosophy of Software Design https://www.amazon.com/Philosophy-Software-Design-John-Ouste...

> The Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

> Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

> Mythical Man-Month https://www.amazon.com/Mythical-Man-Month-Anniversary-Softwa...

letientai299 · 2020-09-22 · Original thread
If you just want to write better code literally, then consider reading Clean Code[0].

If you want to dive deeper in to Computer Science and become a Software Engineer, then there's a lot more to learn. Here's some short tips:

- Learn a few programming language for their paradism: Java (OOP); Python, Hashkell, Scala (Functional Programming), Rust (memory safety). You don't have to actually work on them, just need to be able to write some algorithm and know their key features.

- Read more code, especially those from high quality projects.

- Experiment a lot. Don't just read articles, blog posts. You have to get your hand dirty.

[0]: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

This book is a great read for writing maintainable code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
CodeSheikh · 2019-01-17 · Original thread
Nice list. Appreciate it. But I see there are a few amazing software books missing from the list such as:

- Clean Code (by "Uncle Bob")) [https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...]

- Design Patterns (by "Gang of 4") [https://www.amazon.com/Design-Patterns-Elements-Reusable-Obj...]

- Introduction to Algorithms (by "CLRS") [https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press...]

otras · 2018-11-04 · Original thread
I'd recommend the following:

Clean Code: A Handbook of Agile Software Craftsmanship [0] is a great book on writing and reading code.

Similarly, Clean Architecture: A Craftsman's Guide to Software Structure and Design [1] is, no surprise, a book on organizing and architecting software.

Designing Data-Intensive Applications [2] may be overkill for your situation, but it's a good read to get an idea about how large scale applications function.

The Architecture of Open Source Applications [3] is a fantastic free resource that walks through how many applications are built. As another comment mentioned, reading code and understanding how other programs are built are great ways to build your "how to do things" repertoire.

Finally, I'd also recommend taking some classes. I started as a self-taught developer, but I've since taken classes both in-person and online that have been a tremendous help. There are many available for free online, and if in-person classes work better for you (motivation, support, resources, etc), definitely go that route. They're a fantastic way to grow.

[0]: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

[1]: https://www.amazon.com/Clean-Architecture-Craftsmans-Softwar...

[2]: https://www.amazon.com/Designing-Data-Intensive-Applications...

[3]: http://aosabook.org/en/index.html

fdsvnsmvas · 2018-09-10 · Original thread
Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread:

Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168

Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2

Clean coder: https://cleancoders.com/ videos

Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

Hitchhiker's Guide to Python: https://docs.python-guide.org/

Dustin Boswell The Art of Readable Code: https://www.amazon.com/Art-Readable-Code-Practical-Technique...

John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!

Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

Dan Bader, Python Tricks: The Book: https://dbader.org/

Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...

Svilen Dobrev, various: http://www.svilendobrev.com/rabota/

antjanus · 2018-07-27 · Original thread
I usually recommend a few different books:

Clean Code: A Handbook of Agile Software Craftsmanship

http://amzn.to/2vcRcgU

This book really helped me focus on code organization and seeing maintainable code as an overall goal whilst building long-term applications. I'd say that one of the reasons why the work I've done 3-4 years ago can still be used, expanded, and maintained today is because of this book. Short functions, code organization, and naming conventions all stuck with me.

I'd say that unlike other programming books, this one focuses on the "art" and "organization" rather than syntax and other aspects of programming.

The Pragmatic Programmer: From Journeyman to Master

http://amzn.to/2vfeUaT

This book tackled real-world application building and practices. I'm still reading it. I liked how it tackled not only some basics of programming (resource management practices) but also project management to a certain extent. Eg. how to use prototypes, how to use "trace bullet" programs, etc.

Game Programming Patterns

I think one of my favorites has been "Game Programming Patterns" http://gameprogrammingpatterns.com/ which is free online or you can get an ebook/print version http://amzn.to/2veRdiO

The book introduces several basic design patterns, it explains WHY they're used, how to implement them, etc. in the best way I've read so far. No CS book or online article has been able to explain these patterns as this book did.

And I'm not even a game developer.

Also, check out this post on dev.to -- https://dev.to/ben/what-are-the-most-interesting-readable-so... it has some good answers! :)

framebit · 2018-02-14 · Original thread
2340 (the mandatory group project course) also covered a lot of this stuff, though not in as much detail.

The suggested reading for that course is a book that blew my mind when I first saw it as an undergrad: Clean Code by Robert Cecil Martin. I believe the examples are all Java, but the lessons are applicable to any language. Stuff like naming your variables more carefully than you name your children.

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

technofire · 2017-07-20 · Original thread
I agree with several other users on this thread about maintaining existing code. If you aren't already working in a position in which you have to modify code written by others, try to start fixing bugs or writing features for an open source project. In either case you should immediately see how frustrating it is to try to figure out why things in the code base are the way they are, and I think the best solution is not documentation but clear, clean code that self-documents, not with comments but with small focused recipe-like functions. Bob Martin's book Clean Code[1] is a quick read that makes clear how this can be done effectively. Martin Fowler's book[2] is another obviously good illustration.

The second thing that has really influenced my coding style for the better (making it clearer and easier to understand) is writing a medium-sized program using a strictly functional language like Erlang. This will force you to use global state less, to write functions in such a manner that the function itself includes all the information required to understand it, simply because global state cannot be used and everything on which the function operates must be passed into it explicitly via its parameters.

[1] Clean Code (Robert Martin) http://amzn.to/2uewcpB

[2] Refactoring (Martin Fowler) http://amzn.to/2vnD7vx

W0lf · 2017-06-05 · Original thread
I've gathered all the book titles in this thread and created Amazon affiliate links (if you don't mind. Otherwise you still have all the titles together :-) )

A Pattern Language, Alexander and Ishikawa and Silverstein http://amzn.to/2s9aSSc

Advanced Programming in the Unix Environment , Stevens http://amzn.to/2qPOMjN

Algorithmics: the Spirit of Computing, Harel http://amzn.to/2rW5FNS

Applied Crytography, Wiley http://amzn.to/2rsULxS

Clean Code, Martin http://amzn.to/2sIOWtQ

Clean Coder, Martin http://amzn.to/2rWgbEP

Code Complete, McConnel http://amzn.to/2qSUIwE

Code: The Hidden Language of Computer Hardware and Software, Petzold http://amzn.to/2rWfR9d

Coders at Work, Seibel http://amzn.to/2qPCasZ

Compilers: Principles, Techniques, & Tools, Aho http://amzn.to/2rCSUVA

Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant http://amzn.to/2qPY5jH

Data Flow Analysis: Theory and Practice, Khedker http://amzn.to/2qTnSvr

Dependency Injection in .NET, Seemann http://amzn.to/2rCz0tV

Domain Driven Design, Evans http://amzn.to/2sIGM4N

Fundamentals of Wireless Communication, Tse and Viswanath http://amzn.to/2rCTmTM

Genetic Programming: An Intrduction, Banzhaf http://amzn.to/2s9sdut

Head First Design Patterns, O'Reilly http://amzn.to/2rCISUB

Implementing Domain-Driven Design, Vernon http://amzn.to/2qQ2G5u

Intrduction to Algorithms, CLRS http://amzn.to/2qXmSBU

Introduction to General Systems Thinking, Weinberg http://amzn.to/2qTuGJw

Joy of Clojure, Fogus and Houser http://amzn.to/2qPL4qr

Let over Lambda, Hoyte http://amzn.to/2rWljcp

Operating Systems: Design and Implementation, Tanenbaum http://amzn.to/2rKudsw

Parsing Techniques, Grune and Jacobs http://amzn.to/2rKNXfn

Peopleware: Productive Projects and Teams, DeMarco and Lister http://amzn.to/2qTu86F

Programming Pearls, Bentley http://amzn.to/2sIRPe9

Software Process Design: Out of the Tar Pit, McGraw-Hill http://amzn.to/2rVX0v0

Software Runaways, Glass http://amzn.to/2qT2mHn

Sorting and Searching, Knuth http://amzn.to/2qQ4NWQ

Structure and Interpretation of Computer Programs, Abelson and Sussman http://amzn.to/2qTflsk

The Art of Unit Testing, Manning http://amzn.to/2rsERDu

The Art of Unix Programming, ESR http://amzn.to/2sIAXUZ

The Design of Design: Essays from a Computer Scientist, Brooks http://amzn.to/2rsPjev

The Effective Engineer, Lau http://amzn.to/2s9fY0X

The Elements of Style, Strunk and White http://amzn.to/2svB3Qz

The Healthy Programmer, Kutner http://amzn.to/2qQ2MtQ

The Linux Programming Interface, Kerrisk http://amzn.to/2rsF8Xi

The Mythical Man-Month, Brooks http://amzn.to/2rt0dAR

The Practice of Programming, Kernighan and Pike http://amzn.to/2qTje0C

The Pragmatic Programmer, Hunt and Thomas http://amzn.to/2s9dlvS

The Psychology of Computer Programming, Weinberg http://amzn.to/2rsPypy

Transaction Processing: Concepts and Techniques, Gray and Reuter http://amzn.to/

Types and Programming Languages, Pierce http://amzn.to/2qT2d6G

Understanding MySQL Internals, Pachev http://amzn.to/2svXuFo

Working Effectively with Legacy Code, Feathers http://amzn.to/2sIr09R

Zen of graphics programming, Abrash http://amzn.to/2rKIW6Q

data_hope · 2016-12-13 · Original thread
- don't only worry about code or getting features shipped, but about the process, how to deliver quality.

- behind any given reason, there is a complex network of real reasons. You don't need to second-guess any decision/order/suggestion, but it helps understanding.

- most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")

Essential reading list:

- Clean Coder and Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... https://www.amazon.com/Clean-Coder-Conduct-Professional-Prog...

- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

rjblackman · 2016-12-10 · Original thread
read clean code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

and clean coder https://www.amazon.com/exec/obidos/ASIN/0137081073/metafilte...

If you follow the (admittedly pretty extreme) advice in these books you will be in the top 10% at least.

joshka · 2016-08-18 · Original thread
TL;DR - It depends ;)

The examples you provided (with some context gleaned from your other comments) look like they're probably too long and tack on unnecessary domain specific detail (e.g. jsonStates).

Both variables in your example would likely be better off describing the use of the variable rather than the contents. E.g. use ageInYears rather than yearsAliveInt. Taking it to your example, perhaps something along the lines of convertedDocument would do, this is significantly shorter than your example, but perhaps conveys enough info for your ongoing usage.

This is covered to in Clean Code [1]. "The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used." The notes on the naming chapter at [2] are quite good as well (as noted elsewhere on this thread by @runesoerensen)

I like to follow the principle in naming variables that if I could read the code to a non-technical user verbatim and have them understand the code, it is "good code". I.e. does reading the code out loud as a sentence make sense, or do the verbs and nouns I've chosen act as a barrier to understanding.

EDIT:

Ward Cunningham said that last part better: “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.”

[1] Martin, Robert C. (2008-08-01). Clean Code: A Handbook of Agile Software Craftsmanship (p. 18). Pearson Education. Kindle Edition. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

[2] http://www.itiseezee.com/?p=83

HerpDerpLerp · 2016-03-29 · Original thread
He does reference it in both the first and last paragraph!

my fave is clean code... though uncle bob seems divisive these days for some reason.

http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsm...

stanmancan · 2016-01-21 · Original thread
How is plusMonths(1).plusDays(1) obscure in any way? You could show that to my grandparents and they would be able to guess what it does. "+1m1d" on the other hand they wouldn't have a clue.

Length, in either direction, does not correlate to "clean". Clarity and intent does. Clean Coder (http://www.amazon.ca/Clean-Code-Handbook-Software-Craftsmans...) does a fantastic job talking about this, it's worth picking up if you haven't read it in the past.

Toine · 2015-06-22 · Original thread
Same here. I only have 2 years of experience, but right now my opinion is that this is not something you learn in a book (for the moment).

You can learn how to create clean, readable methods and classes with a book (1).

You can learn how to refactor old methods and classes with a book (2).

You can learn how to organize a small team to allow fast iterations with many books.

But building a project lasting more than a few months with constant changes in the requirements, new developers every month, new SDKs and frameworks every 3 days, without the code rotting to death and everything going out of control is a different story, at least for me.

I guess you just learn by watching old guys do what they do after decades of experience...unless someone has a magic book for me?

(1) http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

(2) http://www.amazon.com/Refactoring-Improving-Existing-Addison...

petersellers · 2015-05-05 · Original thread
For writing clean code, I highly recommend Uncle Bob's "Clean Code":

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

oblique63 · 2014-12-05 · Original thread
Check out the guys over at 8th light: http://blog.8thlight.com/

Uncle Bob in particular (the author of Clean Code[0], The Clean Coder[1], and the Clean Coders videos[2]) is a lot like Wozniak.

[0] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

[1] http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...

[2] http://cleancoders.com/

shreeshga · 2014-11-06 · Original thread
Give them a free copy of Clean Code[1], I started to care about my code more after I read that book.

You cannot sit and review each commit, the best you can do is to make them care about code.

[1] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

raju · 2014-04-22 · Original thread
Great post. If you want a even _further_ expanded version of this I highly recommend "Clean Code"[1] by Robert C. Martin, and I learned a few days ago that there is a follow up book, "The Clean Coder"[2] which I am yet to read

[1] - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

[2] - http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...

ghh · 2014-02-13 · Original thread
Yes! Please refer to the image at [1]. It's also on the cover of the introduction of 'Clean Code' [2]. Everyone here has some code that they are not proud of. You should see it as a sign that you've learned from the experience of designing and developing it.

Want to steadily improve on non-production code? Try codewars.com: you're asked to solve 5-30min coding exercises and after can immediately browse the solutions of your peers. The short feedback loop helps you understand how you could've improved while the code is still fresh in your head.

[1] http://www.osnews.com/story/19266/WTFs_m

[2] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

datawander · 2014-01-30 · Original thread
My favorite rule is 4.1.1; always use braces even where optional. I think a small fraction of the economy may have been damaged by the bugs caused by the silliness of leaving out optional braces and then having another developer come along and, well, you know how that goes :)

As someone who once read the Sun Java Style Coding [1] (which at a quick glance, appears to be a super set of the Google style guidelines) standard years ago and found it exciting and very helpful material, I unfortunately did not get such a kick skimming through this. Perhaps it's because after having read Clean Code [2], I feel that there is much missing that can lend itself to better code.

[1] http://www.oracle.com/technetwork/java/javase/documentation/...

[2] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

NicoJuicy · 2014-01-22 · Original thread
For everyone that didn't knew this, http://amzn.to/1hhI37v

You should read it..

PS. It's the book Code Clean ;)

facorreia · 2012-12-10 · Original thread
I got around this mindset along the years, by learning about the importance of lowering the maintenance costs, improving collaboration and not depending on any single person to understand any given module or system.

Books such as "Code Complete"[1] and "Clean Code"[2] should help you with that transition.

[1] http://www.amazon.com/Code-Complete-Practical-Handbook-Const...

[2] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

boos3y · 2012-07-13 · Original thread
As a recent college graduate, I can tell you that they still teach the comment everything everywhere method, and in fact for most of our programming projects, documentation was at least 20% of the grade. I professionally, do not comment, but instead, write "clean code" that can be understood simply by reading it. Anything complicated I comment, but usually that means I need to refactor and rethink my approach.

I highly recommend this book: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman... as it changed my life when it comes to software development. I have a real problem with commenting everywhere as most of the time you'll find a lot of public String getName() with like a comment of //Gets the name, uh, durr its name is get name! If you create concise methods with one general purpose you can create very readable code. Definitely check the book out, it is a very good read.

mweibel · 2012-07-06 · Original thread
Well done code has good variables, good method/function naming and small methods/functions. If you have those 3 parts, you won't need any comments because it's self explanatory.

Comments often tend to explain the same thing as the code exactly does and what you see w/o looking at the comment. Also, they tend to be forgotten - if someone changes the code, he/she often doesn't change the comment. As a result, you'll have an outdated comment which can confuse you.

I recommend "Clean Code"[1] for more info on this subject. Beside other chapters, there's a chapter about what's a good and what's a bad comment.

[1]: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

raju · 2012-02-20 · Original thread
I am glad someone wrote this article - Now I know I can point it to my colleagues who are often baffled at the amount of time I spend thinking about names :)

I have found that when I can't find a good name for a method or a class, it's because I haven't really thought the reason for the same through. This is especially true for classes where I often realize that I am making the class do too much, or too little.

This book, "Clean Code" by Robert Martin has it's second chapter dedicated to naming things. A whole chapter! The book, alone for that chapter is worth the money. If you haven't read it, I highly recommend it.

http://www.amazon.com/Clean-Code-Handbook-Craftsmanship-eboo...

bguthrie · 2012-02-14 · Original thread
Robert C Martin (Uncle Bob)'s Clean Code is a great read and discusses good naming in exhaustive and occasionally alarming depth.

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

swanson · 2011-12-30 · Original thread
The first step is to be aware that you aren't writing succinct, manageable code - so you are already making progress :)

I'd recommend these books, mixed with some searching around for best practices for whatever specific framework/language/toolkit you are writing code with.

Clean Code

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

Refactoring to Patterns

http://www.amazon.com/Refactoring-Patterns-Joshua-Kerievsky/...

Clean Code seems quite a bit more relevant and in-depth than this.

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

roryokane · 2011-06-08 · Original thread
Other people have already said most of what I wanted to say – that self-explanatory code, and sometimes tests, is almost always better than comments. I just want to point out a good reference on this topic: the book Clean Code: A Handbook of Agile Software Craftsmanship [1], specifically Chapter 4, “Comments”. That chapter gives examples showing which comments should be turned into code and which are acceptable to leave as comments, and it explains the reasoning behind the choices. (And the rest of the book teaches you how to make your code self-explanatory and easy-to-read.)

[1] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

Freebytes · 2009-11-05 · Original thread
The book that changed my life:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...

"Clean Code" by Robert Martin is one of the best programming books ever written, and it barely has any code in it. However, it is relevant for every programming language. He treats unit tests like mandatory rituals, though, and unfortunately, I have not progressed quite that far yet. Still, it is a must read and gives good insights into this topic.

Fresh book recommendations delivered straight to your inbox every Thursday.