Those who know, know.
But is it rewritten in Rust?
It’ll be rewritten in mdBook
Closure! (I don’t think so, not many programmers like reading/writing functional code. But it is his current favorite language, so, who knows?)
I should get to work on my opus, “Dirty Code”
Inside I’ll reveal all my secrets like: not writing tests, not documenting anything, putting the whole app into a single python file, object-disoriented relational mapping, obscure SQL tricks, unobscure no-sql tricks, and more!
object-disoriented
I’ll steal this to shit talk about code; until git blame points to my past self
Github, but it’s afraid of commitment, it just wants to spoon.
Just make sure the first chapter is dedicated to spaghetti, and contains various GOTO statements telling where the reader where to go shove it and other obscenities.
I hope your book won’t have a table of context and those stupid indexes. If they read it, they should know where you mention topics, right? Tables of contents considered harmful! /s
I like “how to build APIs you won’t hate”.
I hope the tricks are only supported on kafka’s ksql.
I read a book like this once! It was like, “how to code badly.”
It was actually kinda fun.
I’m of the opinion that Uncle Bob did some massive damage to software development as a whole with that book.
With that said, this is genuinely funny.Agreed. I found that many developers, in the pursuit of clean code, lost slight of some of the fundamentals principles of good code. I found that people were eschewing readability and modularity and calling it clean code.
Clean code became the target, not the underlying principles and the reason why we needed clean code in the first place. It became an entirely new thing that aided in producing some of the worst code I’ve read.
Oftentimes, when devs talk about “clean code” it’s a red flag for me in hiring. Some of the worst devs I’ve worked with have been clean code evangelists.
I’m beginning to feel we’re no longer talking about Clean Code being bad, but about people following ideas they don’t understand, which is not related or caused to any particular book.
I think its less about not understanding and more that these concepts only work in unrealistic scenarios that aren’t real. It’s the same with Agile. They never address the actual issue and try to work around them which never works.
I’d love to learn what that damage was. I often see complaints (sometimes also involving tech choices) but usually they’re not specific, so I’m always left wondering.
I’ve found it’s mostly two things: readability (ironically) and performance. I’ll describe a few crude examples, but I won’t get too much into specifics, otherwise I might as well write another book myself.
The performance part is simple: its excessive reliance on polymorphism and the presence of several levels of abstraction just doesn’t allow for good code generation. I’ve seen 10x+ performance improvements by dropping all of the above, with often minimal loss in readability; on the contrary, oftentimes the code became more readable as well.
The readability part is harder to explain; not only because it depends on the codebase and the problem at hand, but also on the coding style each programmer has (though in my opinion, in that particular case it’s the programmer’s problem, not the codebase’s).
I like to think of codebases as puzzles. To understand a codebase, you need to piece together said puzzle. What I’ve found with Clean Code codebases is that each piece of the puzzle is itself a smaller puzzle to piece together, which isn’t ideal.Functions
They should be small and do one thing
I generally disagree, not because those ideas are wrong, but because they’re often too limiting.
What often happens by following those principles is you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together. Your code loses locality and, much like with CPU cache locality, your brain has to do extra work to retrieve the information it needs every time it needs to jump somewhere else.
It may work for describing what the code does at a high level, but understanding how it works to make meaningful changes will require a lot more work as a result.Don’t repeat yourself
Once again, it makes sense in principle, but in practice it often creates more problems. I agree that having massive chunks of repeated code is bad, no questions about it, but for smaller chunks it may actually be desirable in some circumstances.
By never repeating code, you end up with functions that are over-parameterized to account for all possible uses and combinations that particular code snippet needs to work with. As a result, that code becomes more complex, and the code that calls it does too, because it requires you to know all the right parameters to pass for it to do the right thing.Exceptions
Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of.
The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development, and they should be treated as such.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.Classes, interfaces and polymorphism
I have lots of gripes with object orientation. Not everything needs to be an object, not everything needs to be polymorphic. There’s no need to have a
Base64Decoder, much less anIBase64Decoderor anAbstractBase64Decoder. Base64 only works one way, there are no alternative implementations, a function is enough.I’m a lot more on the data oriented side of the isle than the OO one, but I digress.
Object orientation can be good in certain contexts, but it’s not a silver bullet.Encapsulation for the sake of it
Let’s say you have something like this:
class Point { public float X, Y; }With the Clean Code approach, it magically becomes:
class Point { private float x, y; public float get_x() { return this.x; } public float get_y() { return this.y; } public void set_x(float x) { this.x = x; } public void set_y(float y) { this.y = y; } }Why? Who the hell knows. It makes absolutely no tangible difference, it only makes your code longer and more verbose. Now, if a value needs validation, sure, but oftentimes this is just done regardless and it drives me insane.
Abstract classes for everything!
- “You’ll never know when you’ll need to add another implementation, right?”
- “You don’t need to know the underlying implementation”
The problem with wanting to create the most generalized code in advance is that you end up stuck in abstraction hell.
You may as well not need the ability to have arbitrary implementations, but now you need to plan for that.Not only that, but it also makes reasoning about your code harder: how many times have you had to step through your code just to figure out what was being executed | just to figure out what particular concrete class was hiding behind an abstract class reference?
I myself, way too many, and there was often no reason for that.Also, the idea that you shouldn’t know about the implementation is crazy to me. Completely encapsulating data and behaviour not only makes you miss out on important optimizations, but often leads to code bloat.
There’s more but I’m tired of typing :)
Take a look at these if you want more info or someone else’s view on the matter, I wholeheartedly recommend both:
Functions should be small and do one thing […] you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together
I believe you have a wrong idea of what “one thing” is. This comes together with “functions should not mix levels of abstraction” (cited from the first blog entry you referenced). In a very low-level library, “one thing” may be sending an IP packet over a network interface. Higher up, “one thing” may be establishing a database connection. Even higher up, “one thing” may be querying a list of users from the database, and higher up yet again is responding to the
GET /usershttp request. All of these functions do ‘one thing’, but they rely on calls to a few methods that are further down on the abstraction scheme.By allowing each function to do ‘one thing’, you decompose the huge problem that responding to an HTTP request actually is into more manageable chunks. When you figure out what a function does, it’s way easier to see that the function
connectToDbwill not be responsible for why all users are suddenly called"Bob". You’ll look into the http handler first, and if that’s not responsible, intogetUsersFromDb, and then check whatsendQuerydoes. If all methods truly do one thing, you’ll be certain thatcheckAuthorizationwill not be related to the problem.Tell me if I just didn’t get the point you were trying to make.
Edit: I just read
Martin says that functions should not be large enough to hold nested control structures (conditionals and loops); equivalently, they should not be indented to more than two levels. He says blocks should be one line long, consisting probably of a single function call. […] Most bizarrely, Martin asserts that an ideal function is two to four lines of code long.
If that’s the standard of “doing one thing”, then I agree with you. This is stupid.
Yeah that was essentially what I was referring to (referring to your edit).
I generally dislike stuff like (crappy example incoming):
void do_stuff(int count, bool cond) { function1(count); function2(b); function3(); } void function1(int count) { for (var i = 0; i < count; i++) { ... } } void function2(bool cond) { if (cond) { ... } else { ... } } void function3() { ... }I’m not a fan of this kind of code fragmentation.
If all those actions were related and it could have been just one thing, retaining a lot more context, then it should be one function imo.
If by not splitting it it became massive with various disconnected code blocks, sure, but otherwise I’d much prefer being able to read everything together.If splitting the functions required producing side effects to maintain the same functionality, then that’s even worse.
Huh, I really like code like that. Having a multi-step process split up into sections like that is amazing to reason about actual dependencies of the individual sections. Granted, that only applies if the individual steps are kinda independently meaningful
To adapt your example to what I mean:
Baz do_stuff(int count, boolean cond) { Foo part1 = function1(count); Bar part2 = function2(cond); return function3(part1, part2); }This allows you to immediately see that part1 and part2 are independently calculated, and what goes into calculating them.
There are several benefits, e.g.:
- if there is a problem, you can more easily narrow down where it is (e.g. if part2 calculates as expected and part1 doesn’t, the problem is probably in function1, not function2 or function3). If you have to understand the whole do_stuff before you can effectively debug it, you waste time.
- if the function needs to be optimized, you know immediately that function1 and function 2 can probably run in parallel, and even if you don’t want to do that, the slow part will show up in a flame graph.
It really depends on the context frankly. I did say it was a crappy example ;)
Try to read this snippet I stole from Clean Code and tell me if it’s readable without having to uselessly jump everywhere to understand what’s going on:public class SetupTeardownIncluder { private PageData pageData; private boolean isSuite; private WikiPage testPage; private StringBuffer newPageContent; private PageCrawler pageCrawler; public static String render(PageData pageData) throws Exception { return render(pageData, false); } public static String render(PageData pageData, boolean isSuite) throws Exception { return new SetupTeardownIncluder(pageData).render(isSuite); } private SetupTeardownIncluder(PageData pageData) { this.pageData = pageData; testPage = pageData.getWikiPage(); pageCrawler = testPage.getPageCrawler(); newPageContent = new StringBuffer(); } private String render(boolean isSuite) throws Exception { this.isSuite = isSuite; if (isTestPage()) includeSetupAndTeardownPages(); return pageData.getHtml(); } private boolean isTestPage() throws Exception { return pageData.hasAttribute("Test"); } private void includeSetupAndTeardownPages() throws Exception { includeSetupPages(); includePageContent(); includeTeardownPages(); updatePageContent(); } private void includeSetupPages() throws Exception { if (isSuite) includeSuiteSetupPage(); includeSetupPage(); } private void includeSuiteSetupPage() throws Exception { include(SuiteResponder.SUITE_SETUP_NAME, "-setup"); } private void includeSetupPage() throws Exception { include("SetUp", "-setup"); } private void includePageContent() throws Exception { newPageContent.append(pageData.getContent()); } private void includeTeardownPages() throws Exception { includeTeardownPage(); if (isSuite) includeSuiteTeardownPage(); } private void includeTeardownPage() throws Exception { include("TearDown", "-teardown"); } private void includeSuiteTeardownPage() throws Exception { include(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown"); } private void updatePageContent() throws Exception { pageData.setContent(newPageContent.toString()); } private void include(String pageName, String arg) throws Exception { WikiPage inheritedPage = findInheritedPage(pageName); if (inheritedPage != null) { String pagePathName = getPathNameForPage(inheritedPage); buildIncludeDirective(pagePathName, arg); } } private WikiPage findInheritedPage(String pageName) throws Exception { return PageCrawlerImpl.getInheritedPage(pageName, testPage); } private String getPathNameForPage(WikiPage page) throws Exception { WikiPagePath pagePath = pageCrawler.getFullPath(page); return PathParser.render(pagePath); } private void buildIncludeDirective(String pagePathName, String arg) { newPageContent .append("\n!include ") .append(arg) .append(" .") .append(pagePathName) .append("\n"); } }That’s what I was talking about.
The “Don’t repeat yourself” mantra is also used with documentation, this leads to documentation which you first have to read and learn unless you frequently want to step into issues of the documentation assumed you read prior parts and didn’t just searched how to do XYZ.
Thank you for linking the blog posts. They are a really good deterrent from Clean Code. I once thought I’d read it, but Fowler’s advice really is stupid.
In case you’re wondering why I replied three times: “Do one thing” :)
The “Don’t repeat yourself” mantra is also used with documentation, this leads to documentation which you first have to read and learn unless you frequently want to step into issues of the documentation assumed you read prior parts and didn’t just searched how to do XYZ.
Also while I used the more clean code oriented XML DOM implementation for my D XML parser (or at least copied such code as it was abandoned by its original creator), I planned a much simpler system for my SDLang parser. While everything originates from the
DLElementabstract class, I didn’t go overboard with the interfaces, etc.Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of. The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development
They may be a part of software development, but they should not be common during the normal execution of software. I once read the hint, “if your app doesn’t run with all exception handlers removed, you are using exceptions in non-exceptional cases”.
Throwing an exception is a way to tell your calling function that you encountered a program state in which you do not know how to proceed safely. If your functions regularly throw errors at you, you didn’t follow their contract and (for instance) didn’t sanitize the data appropriately.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.
I disagree here. You can always ignore an error return value and pretend that the “actual” value you got is correct. Ignoring an exception, on the other hand, requires the effort to first catch it and then write an empty error handler. Also (taking go as an inspiration), I (personally) find this very hard to read:
res, error = try_something() if error { handle_the_error(error) return_own_error() } res2, error2 = try_something_else(res) if error2 { handle_other_error(error2) return_own_error() } res3, error3 = try_yet_something_else(res2) if error3 { handle_the_third_error(error3) return_own_error() } return res3This code mingles two separate things: The “normal” flow of the program, which is supposed to facilitate a business case, and error handling.
In this example, on the other hand, you can easily figure out the flow of data and how it relates to the function’s purpose and ignore possible errors. Or you can concentrate on the error handling, if you so choose. But you don’t have to do both simultaneously:
try { res = try_something() res2 = try_something_else(res) res3 = try_yet_something_else(res2) return res3 } catch (e) { // check which error it is and handle it appropriately throw_own_exception() }Also (taking go as an inspiration), I (personally) find this very hard to read
Agreed. Go’s implementation of errors as values is extremely noisy and error prone. I’m not a fan of it either.
You can always ignore an error return value and pretend that the “actual” value you got is correct.
Then that’s a language design / api design issue. You should make it so you cannot get the value unless you handle the error.
I’m of the opinion that errors should be handled “as soon as possible”. That doesn’t necessarily mean immediately below the function call the error originates from, it may very well be further up the call chain. The issue with exceptions is that they make it difficult to know whether or not a function can fail without knowing its implementation, and encourage writing code that spontaneously fails because someone somewhere forgot that something should be handled.The best implementation of errors as values I’ve seen is Rust’s
Resulttype, which paired with the?operator can achieve a similar flow to exceptions (when you don’t particularly care where exactly an error as occurred and just want to model the happy path) while clearly signposting all fallible function calls. So taking your example:try { res = try_something() res2 = try_something_else(res) res3 = try_yet_something_else(res2) return res3 } catch (e) { // check which error it is and handle it appropriately throw_own_exception() }It would become:
fn do_the_thing() -> Result<TheValue, TheError> { res = try_something()?; res2 = try_something_else(res); res3 = try_yet_something_else(res2)?; } match do_the_thing() { Ok(value) => { /*Do whatever*/ } Err(error) => { /*handle the error*/ } }The difference is that you know that
try_somethingandtry_yet_something_elsemay fail, whiletry_something_elsecannot, and you’re able to handle those errors further up if you wish.
You could do so with exceptions as well, but it wasn’t clear.The same clarity argument can be made for
nullas well. AnOptiontype is much more preferable because it forces you to handle the case in which you are handed nothing. If a function can operate with nothing, then you can clearly signpost it with anOption<T>, as opposed to justTif a value is mandatory.Exceptions are also a lot more computationally expensive. The compiler needs to generate landing pads and a bunch of other stuff, which not only bloat your binaries but also prevent several optimizations. C# notoriously cannot inline functions containing
throws for example, and utility methods must be created to mitigate the performance impact.The best implementation of errors as values I’ve seen is Rust’s Result type
You’re talking Monads, baby!
I generally agree, but there are some things that are oversimplified. Sure a point(x, y) can have public attributes, but usually business objects are a bit more complex: insurancePolicy, deliveryRoute, user, etc. Having some control over those is definitely something you want to implement, at the cost of some boilerplate.
Oh for sure. I have nothing against getters and setters when they’re justified, but in the case of bare fields with no validation like that example it’s just annoying.
Also stuff like this just grinds my gears (oversimplified example again):class IntegerAdder { private int a, b; public IntegerAdder(int a, int b) { this.a = a; this.b = b; } public int get_sum() { return a + b; } }Just make it a bloody function.
You may say it’s silly, but I’ve genuinely found code like this in the wild. Not that exact code snippet of course but that was the spirit.
lol
New edition is just an incoherent rant about the “woke mind virus” trying to destroy him for “just saying what everyone is thinking”.
This! Uncle Bob is a garbage person. Used to really respect him, but F that guy.
I didn’t knew anything about him but I respect everyone who doesn’t shut up in front of the woke agenda and propaganda.
Dude fuck off
And what would you say is that “woke agenda and propaganda”?
“Code optimization is a cultural Marxist conspiracy!”
I’m a programmer since the 80s, who is this guy?
He wrote for example the books Clean Code and Clean Architecture which are IMO opinion really good books although I don’t agree with every point he makes.
Some really good points he makes are for example:
- Functions that only do one job
- Testing makes refactoring easier
- The standard SOLID OOP stuff.
- Tech debt is bad
- Abstraction and encapsulation is good and allows developers to interact with the code on a higher level in terms of actions instead of writing verbose stuff. Essentially saying less code leads to less bugs
- Insulate yourself from change
- Duplication is bad
- Two use cases that are very similar is not duplication and common code shouldn’t be factored out.
- Don’t mix high level code with low level.
- Build solid Entity classes to model the data and their interactions.
- Don’t write multithreaded code if you don’t have to.
- If you have to do your best to write it so they don’t share memory.
Those comes with examples. He’s a tad bit overly idealistic in my opinion. These books fail to mention a couple of things:
- Refactoring is expensive and the cost is often not justified.
- Premature abstraction is the absolute devil
- You don’t need to insulate from things that are very unlikely to change (like going from SQL to Document DB)
- Less changes also lead to less bugs.
- Too much emphasis on functions being few lines of code instead of just being simple.
All in all though, very solid books. I read Clean Code in university and Clean Architecture in my first job and it really helped me wrap my head around different ways to solve the same problem. Excellent ideas but it’s not the holy truth. The only reason I remember all of these points is that I encountered all of them on the job and saw the benefit.
In my opinion new programmers should read it and take inspiration. Craftsman level developers should criticise and maybe pick up a few brain concepts to sort some concepts out in their brain. Experts will get little benefit though.
The consultancy I used to work for in the late 90s would have crucified any developer that didn’t write “a data abstraction layer that allows you to pop off the original db and substitute a different one later”.
How many times in my 25 year career have I swapped out the database (and been thankful for such an abstraction layer)? 0 times.
In my 15 year career? Dozens. Maybe low hundreds. Depends what you work on. Oracle is not making any friends lately and a ton of companies a whole-sale migrating to Postgres, MongoDB, DynamoDB or some of the NewSQL contenders. It’s like 50% of the projects I’m involved in. Results are generally positive, with some spectacular wins (x3000 acceleration or x1000 lower costs) and a few losses.
I am literally in the middle of swapping DynamoDB for a RDBMS.
The idea that you can abstract away such fundamentally different data stores is silly. While I hate doing it now, reworking the code to use relational models properly makes for a better product later.
It’s literally what an orm does, and it’s good enough for 80% of apps out there. Using it for the wrong purpose is what’s silly.
I see. It seems like you may be one of the people that try to coerce relational models into nosql stores like Dynamo.
Or course it’s possible. They even trick you into thinking it’s a good pattern by naming things “tables”.
But if you’re using Dynamo to its fullest an ORM is not going to be able to replicate that into a relational store without some fundamental changes.
Hence 80%.
Most apps out there are a CRUD with a thin layer of logic.
If you are in the 20% that needs real performance, an ORM is not gonna cut it, no matter what DB you have.
I’m going to suggest not using an ORM. I used three so far and it really likes to tell you what you can and can’t do when query builders can do the same thing by creating the SQL string for you. SQL is also very nice and easy (just parameterise all inputs to avoid the SQL injection)
While he advocates for it, that’s also a point that Martin brings up multiple times when he talks about his project “fitnesse”.
Basically saying that they left it open how stuff can be saved, but the need has never arisen to actually pivot to a different system.
I generally agree with the idea that code should be as simple as it can be to accomplish the goal of the code… I just haven’t been convinced that Clean Code is the way to get there, necessarily. The book does contain some good advice , to be sure, but I wouldn’t call it universal by any means.
I also think TDD is a very optimistic strategy that just doesn’t match up with reality terribly often.
Actually, I think that’s what confuses me the most about all of Uncle Bob’s books. I’ve read a couple of them and thought, “All this sounds great but real world development just doesn’t seem to work that way.” Like, all of his advice is for best case scenarios that I certainly haven’t encountered in my career.
I say confusing, because surely he’s been in the profession long enough to have seen the disconnect between what he’s preaching and real life, right???
Yeah, I 100% agree. For small projects most of the principles don’t matter as much because the complexity is just not there. For big projects you actually need to take a big ass tech debt loan to actually get things done on time and on budget.
The testing aspect I’m not as sold on either. I enjoy tests sometimes but they also come with increased development and maintenance cost. He emphasises unit tests but I’ve found that a few integration tests that use API calls to simulate a use case gets you most of the way there.
That being said I’ve seen raw HTML email string with hardcoded values in a 2000 line method that relies heavily on if statements. That one method probably breaks around 10 of his rules and I absolutely hate it. Very hard to add features to if you can imagine and incredibly noisy and hard to debug. Shouldn’t be like that but it is. I wouldn’t apply all of Bob’s rules but I would refactor it into a service with clear boundaries so I don’t have to deal with the function having “local globals” if you know what I’m getting at.
Wrote a couple famous books about Clean Code, Architecture, Test Driven Development, OOP, and Agile.
he’s a programmer since the 70s
Robert C. Martin
Your long lost son, perhaps
There’s a multi-part talk on YouTube if you want to hear all about it.
I was a big Uncle Bob fan and still really like the Clean Code book. But he trashed his public reputation so I doubt this 2nd edition will do very well.
Is there a TL;DR if I don’t know who this is?
Basically he is an old man/ software engineer who’s famous for his philosophy of coding.
Any context on him “trashing his reputation”?
He made some political remarks on Twitter that many people didn’t like.
I am also a big fan of his books, especially Clean Code. His (far-)right opinions are bad, but should be (to some extent) viewed separately from his technical standpoints. However, even then a new edition would not perform well, there are too many people hating Clean Code (without really understanding its message/just ranting without having read it). But I was very surprised that ThePrimeagen recently interviewed his “opponent”, it was very nice to watch.
i am genuinely waiting for it. read the first one almost 10 years ago and it gave me a good start into my programming journey.
even if this second version won’t bring in anything new for me, I will be glad to consume it
Is this the book that introduced SOLID?
no, but the concept was introduced by uncle Bob.
Working in Ruby did 10x more to help me write clean code than reading Clean Code ever did.
Many of the lessons drilled into me with Ruby (keep a consistent style, tests are cheap, keep your methods relatively small where possible, reduce nesting where possible) carry over nicely into other languages without needing to go through any OO bullshit.
IMO, the best lesson around Clean Code is this: you’re not clever, write obvious code that works with as few tricks as possible.
I find this to be true for every new language I try out. Since every language has a different way of doing things and gives me a new perspective, in the long run they all end up improving my programming style as a whole. I always end up integrating the best parts of each into my next project when possible.
Experience will always be more valuable than any set of rules these kind of books tout as “the way things are meant to be done”.
oh no somebody stop please him
Ooh la la 😏
Cleaner Code.
Waiting for him to finish the trilogy with Cleanest Code
cleanerer code. gotta leave room for a fourth book: clean code and the crystal skull
Clean Code With a Vengeance.
The bit of Clean Code that I read was unimpressive, but Clean Architecture was amazing. I view that book as required reading for anyone who wants to write code professionally. If Uncle Bob hasn’t realized that his coding style is worse than alternatives, I do not see how a second version of the same bad ideas is going to do well.
Glad I didn’t read it.
There are no inherent “rules” in software development. These books are useless and a waste of time. They offer nothing but CS Dogma and are actually against freedom of expression.
Rules of thumb can be very useful for a relatively inexperienced programmer, and once you understand why they exist you can choose to ignore them when they would get in the way. Clean Code is totally unhinged though
The problem is that a lot of people don’t understand when to ignore the rules and just stick with them forever.
We had a developer once that always said KISS KISS KISS whenever we pointed out that her functions are working but not reusable, so she wrote 20 functions that all did the same thing, but with slightly different parameters. And that’s just one of the examples
CS often requires working in teams, and working it teams is often more efficient if you have some shared approaches.
There are no inherent “rules” to language, either, but when you don’t followthemthingsgetmessyandyou’reannoyingforeveryoneelese.
Those of you who red and liked clean code (I did too), what’s your next best recommendation as a book? The pragmatic programmer?
Thanks for the warning
