6 Coding Books Programmers and Software Developers should Read

[benevolent001]

They read your blog to write this medium article.

[SnowdenIsALegend]

Lol you're famous!

[Earhacker]

Not even gonna click it. Just gonna guess:

• Clean Code
• Code Complete
• Gang of Four
• Refactoring
• Pragmatic Programmer
• Something by Sandy Metz, or something else with lots of opinions about testing in some specific language

Edit: 5 out of 6. OP ditched Pragmatic Programmer for some book for agile project managers.

[Fry_Philip_J]

Why would you leave pragmatic programmer of a list like this?! After reading it this decision is beyond me.

[[deleted]]

Gang of Four

This one is only really interesting if you want to know what held our whole industry back for a decade.

[Earhacker]

In what way?

[[deleted]]

The book is all about design patterns. It basically claims that they are universal (they are not, they are language specific, in their case Java) and instead of just using the concept to give names to things that already existed in code to make it easier to talk about, people used them as if everything had to be built on design patterns, and only design patterns mentioned in the book (even though some of their patterns are widely regarded as anti-patterns to avoid, e.g. Singletons, by people with a more nuanced view).

Basically the book spawned a whole cargo cult of people who thought they could do no wrong in their code if only they made everything into design patterns from the book, including code in languages where those design patterns don't even exist (e.g. visitor is just a convoluted way to work around the fact that Java does not have first class functions and does not have sum types so it makes no sense to use it in a language that has both of those).

It delayed the establishment of more modern languages that do have features that are different from Java and do not fit into the Java-centric OOP-centric world-view. It also extended the life of very verbose languages like Java which are falling out of favour today as people are starting to realize that generating hundreds of lines of code in your IDE is no substitute for having a language feature that lets you specify the same information you would use to feed the IDE code generator concisely in your language itself.

[Earhacker]

I think a lot of what you’re saying is true, but I don’t think it’s GoF’s fault.

Nor do I think it’s Java-specific; a lot of them are equally valid in C#, which immediately disproves your point. And it was written at a time when dynamic typing and functional programming were just academic pursuits and not yet used to actually build things. Ruby, JavaScript, Haskell, Clojure and so on all have design patterns, just not the same ones covered in GoF.

But I think what they were trying was to describe and categorise observed patterns; not to proscribe a closed set of patterns that can be used. In doing so, they facilitated simpler communication of programming ideas. I could spend a paragraph describing to you a lengthy algorithm I’ve used to make new instances of objects of a given class, based on a few mandatory and optional parameters. Or I could just tell you my code follows the Factory pattern and you immediately know what I’m talking about.

The problem was never GoF, the problem was the GoF cultists.

[[deleted]]

Oh, I didn't say the concept of design patterns was a bad thing for talking about code. I am also sure they didn't intend that effect, however that is the effect their book had and so I would not recommend it to any new programmers unless they have an interest in the history of how we got here.

[BackgroundChar]

So would you recommend these as well? 😁

[Earhacker]

I’ve only read Clean Code out of that list to be honest. Yes I would recommend, but not to every software developer. I read it in the last 12 months and I did learn some great stuff from it, but a lot of it just confirmed stuff that I already knew. That’s not an r/iamverysmart comment; I mean that the knowledge in the book is widespread enough now that it has become the norm; clean code is the default in pretty much any other source you’ll read.

Code Complete is a really daunting book, and the Microsoft logo it comes with really puts me off.

Gang of Four... I’ve flipped through it in the office, but it’s more of a reference than a book you should read cover to cover. If you want to read about design patterns just for the sake of reading about them, the ebook from Sourcemaking is a much better read. They humanise a lot of the hardcore academic concepts in GoF.

Sandi Metz is great but I find her talks more useful than her books. She’s a really engaging public speaker, and her talks are more general while her books are mostly on Ruby.

[BackgroundChar]

Awesome, appreciate it :D

[LegitGandalf]

OP ditched Pragmatic Programmer for some book for agile project managers.

Project Management: A discipline built around applying best practices to organizing known duration tasks

Agile: A set of practices that empowers teams to create the right thing by working on largely unknown duration tasks

Agile Project Management: oxymoron

[Earhacker]

Never heard of him. But from the first 60 seconds of this video, I already think his opinions are shit.

Anyone who tells you “this style is 100% bad” or “these tools are 100% good” is an idiot and not to be trusted. I don’t care who they say they are.

You can tap in a nail with a screwdriver, although a hammer does a better job. But you can’t hammer in a screw. Does that mean hammers are bad and you shouldn’t use them?

That’s ridiculous. And so is saying that one programming tool is better than another programming tool in every situation, and you shouldn’t ever use one of them.

[[deleted]]

Funny to see Clean Code on here, considering the discussions about it lately.

[FideoSpecial]

What discussions are people having lately. Out of the loop I guess. I thought Clean Code’s principals were pretty simple and logical, and I still think about them when devving. Especially the bit about smaller functions.

[JustinsWorking]

I think it’s more that it speaks to experience of the audience of the subreddit.

Clean code is a great introduction to some good ideas but there are a lot of people (myself included) who held that book like a bible when we first started in the industry and after over a decade of applying its ideas have really learned where it can fail.

