The Clean Coder: A Code of Conduct for Professional Programmers

Category: Programming
Author: Robert C. Martin
All Hacker News 11
This Month Stack Overflow 1


by Andy101493   2019-07-21

i’m sorry for this situation, a lot of others answered this question very well. i just want to add that there’s a book called The Clean Coder that talks about this side of being a software engineer, I’ve personally found it an excellent and relevant read that sheds a lot of light onto this side of the job

by sastarbucks   2019-07-21

First off starting with some non financial advice stuff

It seems you have things sorted from a technical ability perspective but when it comes down to requirements and understanding what is needed that is something you might fall down on.

This happens a fair bit to be honest with you as systems can get a lot more complex and you are at the mercy of any business analysis which might be done, so as you say you can deliver "it" if you know what "it" is, that comes from experience but can be learnt in other ways.

Couple of book links:


Now financial questions, I would adjust your salary expectations, but it might not be out of the question for you to find something in that area especially depending on how commutable Manchester is, but there are places everywhere which do this kind of work, just might find competition is different.

by anonymous   2019-07-21

The main advantage is: it's easier. As in, it's the simplest thing to do, because as a result, you have no application architecture. You're grasping at things from everywhere and anywhere because you have no idea how to get them otherwise, and this makes for very poor maintainability. Guess what happens 5 years down the line with this sort of codebase? Massive legacy technical debt, and it's very likely your developers aren't using Object Oriented Programming - more likely shoving procedural code in classes.

I'm not going to bother explaining about global state, because there's already a fantastic answer that already exists on programmers. A small excerpt:

Very briefly, it makes program state unpredictable.

To elaborate, imagine you have a couple of objects that both use the same global variable. Assuming you're not using a source of randomness anywhere within either module, then the output of a particular method can be predicted (and therefore tested) if the state of the system is known before you execute the method.

However, if a method in one of the objects triggers a side effect which changes the value of the shared global state, then you no longer know what the starting state is when you execute a method in the other object. You can now no longer predict what output you'll get when you execute the method, and therefore you can't test it.

You'll find some developers do this purely out of laziness or a lack of knowledge / understanding of the basic concepts of SOLID. If you access global state (like the database), then the beautiful, isolated class you are currently writing that theoretically can be handed off to any other developer, and also tested in it's own right, is now coupled to this object somewhere off in the clouds.

As well as the above, you're making a liar of your object API. Each object should, via it's constructor / method signatures, specify exactly the required external objects with which it requires to function. This allows:

  • Your object to have a definitive API for it's usage
  • Future developers can see exactly what is required for this object to function from the constructor / method signatures
  • Everything passed in via Dependency Injection (the posh word for passing in parameters, basically), can be 'mocked out' for testability
  • Developers don't need to read through your code to find out what other objects are required, because of point 2
  • You aren't accessing something that can be changed by something else, somewhere else, and make debugging a nightmare

Your code should not be brittle. You should be completely confident in making changes somewhere in a massive codebase, without worrying about breaking something somewhere else. Your unit tests will cover this. I highly recommend reading The Clean Coder as it elaborates on some of these concepts.

AlmaDO has a picture of a good image about Singletons, which are basically objects that return a single instance of an object, like a database or logger. So if you request a new database from it, you either get a new one or just get back the one that already exists. In the traditional request / response / dead context, this is completely unecessary. If you're having a very long-running process, maybe this might be necessary, especially in other languages, but as a general rule of thumb in PHP; unless you're running a PHP web socket server or similar, DI is a much better way to go for maintainability.

This is exactly the same as calling StaticObject::Database, again - something that can be accessed from anywhere.

This is a really good post on Singletons in PHP, and how they're not at all needed - that post also has a lot of useful links in it further down.

Basically - don't be lazy and grasp SOLID. There's a reason it exists, and it's certainly not just for PHP, either. The main reason people do it is because they don't know better and it's easier, and easier isn't always the best way.

