How to Write Clean Code that Reduces Headaches

Clean code is an elusive concept due to the varying opinions of developers.

However, I believe that there are few common points that most developers (if not all) can agree on.

I will be discussing both the common points and also my own opinion on what clean code is.

You might be asking:

Why write a post on clean code when so many highly acclaimed people such as Uncle Bob wrote books on this topic?

Well, my answer is simple:

I am highly passionate about writing clean code, because nothing frustrates me more than code that reads like code.

You dig right?

By finding these common grounds, the discerning and pragmatic programmer can write code that not only works like a well-oiled machine, but also reads like a well-written book.

What is Maintaining code or Software Maintenance?

Most programmers spend more time maintaining an existing code base than writing new code.

How do you define software maintenance (or maintaining code)?

Good question. I personally define maintaining code as refactoring I.e. changing the source code without modifying its features. AKA preserving the features and user experience of an existing application or system.

It also involves

  • fixing bugs.
  • re-designing an existing part of the program/system.
  • optimizing the physical performance of the system.

I derived this personal definition from the word “maintenance”. According to merriam-webster dictionary, the very definition of the word maintenance is

 to keep in an existing state (as of repair, efficiency, or validity) :  preserve from failure or decline

However, the difference between maintaining something other than software (e.g. a building) and maintaining software that is we, as software developers, want to and make efforts to IMPROVE the code-base, not just simply preserve its current state.

The golden rule in software maintenance or maintaining code is to preserve the user experience and its existing features.

Everything on the back-end AKA what is unseen, we are able to and should change if there is an opportunity to improve.

What do I mean by improve? It is improving the

  • Readability of the overall code-base.
  • Scalability of the system.
  • Performance of the system.

Scalability and performance may sound somewhat similar, but they are two unique beasts that should be kept separate. If you don’t understand the difference between the two, I suggest doing some research on your own.

Benefits of Writing Clean Code

Clean code minimizes the time spent reading and attempting to understand the code, which takes up a large portion of a developer’s day to day operations.

Writing clean code not only makes the job of software developers easier, it ultimately translates into reduced expenses for the business.

Imagine that you have a code base and your client asked you to add a new feature to the application.

If the code only takes 1-2 hours to navigate, analyze and extend to accommodate this new feature addition (I know this is unrealistic), as opposed to 10 hours, your business saved an entire day’s worth of a developer’s wage.

Although the actual monetary worth of reduced expenses is difficult to measure, due to the intangible nature and value of clean code, the effects of clean code (or lack thereof) will be felt by both the developers and the business.

It is like investing time, money and effort into the foundation of a building in order to make it sturdy. When the storm comes, that building will endure while those that did not place a high priority into the foundation crumble away.

Clean code almost always pays for itself in a matter of months (depending on the size and scale of your business or solution).

If you are determined to continue reading, I am assuming that I have convinced you that clean code is important and worth investigating.

I will now present to you, ways to write clean code that boosts productivity, and ultimately, makes the world a better place.

#1. Embrace the Clean Code Mindset

To write clean code and embrace the mindset of writing clean code, you first need to understand the cost of poorly written code.

Every programmer understands the importance of indentation. If you have been programming for at least six months, this is a no-brainer.

Lets take a look at some very simple code in JavaScript to explore this concept. Don’t worry, you don’t need to be a JavaScript developer to understand this example.