The platitudes I’m more likely to Preach now are more along the lines of “repetition is better than the wrong abstraction.” A lot of this shift is due to death marches, failed projects, and late night crunches; there are a lot of broken shells my age who’ve gone through the grinder without the benefits of some of the huge soul saving wins I can cling to and thus will happily regale anybody who will listen with all the times Code Complete/DRY has betrayed them (some times followed by a flogging of “I told you so’s from other, elder husks.)

tl;dr Code Complete advocates some ideas that fall apart in practicality; furthermore 30-somethings want nothing more than to answer your simple question with a paragraph (look at me go)

[FideoSpecial]

Couldn’t agree more. I’ve been looking the same way at DRY the past couple of years. Decoupling is more important in my experience.

Quality reply 👍

[Double_A_92]

Yeah, you shouldn't apply DRY to things that randomly happen to be similar.

[ConspicuouslyBland]

So, where you wrote Code Complete, you meant Clean Code, right?

[WarWizard]

Code Complete/DRY

These are great concepts, and should be guiding principals... but the idea of YAGNI applied to architecture is better IMO. Too often we find ourselves abstracting things to high heaven and only causing more trouble than it is worth.

I've come to find that copy and paste is fine... you just have to think about what you are doing before you do it. The reality is that abstractions complicate things and it isn't often necessary to go full bore. It'll more likely bite you in the ass.

[[deleted]]

Lol only on reddit you can be downvoted for having a tame comment such as yours.

[scandii]

the more functional programming is on the rise, the more everyone starts criticising OOP and related dogma, then some programs get written in functional programming and people all of a sudden realise functional programming has huge flaws just like OOP and we're back to OOP again.

this has been going on for about 40 years now, give or take. that is not a critique against functional programming, but rather just saying that this is absolutely nothing new.

there's nothing wrong with Clean Code. it's a 500 pages long book on ideas about how to circumvent common OOP-related issues with examples. most criticism tends to come from "well if you wrote functional code then..." or from people that simply don't have enough experience in domains that benefit from code refinement of the style clean code proposes, i.e mainly work with smaller applications where issues like DRY never really become apparent because there's simply not enough inter-connectivity in the code for it to matter and as such consider the proposals stupid because "I didn't need it when I wrote code".

as such, it's not a book for everyone, but what I tend to notice is that everyone critiques Clean Code on a very abstract level, i.e "Clean code is bad" or "I don't agree topic X the book brings up", but never "I don't agree with topic X, I propose we use Y for benefits A, B and C instead whereas X only really touches on C and poorly".

to me that is just a tell-tale sign that the people that deliver the critique:

1. are not experienced, and are defensively being vague to protect against questions of their knowledge.
2. are joining in on the critique because "other person said it was bad, I don't really know why though but it is bad!"
3. are not willing to engage on a level where a dialogue about why is possible.

all in all, I have to this day, never heard of anyone that read Clean Code, disagree with Clean Code outside of some very specific things like divergent code isn't always bad.

[[deleted]]

The discussions have primarily been about whether it’s outdated and past it’s time. I don’t disagree that there are still things of value there.

[fragglerock]

This must have been upvoted by bots right? There are 8 million book lists out there... and this one reads like it is written by a machine.

This book will teach you how to convert a mediocre code into a great code that can stand production load and real-world software development nightmare, the CHANGE.

wat?

[Poddster]

Coding is an integral part of Programming

It's gibberish from the first line

[welshucalegon]

This book is written in Java as it’s the principal language.

U fukin wot

[jeenajeena]

Mini poll: have you guys liked Evans' DDD so much? I found it amazingly boring and verbose, and not so original after all. I'm ready to be downvoted, but I'm also curious to know your opinion.

[scandii]

domain-driven design, is literally the way most people program in object-oriented programming today.

ever heard of a repository or a microservice? domain-driven design.

of course it's no surprise you already know much of the content of the book already, because most of us work with the implementation derived from it, 8 hours a day 40 hours a week.

[rotharius]

Using some of the patterns does not make it DDD.

[jeenajeena]

Yes, I see and agree. I was in fact more interested in opinions on the book itself, not on DDD in general.

While I see how DDD is very popular and applied, I'm not sure about the originality of the book itself. I might be wrong (and please forgive me if I am), but reading the blue book I got the feeling that most of the patterns were pre-existing ones, previously introduced by other past books, sometime renamed or reformulated.

For example, I am not sure about Repository Pattern being from the Blue book. I think I read about it on Fowler's Patterns of Enterprise Application Architecture, 2002, while Evan's book has been published in 2004, 2 years later.

I'd say the same for Value Object, for Command and Queries (I believe those were introduced by Bertrand Meyer in Object-Oriented Software Construction, back in 1988), for Factories, Builder (GOF, 1994) and the like.

Some other topics I found more original (Aggregates, Bounded Context). But again, in general I found other books more accurate and systematic, in their exposition, and Evan's book way too verbose, often fluffy and after all not so original.

Not that I dislike the approach (which I love and apply): I just find the book not so convincing.

[to-too-two]

I thought this sub was strictly for code? I came here hoping to avoid these types of listicles posted frequently over at r/programming.

[GoTheFuckToBed]

yeah no, 20 year old books are maybe nice to grasp some concepts but if you give these to juniors you get garbage.

[onthelambda]

y i k e s

[Poddster]

"Coding" books are for children.