Also, a few additional clarifications. We don't have "models". We have a model, which is a layer. This is a massive misinterpretation of 'MVC', which we don't even actually have in PHP ('classical mvc'). We have the separation of concerns and that's it.

  • Your "models" are likely, services, domain objects, entities. More info on what the model is

  • Your user should not know about the database. It should be an Entity. Active Record Pattern is not the way forward. Take a look at DataMapper. Your repository would use the database object and return an array of User objects. Contextually as well, a user having access to the database makes no sense.

  • Most frameworks do not work by having access to the database in entities - this isn't PHP 4 any more, it's progressed a lot since then ;-) I highly recommend moving away from CakePHP (it's not MVC in any way) and take a look at a framework like Symfony, which still has it's flaws - knowing the flaws of your chosen framework is very important

by ArnoldRudolph   2018-11-10

> Anyone have advice for "theory people" who can't code all that well starting out in industry?

Casually read one of these (which is how to perform technically):

All you really need is the above info on how to code well and write robust modular code that is tested, the rest is just doing whatever code style you see in your codebase. It also will serve you over any language at any job company... for the most part.

Then consider reading this after for how you should be as a person doing programming (which is non technical important information):

You will pick up frameworks and knowledge of the language as you go, no need to stress over it.

Spend the first year doing front and backend, then after 6-12 months (starting from day 0 of work) specialize in the area you find interesting, such as a framework, or databases, or backend, or microservices, or whatever you find interesting.

by PaulSolt   2018-11-10


  1. You are more than capable of getting a job doing iOS development
  2. It takes effort and hard work beyond the course
  3. Start publishing a blog and get your name out there on the web, share what you're doing, even if it's just on as a Readme
  4. Learn how to use Git and work in a team
  5. Show up every day and code, or share what you're learning

BUT you need to change your mindset (Read: Mindset , SoftSkills , and The Clean Coder )

by restlessapi   2018-11-10

I agree with all the top comments, but I want to add something else. Two things really.

First, it is ALWAYS harder to read code than to write code. Dont let that get you down. Like any skill, you get better at it. You learn what classes and methods dont matter, and where to focus your attention.

Second, you need to be aware that the code youre reading, might be garbage. What I mean is, the code might be so terrible, that no one could reasonably understand it. Ive seen production systems at big name companies that are utter garbage. I would strongly recommend reading the book The Clean Coder to help your understanding with whether or not the code is terrible or not.

by mkirschner   2018-09-01
I have a feeling you are selling yourself short (and being overly hard on yourself, something I'm well acquainted with but more easily recognize in others).

Based on your technical focus, you're clearly (in my opinion) way above the "average" developer in technical ambition and appreciation for computer science.

A bit of unsolicited advice: If you organize your preparations around the concept of providing value to a prospective employer, rather than merely getting hired to write code, then I bet your outlook will change. One book (and definitely not the only one) that can help with that is Bob Martin's The Clean Coder: A Code of Conduct for Professional Programmers:

by robmcm   2017-08-19
You shoudl read Robert C Martin's, "A clean coder".
by oblique63   2017-08-19
Check out the guys over at 8th light:

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.




by distracted828   2017-08-19
When you start looking for jobs, only join a company that does TDD and pair programming. Ask about this in interviews.

TDD helps you break down tasks and, when you lose focus, you can regain it by re-running your test suite and seeing which test fails.

Pair programming help you because:

- They'll tend to have closer to a 10-6 schedule rather than encouraging you to stay up late.

- When talking through the problem with a colleague, you break the task down more easily and get through whatever mental block you have.

- You can't get distracted when someone else is right there.

It may be harder to find a company that does this because many folks think that they can move faster if they build something the "quick and dirty" way. "Quick and dirty" doesn't exist for you. "Quick and dirty" means that the project either fails outright or is one that you start procrastinating on until you get fired.

Take a look at the book The Clean Coder ( It talks about procrastination and how to overcome it.

For a practical introduction to TDD, I'm a fan of Test-Driven Web Development with Python. It is Free.