var userData = [
        userId: 1,
        name: "Sam Brown",
        memberSince: "2015-08-20",
        favoriteIceCreamFlavors: ["strawberry", "green tea", "cookies and cream"]
        userId: 2,
        name: "Michael Jackson",
        memberSince: "1990-08-20",
        favoriteIceCreamFlavors: ["chocolate", "mint", "rainbow sherbet"]

Now, let me remove some indentations.

var userData = [
    { userId: 1, name: "Sam Brown", memberSince: "2015-08-20", favoriteIceCreamFlavors: ["strawberry", "green tea", "cookies and cream"] },
    { userId: 2, name: "Michael Jackson", memberSince: "1990-08-20", favoriteIceCreamFlavors: ["chocolate", "mint", "rainbow sherbet"] }

The code immediately becomes less readable, but still somewhat readable. Lets compress the four line code snippet above into a single line code snippet.

var userData = [ { userId: 1,  name: "Sam Brown", memberSince: "2015-08-20", favoriteIceCreamFlavors: ["strawberry", "green tea", "cookies and cream"] }, { userId: 2,  name: "Michael Jackson",  memberSince: "1990-08-20", favoriteIceCreamFlavors: ["chocolate", "mint", "rainbow sherbet"] }];

At this point, you are now going to be saying WHAT THE?!?! Who would even write crappy code like this?

The example above highlights and exemplifies the very heart of writing clean code.

The heart of clean code is writing code that your target audience can read, understand, extend and modify smoothly.

If you observe the way human beings read text, most of us are trained to read from left to right, top to bottom.

If you tried reading that single protracted line of code above, you also probably noticed that we are bad at reading long text.

For most people, this will tire out the brain more quickly than reading out the same piece of code that is formatted properly.

As a developer who writes clean code, we want to make the job of our target audience easier. And of course, it is a no brainer that every person who maintains the code must, at one point, read the code, thus making readability a high priority.

Know your Target Audience

I think this is super important, so I am going to go all out here to make sure that I get this point through.

Generally, our target audience are other programmers. In another words, people who have been trained and are paid to write code.

This would be the big umbrella category, but in many of the cases, we can narrow that down to many different sub-categories. Such as:

  • JavaScript Developer.
  • Java Developer.

We can take this even further.

  • Junior Korean Java Developers
  • senior Korean Spring Java EE developers.

YES! If you want to write good code (and I hope that you do), you need to


It’s like writing a book or a thesis.

When writing a thesis, it is okay to use technical jargon and some big, sophisticated words, because your target audience are professors who have years and years of experience in that specific field.

However, if you use the same technical jargon in a written text addressed to elementary school students … let’s just say you will be responsible for wasting a lot of time and energy (and not just that of the students).

For example, let’s say that you are writing sample code for junior developers in Java. If you start getting all funky with meta-programming and using reflection to do some cool stuff at run-time guess what?

You are going to LOSE THEM!

No matter how clean and awesome you think your code is, if your target audience says otherwise, guess what?

Your code is close to worthless!

Your code is only valuable if your target audience can read, understand, modify and extend your code WITHOUT your intervention.

Identifying your target audience

To keep things simple, your target audience are programmers who will be maintaining the code that you write.

If you are writing code for a company, your code will be maintained by yourself and your co-workers.

If you are writing open source code, it can potentially be anyone around the globe. In this case, because you don’t have a personal relationship with people that you write for, just try to apply universal best practices that make the code easy to read and follow. This includes using the right naming conventions, making your code expressive, writing small, compact, single purpose code, etc.

Your ultimate purpose should be to write code that is easy to read, understand, extend and modify.

Therefore, when addressing a global audience, it is of utmost important to create a coding guideline so that everybody is on the same page.

I even recommend writing coding/style guides for companies because it gets developers that are new to your company up to speed and productive in a shorter amount of time.

Imagine if you have some areas of your Java code where variables are in camel case and other areas in pascal case.

I smell chaos.

If you are like me, you may be wondering if there was a specific purpose for naming a variable in pascal case.

Ask Questions

You might want to ask yourself some questions at this point.

While reading, if you think of any good questions to add to this list, please leave a comment and let me know! I would appreciate it tremendously :).

  1. What is the skill level of my current target audience? Am I above/below the average skill level of this audience?
  2. Is English their main language?

You might laugh at some of these questions I listed.

I currently work in Seoul, South Korea where English is not the main language.

Therefore, to write clean code, I need to gauge the English skill level of my target audience. I also need to get a little creative when naming my variables so that other developers understand.

This may even involve utilizing your knowledge and understanding of the culture and contextual values on a nationwide or corporate level. But be careful when you do this. Taking this a little too far will result in hindering other developers (who speak fluent English) from understanding your code, which can spell disaster, especially if you work in a multi-cultural environment.

#2. Give Variables and Methods Meaningful Names

You have probably seen this point on countless blog posts on writing “clean code”. The reason why you have seen this so often is because everybody is in agreement.

If you are a junior developer, you might be thinking “psssh, naming variables is easy”.

Well, you are right. Naming variables is easy.

However, naming variables in a way so that the developer next to you understands the purpose of that variable right away is somewhat challenging.

Try asking your co-worker to tell you what the method that you just wrote does without reading the implementation details.

If they guess correctly, congratulations! If not, that might be a sign that you should probably look at renaming that variable/method.

Here is my advice: Be descriptive with your variable/method names.

Long variable names do NOT equate to good variable names.

Being descriptive involves using only as many characters as necessary.


Let us look at a simple code snippet in JavaScript. Note that this example applies universally, no matter what language you program in.

When naming variables, examine the logic and choose the most appropriate name for the operation.

Here is a rule of thumb:

If the variable contains more than three to four words, chances are, the function is doing way too many things. 

Do use your discretion with the rule above before making any decisions.

We will be re-visiting this concept briefly in another point.

Let’s take a look at a sample code snippet.

var intialValue = 0;
var sum123= [1,2,3,4,5,6].reduce((accumulator, currentVal) => {
    accumulator += currentVal;    // increment the accumulator
    return accumulator;
}, initialValue);

Which variable name is more concise? sum123? or sum? Here, I will argue and state that sum is better.

Because it doesn’t take much time to figure out that the values we are summing up here is 123. By appending 123 to the variable name, we are not only adding unnecessary information, we are also adding a layer of confusion.

How can you tell for sure (without looking at the code) whether we are summing up to the number 123 e.g. 1 + 2 + 3 ... + 123, or summing up the numbers 1, 2 and 3?

In the small code snippet above, the problem is not very noticeable, because the logic is extremely simple. It doesn’t take long to read the code and figure out what it does.

However, in complex functions, such mistakes can be detrimental and may convert into 1 ~ 2 hours of extra debugging or more.

#3. In General, Methods should perform only a single operation

Borrowing from the single responsibility principle and also from functional programming concepts, I would like to explore the concept of methods.

Methods and modules should only have a single reason to change.

If you have been programming for a bit, you would have come across the point.

For more reading on Object oriented analysis and design and best practices, I recommend that you read up on SOLID. Because these topics alone can fill an entire book, I will just keep the scope to methods and modules.

Example One

Keeping your functions pure is also another terrific way to minimize bugs and side effects.

Lets take a look at some basic code: the legendary add() method in Java.

public static int add(int a, int b) {
    return a + b;

First, let us look at the access modifier: static. The word static communicates to me that I should get consistent results, regardless of the nature of the items I input.

That it is NOT dependent on the state and behavior of the class that it is part of.

The above example is clean. You might give me flake saying that the variable name choice a, b is bad. Normally, in some more complex piece of code, yes, you would be right.

However, in the code snippet above, it is obvious that a and b are arbitrary numbers. It has the keyword int in front of it!

As you can see, sometime we have to (and should) break existing principles regarding clean code to make things more readable. In the previous example, changing the arguments to numberOne and numberTwo makes the code longer and does not provide any more meaningful information than a and b does in this case.

Let’s look at a version of add where we start doing more than just adding and returning the sum of the two values passed.

public static int printAndAdd(int a, int b) {
    int sum = a + b;
    System.out.println("result: " + sum);
    return sum;

We added only two lines and changed the variable name, but now we have a problem. The function is doing two things instead of one!

This leads us to the next code smell.

If a variable or method has “And” in its name, bring out the refactoring rifle!

Aim to build methods and subroutines that have predictable results.

If you cannot predict the results for sample inputs, that is a big neon sign flashing at you to refactor your code!

Example Two

The exception to the following rule

Methods and modules should only have a single reason to change.

applies when a method needs to perform a operation that involves a sequence/series of sub-operations.

Like the following (written in semi – pseudo code). The code below utilizes sequential function calls to handle initialization logic.

initApp() {

    if (isRunning) {
    // big picture view of what is 
    // going on during initialization.


    // More operations

The code above reads like a paragraph in a well-written book, which is what you should be aiming for. Imagine if you had a for loop in this code snippet and all the nasty logic inisde of initApp(). Below, we utilize inline logic to create a longer method for initialization. As you can see, we are breaking some rules such as keeping methods short and simple as possible, and only handling one operation per method call.

initApp() {

    if (isRunning) {
    // ewwwwwww ...

    // Initialize data sources
    if dataSources is not NULL
        for dataSource in dataSources 
            // Perform some operations
        log.INFO("No data source available to initialize on startup"); 

    // Initialize scheduled events
    if scheduledEvents is not NULL
        for scheduledEvent in scheduledEvents
            // Perform some operations
        log.INFO("No scheduled event available to initialize on startup"); 

    // More operations

Instead of reading code that reads like a paragraph in a well-written book, we now also need to decipher what exactly is going on.

Because the logic in initApp() has now become complex, comments may be added by the developer.

Just from looking at the code above and the tone that I used, you might be led into thinking: “Hey, I like the method of putting all the logic into functions, and calling them step by step”.

I too was also convinced for quite some time that the former is objectively the better way until somebody on Reddit was kind enough to disagree with me and say otherwise. Let’s look at the pros and cons of both methods.

Examining Trade Offs – Inline logic vs Function calls

If we wrote code that read like the former example, minimal commenting would be needed. The method calls alone such as initDataSource() will be more than sufficient to explain what is going on.

In my history as a developer, I have come across cases where comments are downright wrong, which has caused many hours to be wasted.

In the first example, although the complex logic is replaced by name function calls, we expose ourselves to the possibility of facing confusing cases if yourself or another developer who named that function gave the function a misleading or improper name.

When we are familiar with a system and its behavior, we usually want the big picture info, which makes named function calls a lot easier to follow around, since we have a more intimate knowledge of our domain and the workflow involved. It also helps that IDEs have nice features that allow us to travel to the implementation details of a function with a single click or via a shortcut.

However, what if you need to see all the details on one page without jumping to 4-5 different files to trace each implementation details?

Perhaps you are new to the job, or that particular method is part of a system that is touched once a month and you need to refresh your memory each time?

As you can see, not everything is black and white.

In most cases, especially as your code-base grows, you will have to weigh the pros and cons, and make compromises. In the end, over-engineering or trying to be too smart for your own good will do more harm than good.

Inline Logic – Pros and Cons


  • All the logic can be viewed inside of a single function, without the need to move back and forth between various function calls.
  • In certain cases, having the code inline (especially when dealing with many state changes) can lead to more readable code, despite the length of the method body. This becomes more apparent if the logic inside of the function is short.


  • A lengthy method body can be taxing for the brain and eyes.
  • If function calls contain complex logic, this can add an extra layer of complexity, which could have been abstracted out via placing each individual operation inside of function calls.

Therefore, because each case is unique and there are obvious trade-offs between each decision made, it is important to develop strong critical thinking skills and use them before, while and after writing code.

#4. Write Code for your Target Audience

Earlier on, we discussed the importance of knowing our target audience. The next step is to apply and adjust to the way we write code in accordance to our knowledge of the target audience

You might be wondering: what the heck is Jay saying? We aren’t writing a novel or some sort of online blog post or article.

Yes, true. However, the common link between writing software and some other form of written content such as literature or a blog post is that there is a target audience and knowledge or lack thereof is costly.

I know, every developer has their own style and opinions. Believe me when I say that I feel you.

Regarding this conflicting matter, I have one crucial piece of advice.

A good programmer should be open and willing to lay down and re-evaluate his/her personal style for the sake of cohesive development

The moment a developer is unable to lay down and evaluate his/her style is the sad day that growth stops (hopefully temporarily) for that said individual.

An opinion that cannot be changed is no longer an opinion.

A stubborn person will only operate with what they like and are familiar with. They will disregard everything else, and that becomes fatal, especially more so in programming where the industry has evolved rapidly and is continuing to take great leaps and bounds in its development.

Working in a Team with a High Skill Range

This leads to another interesting concept that an extremely experienced software engineer shared with me after work over a cup of coffee.

By high skill range, I am stating that the skill gap between the high and low tier developers of a specific team, is high.

Before I proceed, let me tell you: I am not here to bash on low skilled developers. Every developer, regardless of talent, IQ, etc. has all been there at some point.

Sometimes, your idea of clean code is not the most optimal solution for the given case

Let’s face it: writing code is a team game. Somebody else wrote the code for the text editor/IDE you are using to write code.

We work with people that are on various skill levels. Some are amazing developers. Others are so and so. Some are also downright bad. Let’s just be real.

If everybody is on the same level, sure! Cohesive development will occur more naturally (not saying that it won’t occur without the proper interaction and agreements however).

If however, you are using some complex architecture, no matter how “good” your code is, the developers with little to zero experience or the bad developers will have no clue.

It’s all mumbo jumbo to them.

How to deal with this situation

Therefore, in cases like this you have two choices

  1. Continue to do your own thing.
  2. Communicate with the entire team. Try to meet your team members in the middle.

I also had instances (I am not saying this to brag. I still have a long long way to go) where I had to compromise and think about how to write code so that the junior developers can understand the code that I write.

Meeting in the middle is not just about you compromising. The compromise has to be mutual. In another word, the lower-tier developers have to do their part and pick up their game a notch or two.

I have personally seen decent results with this approach, provided that the lower-tier developers are motivated and have a positive attitude.

I will now go through some possible target audiences in the next sub-section to give you a picture of what this can look like in certain environments.

Enterprise Development

A lot of companies have in-house development style guides or conventions. It is pretty much a documentation that describes how you should name your variables, what kind of casing you should use, etc.

Writing clean code in an enterprise development lies in firstly adopting and embracing these conventions.

The next step is to get to know your co-workers.

How do they read code? After working with co-workers for a few months, you will begin to understand their style.

Afterwards, start writing code in a way that maximizes readability for these co-workers.

You are writing code not just for yourself, but also for those around you.

I said this before, but I will say it again. What is the point if you think your code is awesome, but everyone around you says otherwise?

Large Open Source Projects

Huge open source projects will most likely have their own development guidelines, documentations, rules and standards.

To write good code in this situation, read the existing code base and see what others have done.

Generally, well-written code is easily understood by a wide range of audience. The more confidence votes you get, the more likely it is that the code you just wrote is clean code.

If possible, identify parts which many developers have recognized as good code. Up-votes or explicit positive comments are a good sign.

Examining commit histories and comments made will enable you to assess the general mindset and preferences of the people working on that project.

Open Source – Personal Project

Here, you are free to choose to stick to your own style and conviction. I love personal projects, because it enables you to think critically on the task at hand, unhindered by external constraints.

Take advantage of this fact!

Remember though, with great power comes great responsibility.

Just because you have this “freedom”, don’t loosen up and be negligent in the way you think, process, analyze and write code. Take pride in your work!

Remember, you are/will become an MVP programmer!

#5. Don’t Use Comments to Justify Bad Code

Over the time, some people gotten into the habit of writing comments on every piece of code that you write.

I would like to say the following.

If your code requires comments to follow, that is a sign that your code needs to be refactored.

I generally equate comments to be code smell when working with a module that is designed specifically for a single purpose.

Comments should explain where code cannot

For example, code cannot explain the history behind why a specific method was implemented a certain way if things were done unconventionally. By leaving a comment, the next developer that examines the code can read the history and understand why the code was written that way.

Sometimes we might apply an unconventional approach to solving a problem because of some obscure external variable is causing side effects. These things are difficult to explain with code.

#6. Be Open to Criticism

Blatant hate-filled criticism is worthless, but constructive criticism is often the catalyst for explosive growth.

We cannot see our own body without the help of a mirror. And even then, our field of vision is grossly limited.

In the same way, people see your work in a different light.

Which is why it is mutually beneficial to critique one another, with the purpose of building up, not tearing down.

The only thing you should be tearing down are bad habits and poorly written code.

When we constructively critique each other, we spur one another on to not only write better code, but to also think outside of the box.

Aim to write code that is so clean that you can see yourself in it!

#7. Do Code Review with Peers

Sometimes, you can suffer from tunnel vision, especially regarding code that you personally wrote.

When you write the code, of course you know how the logic works. What the values stored in the variable does. How all the classes and methods work and interact with each other.

The most important question to ask here is:

Can your peer(s) figure it out on their own quickly? 

Quickly is a relative term, so here is my personal checklist:

  1. By skimming over the code, can your peer(s) understand the general flow of logic?
  2. Does your method perform only the operation suggested by the method name?
  3. If I shipped my code to another developer, could they utilize the code by just following the API documentation?
  4. Is your code modular and easy to test? (clean code, by my definition, should also be easy to test)

If you answered no to any of the questions above, you may want to refactor your code.

I say “may” because as I mentioned, in some cases, you need to break the rules to make code more readable and clean. This doesn’t mean however that you should always break the rules, because more often than not, these rules will act as safeguards to keep you from writing bad code.

Now, I know that these are very tall orders to achieve. But this is the standard to which you, as a software engineer, should hold to.

I fall short of my standards often, but the pursuit of fulfilling these standards, and the process/journey is what allows us to grow and become better at what we do.

If you said yes to every one of the points above, good for you!

As a programmer, you never want to become stagnant. If you want to become a better programmer, I wrote an article on how to become better at coding. Hopefully the points that I make aid you greatly in your quest to become a clean coder.

#8. Learn Clean Code via Pair Programming

One of the best ways to learn how to write clean code is to pair program with somebody, preferably one who has more experience than you.

Pair programming is a free real-time coding feedback system that is (usually) free of charge

Well, free to you anyway, since the company is paying money for the other developer’s time if you pair program at work.

Pair programming works on two levels.

  1. As you code, you have another developer share his/her opinions, provide feedback and chime in if there is possibly a “better/cleaner way” to do things.
  2. When the other developer codes, you get the opportunity to critically think, share your opinion and observe how another programmer approaches the problem at hand. You also pick up invaluable programming knowledge if the developer is more experienced than you.

The thoughts that generated the code that you see on your screen is more valuable than the code itself.

The code is good. However, the code that you see on the screen communicates only a small fragment of the efforts, thoughts, processing, blood, sweat and tears of that programmer.

Why not bother to pick his/her brain?

Do I even need to go into why this can help you write clean code?

You can potentially receive year’s worth of knowledge in a matter of hours! Going to take a leaf out of Shia’s book and say JUST DO IT!!

The code is simply the summarized conclusion of a deep and vast array of thoughts

How to Pick a Programmer’s Brain while Pair Programming

Okay, you now know the importance of pair programming. The next question to answer is

How can I make the most of this opportunity?

If you are going to be all timid and just shut up while he/she codes, don’t expect anything.

Don’t be afraid of sounding dumb. Just ask it!

However, when you do ask a question, make sure that you have put some thought into the question and the subject matter before asking. Nothing peeves off a programmer more than a unprocessed question with little to zero substance.

And be polite!

Here is a collection of possible questions to get you started.

  • I would have thought <insert method/approach> would be better in this case. Can you please explain your thought process and how you came to decide on implementing it that way?
  • Is <insert language/tool> the most appropriate language/tool for this case? If so, could you please explain why?
  • Do you think the code is clean as it is? If you were writing the code, would you make any changes?

#9. Don’t Always Adopt the Same Approach

This is a general rule of thumb that applies to anybody who wants to grow or improve, regardless of area of specialty.

If writers always used the same cookie cutter methods for producing books, we would not have the wide variety of books that we have in the world right now.

As programmers, our primary objective is to write clean, readable, easy to understand solutions to problems.

We are paid to solve problems.

And guess what: each problem is unique!

Therefore, it is only natural that we adopt different, unique approaches to each set of problems.

The ability to gather, collect and organize information not only makes you a better problem solver, it also gives you insight on how you can solve a problem in the cleanest, most efficient and coherent manner.

If you are working in a mission-critical environment, why not employ TDD? If they are giving you the time to write the best possible code, this might be a good idea.

NEVER EVER COPY PASTE A PIECE OF CODE without first scrutinizing it!

If you ever need to copy and paste a piece of code, that means that either yourself or another developer came across that problem and solved it.

No need to constantly re-invent the wheel, right?

If this is the case, then it is a sign that the piece of code should be part of a module/library that addresses that problem.

Bottom line is: Never achieve code re-use by re-inventing the wheel or via CTRL C + V.

Bonus: Is Software Maintenance a part of Software Development?

Some people go far ahead as to say that developers write new code and that people who just maintain software are not developers. Well, lets look at the definition of the word “develop” in the good old English dictionary.

to bring out the capabilities or possibilities of; bring to a more advanced or effective state

Does the act of software maintenance bring the software to a more advanced and effective state? If you ask me, my solid answer is YES.

Recommended Resources

  • Clean code: A handbook on Agile Software Craftsmanship – Without hesitation, I will recommend all Java Developers to read this. As a matter of fact, I actually wrote a Java book review which covers my opinion of this book in detail. Please note that the source code in this book is all in Java. However, I do believe that programmers that do not have a Java background can still benefit from reading this book. However, one major pitfall is that some of the examples are Java specific, meaning that translating that concept into another language without a filter may not be considered “clean code”.
  • The Clean Coder – Another book by Uncle Bob. Rest assured, I am not getting paid by Uncle Bob to promote his books. This book focuses more on the daily struggles of a programmer, such as committing and attempting to meet unreasonable deadlines, learning when to say no, when to say yes, etc. This will teach you practical wisdom on how a professional software engineer should behave and conduct themselves out on the market.
  • Code Complete – Although the concepts discussed in this book is by no means easy, the hard work will pay off dividends throughout your life as a software developer. It also gives you a benchmark to assess your programming skills and your journey. One basic litmus test you can apply is that if you are able to understand the concepts and the underlying messages in this book, you are growing as a programmer. The practical advice given on how to write clean code and complete writing your code is of extreme importance and warrants multiple re-reads.

If there are any additional books that you would like to recommend, please leave a comment below and suggest!

After determining its worth, I will most likely pick up a copy and read it.

Additionally (not sure if this is a strong incentive), you will also have my thanks.


If this post helped you, or you found the contents valuable, I want to ask you to please share this post!

I put in quite a bit of time to write up this post with a sincere desire and purpose of helping people. One way to ensure that this post reaches as many people as possible is to share it.

This was lengthy post, so I suggest that you take a break or (if you really want to) process what you learned.

Thank you so much for reading and until next time, peace!

– Jay

About the Author Jay

I am a programmer currently living in Seoul, South Korea. I created this blog as an outlet to express what I know / have been learning in text form for retaining knowledge and also to hopefully help the wider community. I am passionate about data structures and algorithms. The back-end and databases is where my heart is at.

follow me on: