In short: old but gold.

Published in 1999, The Pragmatic Programmer is a book about how to become a Pragmatic Programmer. Which really means a ‘Good Programmer’.

Yes, it was published about 20 years ago. But this book still provides many insights that are very relevant to programmers or software engineers, as some people might call them these days.

You might have heard about this book before and questioned what actually it's actually about. Well, today I will share with you some of the interesting things I learned while reading the book.

There is more to being a programmer than technical skills

_Photo by [Unsplash](https://unsplash.com/@alexkixa?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Alexandre Debiève / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

When reading the book's title, you might expect it to give out a lot of technical lessons. But in fact it does not. What makes this book still relevant 20 years later is that it teaches us that being a programmer is not all about technical strength. And we often overlook this fact.

The book teaches us that there is more to programming than technical abilities.

The cat ate my source code

_Photo by [Unsplash](https://unsplash.com/@chen93?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Chen Zhao / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

This is the first chapter in the book and is a very interesting concept.

Remember that one day when we didn’t finish our homework and we said that the dog ate it? (Actually I don’t remember it, because I always finish my homework ?)

What that - and this chapter - teaches us is actually responsibility. When you have responsibility for something, you should be prepared to be held accountable for it.

If you make mistakes and cannot fulfill those responsibilities, you have to make up for it and find a solution. Don’t make up excuses and play the finger pointing game. You can’t just go into work and tell everybody that a cat just ate your source code.

Provide options, don’t make lame excuses.

It’s all about a broken window

_Photo by [Unsplash](https://unsplash.com/@pawel_czerwinski?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Paweł Czerwiński / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

In the book, there is a story about an urban area that became very messy and run-down, all because of one broken window.

This is much like our code: when we see some dirty code (which we can see like it's a broken window), we might start to think that it’s okay to let the code be dirty. That it’s okay to just go back later, which most of the time we never do.

Try not to leave “broken windows” unrepaired. When you find that kind of code, fix it up as soon as possible. When you continue to think that no one has the time to fix that broken code, you might as well go and buy yourself a dumpster just to keep your code.

What this chapter discusses is actually simple: it’s about initiative and taking care of your stuff.

Take the initiative, be the catalyst

_Photo by [Unsplash](https://unsplash.com/@bradencollum?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Braden Collum / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

There also might be times when you know that either something is all good or something needs to actually get done. It comes to your mind and you just think to yourself that it’s the right thing to do.

If you just keep thinking, nothing will happen. Or if you just ask for it to be on the project timeline, you might be met with huge feature development requests and technical debt. So it ends up in another year in discussion.

It’s time to step up your game. Work out what you can, don’t overdo it, but also make it reasonable. Once you got your complete idea, show it to people. They might think that “Yeah, it might be better if we had that.”

Show them a glimpse of the future and people will rally around you. Be a catalyst for change.

More so, this book also teaches us about basic fundamentals that we often forget as programmers.

Sometimes, the more we delve deeper and deeper into our work, the more often we forgot about the basic things that we learned a long time ago.

Busy chasing features and new tech improvements, we often forget that there are actually a lot more things that we need to pay attention to beforehand before going deeper.

Clean code

_Photo by [Unsplash](https://unsplash.com/@4themorningshoot?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Oliver Hale / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

One of the most basic principles we often forget about is clean code. As features are piling up more and more, the codebase become fatter and technical debt rises.

But we must always remember to keep our code consistent and clean every time we write it.

One of the things that is mentioned in the book is the DRY principle (Don’t Repeat Yourself). It is related to code reusability. Duplication is evil and that's the truth. Duplicate code will make maintaining your code very hard, and it can cause confusion when you need to change a feature or fix a bug.

Remember that time when you needed to fix some of your code? And you realized that there was code that was very similar to the bit you just changed? So then you gotta change that part too, and another too, and then maybe this bit too…you get the picture.

Find the correct tools

_Photo by [Unsplash](https://unsplash.com/@carlevarino?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Cesar Carlevarino Aragon / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

Like a woodcutter, finding the correct and proper tools is very important. Before a woodcutter starts cutting trees. they have to decide - do they need a chainsaw? Or is an axe good enough? Or maybe there is a brand new lightsaber they can use. But using kitchen knife might take some time to cut down a tree.

It's similar for programmers: this book teaches us that it’s very important for us to find the proper tools before we start working (like a good code editor). We shouldn't jump right to coding.

For example, it’s actually possible to code using Windows notepad and compile it using the console. But is it the right tool for you? Try to find the best editor that you are most comfortable using. Learning and mastering it and it will increase your productivity by several times.

There are several editors mentioned in the book, such as Emacs or Vim. But nowadays you can find more modern code editors such as Visual Studio Code. Find one that suites you. It's like your taste in coffee – some people prefer lattes and others prefer cappuccinos.

Don’t program by coincidence

This is one very important point noted in the book. In all of our programming journeys, there have likely been times when we were just coding blindly and unexpectedly… and somehow it just worked.

You probably weren't sure what you were actually doing, so you kept adding more and more code and it still worked. That is, until one day when there was an issue and you tried to remove some chunk of code and it completely broke everything. And you were not sure which piece caused it.

Relying on unknowns is very dangerous. When you are not sure what the code is supposed to do, try to simplify it and make sure that the code is reliable in its own right, not just reliable by chance.

Rely only on things you are sure of. Don’t program by coincidence.

Unit test

Testing is a hot topic these days. And yes, it was also an important topic 20 years ago (and it will always be).

But sometimes people forget about unit tests these days. They might have just finished their code and they assumed everything was okay...until the code ended up broken in production because of edge cases.

In order to maintain stability and refactor safely, we always need to keep our code protected by writing unit tests. And it’s never enough if your tests only cover the happy path. Perform ruthless testing on your code, and remember that your code is not finished until you've covered every available test.

Unit testing will help you be confident that your piece of code is truly done.

Taking ownership

There's one last thing I want to talk about. As we know, programmers like to leave ‘legacies’ behind, in the form of code. And yes, most of the time it’s bad.

Being a programmer, we ought to take pride in our own work. We should be proud of the responsibility we've been given and the piece of code we have been working on.

When we are finally able to take pride in our code and own it, we will be able to leave a good legacy behind. And people will see our code as a signature. When they see our code, they'll know that it will be solid and well-written, by a professional.

Finishing up

There are even more topics covered in this book that I haven’t discussed here, such as Requirements and Teamwork. If you are interested in exploring these topics, you should try to find and read the book!

Just a note, however: as much as I liked the book, some stuff just didn't seem relate-able, looking at how old the book is (20 years old). It talks about old languages such as Prolog, and speaks about OOP like it’s a really new concept - so these oddities just don't seem right.

But it can’t be blamed since it's already a couple decades old.

Aside from that most of the stuff covered in the book is still quite relevant to the current age of Programming, like those topics I covered above.

If I was trying to sum everything up in this book, I'd say it basically covers everything I have ever read on the Web about becoming a better engineer.

Thanks for reading my article about The Pragmatic Programmer! Hopefully it has given you some insight into your journey as a Programmer or Software Engineer. And grab yourself a copy of the book if you are interested in learning more.

P.S. I wrote this article on my own, without any means of advertising or marketing from a third party. The cover photo was taken from amazon's site.

I was at a software craftsmanship meetup recently, where we formed pairs to solve a simplified Berlin Clock Kata. A Berlin Clock displays the time using rows of flashing lights, which you can see below (although in the kata we just output a text representation, and the lights in a row are all the same colour).

Initial Test Driven solution

Most pairs used inside out TDD, and there were a lot of solutions that looked something like this (complete code available on GitHub).

def berlin_clock_time(julian_time):
    hours, minutes, seconds = list(map(int, julian_time.split(":")))

    return [
        seconds_row_lights(seconds % 2)
        , five_hours_row_lights(hours)
        , single_hours_row_lights(hours % 5)
        , five_minutes_row_lights(minutes)
        , single_minutes_row_lights(minutes % 5)
    ]

def five_hours_row_lights(hours):
    lights_on = hours // 5
    lights_in_row = 4
    return lights_for_row("R", lights_on, lights_in_row)

# ...

This type of solution drops out naturally from applying inside out TDD to the problem. You write some tests for the seconds row, then some tests for the five hours row, and so on, and then you put it all together and do some refactoring. This solution does expose some of the domain concepts at a glance:

• There are 5 rows
• There is one second row, 2 hour rows and 2 minute rows

Some more concepts are available after a bit of digging, but aren't immediately obvious. The rows are made up of lights that can be on (or presumably off), and that the number of lights on is an indication of the time.

However there are some big parts of the problem that are not exposed. And since I haven't yet explained it, you probably don't know exactly how the Berlin Clock works yet.

Elevate the concepts

To improve this we can bring some of the details that are buried in the helper functions (such as get_five_hours) closer to the top of the file. This brings you to something like the following (complete code available on GitHub), although the downside is that it breaks nearly all of the tests. Solutions like this are rarer on GitHub, but do exist.

def berlin_clock_time(julian_time):
    hours, minutes, seconds = list(map(int, julian_time.split(":")))

    single_seconds = seconds_row_lights(seconds % 2)
    five_hours = row_lights(
        light_colour="R",
        lights_on=hours // 5,
        lights_in_row=4)
    single_hours = row_lights(
        light_colour="R",
        lights_on=hours % 5,
        lights_in_row=4)
    five_minutes = row_lights(
        light_colour="Y",
        lights_on=minutes // 5,
        lights_in_row=11)
    single_minutes = row_lights(
        light_colour="Y",
        lights_on=minutes % 5,
        lights_in_row=4)

    return [
        single_seconds,
        five_hours,
        single_hours,
        five_minutes,
        single_minutes
    ]

# ...

This improves the concepts that are now exposed at a glance:

• There are 5 rows
• The seconds row is a special case
• There are 2 hour rows and 2 minute rows
• The rows use different colour lights
• The rows have a different number of lights

This is pretty good, and is already better that most of the solutions out there. However, it's still a bit mysterious how the rows are related to each other (there are 2 rows to display the hours and the minutes, so presumably these are linked). It's also not obvious what amount of time each light represents.

Name implicit concepts

At the moment some of the concepts (such as the amount of time each light represents) are implicit in the code. Making these explicit, and naming them, forces us to understand them and to embed that understanding in the code.

In order to make the amount of time each light represents explicit, it seems like it would be sensible to pass a time_per_light value to row_lights. This means we have to push the calculation of lights_on down into row_lights.

This in turn makes it obvious that there are two kinds of rows: one related to the quotient (\\) of the time value, and one related to the remainder / modulus (%). If we look at the quotient case, we see that the 2nd parameter to the operation is the time_per_light, which is 5 in both cases (5 hours in one case and 5 minutes in the other).

This allows us to write these rows like this:

five_hour_row = row_lights(
    time_per_light=5,
    value=hours, 
    light_colour="R",
    lights_in_row=4)

If we now turn our attention to the remainder case, we realise that time_per_light is always singular (one hour or one minute), as it is filling in the gaps in the quotient case.

For example, the five hours row can represent 0, 5, 10, 15, or 20 hours, but nothing in between. In order to represent any hour, there must be another row to represent +1, +2, +3 and +4. This means that this row must have exactly 4 lights, and that each light must represent 1 hour.

This implies that the remainder case is dependent on the quotient one, which most people would describe as a parent / child relationship.

With this knowledge in hand, we can now create a function for the child remainder rows, and the solution now looks like this (complete code on GitHub):

def berlin_clock_time(julian_time):
    hours, minutes, seconds = list(map(int, julian_time.split(":")))

    return [
        seconds_row_lights(
            seconds % 2),
        parent_row_lights(
            time_per_light=5,
            value=hours, 
            light_colour="R",
            lights_in_row=4),
        child_remainder_row_lights(
            parent_time_per_light=5,
            value=hours,
            light_colour="R"),
        parent_row_lights(
            time_per_light=5,
            value=minutes, 
            light_colour="Y",
            lights_in_row=11),
        child_remainder_row_lights(
            parent_time_per_light=5,
            light_colour="Y",
            value=minutes)
    ]

# ...

A quick glance at this code now reveals nearly all the domain concepts

• The first row represents the seconds and is a special case
• On the second row each "R" light represents 5 hours
• The third row shows the remainder from the second
• On the fourth row each "Y" light represents 5 hours
• The fifth row shows the remainder from the fourth

This took something thinking about, which will have cost us some time / money. But we increased our understanding of the problem while we did it, and most importantly we embedded that knowledge in to the code. This means that the next person to read the code will not have to do this, which will save some time / money. Since we spend about 10 times longer reading code than we do writing it, this is probably a worthwhile endeavour.

Embedding this understanding has also made it harder for future programmers to make mistakes. For example, the concept of parent / child rows didn't exist in earlier examples, and it would be easy to mismatch them. Now the concept is plain to see, and the values are mostly worked out for you. It is also easier to refactor to support new clock variants, for example where lights in the first hours row represent 6 hours.

How far should you take it?

There are things we can do to take this further. For example the parent_time_per_light of a child row must match the time_per_light of its parent, and there is nothing enforcing this. There is also a relationship between time_per_light and lights_in_row for the parent rows, and again it is not enforced.

However, at the moment we are only required to support one clock variant, so these probably aren't worth doing. When a change is required for the code, we should refactor so that the change is easy (which might be hard) and then make the easy change.

Conclusions

Embedding domain concepts in code requires thought and skill, and TDD won't necessarily do it for you. It takes longer than a naive solution, but makes the code easier to understand, and will very likely save time in the medium term. Time is money, and finding the right balance of spending time now versus saving time later is also an important skill for a professional programmer to have.

Reducing Risk and Managing Your Custom Fields

source https://pixabay.com

Have you ever wondered how to properly name keys of WordPress custom fields? Does it make any difference? Should you care? What are the potential risks?

Recently I wrote a tutorial about filtering WordPress admin views. In the code, I named custom fields key like kg_order_items. You could ask why? Why not name it just items? Well… read below!

If you try to google for naming custom fields there is not so much information about it. Even the Codex entry tells nothing about naming the field keys in a proper way. I found only one resource at ACF forums that contains proper information.

If there is no problem, what is the fuss about? You could ask.

_Found on [http://dilbert.com](http://dilbert.com" rel="noopener" target="blank" title=")

The days when WordPress was a simple CMS supporting small blog websites with only posts and pages are gone. Today even the smallest website uses a plethora of plugins and complex themes. And all of them bring new custom fields into the game.

The situation gets even worse if you use any of the fancy “premium” themes. Unfortunately, many of these are not well written and combine 1001 functions in one. Final result? Slow, not performant, and tangled site which looks nice only on demo content and stock images. And they add a lot of custom fields too.

Danger!

Source unknown

WordPress wp_postmeta table is very simple. It is a key-value pair attached to particular post_id. It means that all custom fields keys share a common namespace. That is especially true for the particular ID of the post.

First example
a) Imagine that your post has a “learn more” link. After you click the link it redirects you to a particular URL. The address is provided in a custom field. Let’s name the field key as redirect_to.

b) Now imagine that you install a plugin called for example “Redirect me, Honey”. The plugin is very, very simple. When the user enters the page it immediately redirects the user based on custom field setting attached to a post. Oh… and its field key is named redirect_to as well.

Result? After you activate the plugin, all of your posts with “learn more” button are redirecting users out of your website. And the reason why is not obvious at the first sight. It may even be unnoticed for quite a while.

This scenario is, of course, made up but the dangers are real. With thousands of plugins and thousands of themes available it’s just a matter of time to encounter such name collision.

Second example
WordPress can store multiple values for the same key name and post ID. (Unless you provide special parameter called $unique).

It means that if you save your data 5 times under the key location you will receive an array consisting of 5 elements when calling get_post_meta().

Let’s assume that you have a post about the cities you have visited. You have been to 5 cities and those locations are shown on the embedded map in the post. Simple, right?

Attention! Not useful code ahead. ;) !

//NYadd_post_meta($post_id, 'location', '40.7127753, 73.989308');

//LAadd_post_meta($post_id, 'location', '34.0522342, -118.2436849');

//Parisadd_post_meta($post_id, 'location', '48.856614, 2.3522219000000177');

//Viennaadd_post_meta($post_id, 'location', '48.2081743, 16.37381890000006');

//Romeadd_post_meta($post_id, 'location', '41.90278349999999, 12.496365500000024');

//Lets check what we have herevar_dump(get_post_meta($post_id, 'location');

array (size=5)0 => string '40.7127753, 73.989308' (length=21)1 => string '34.0522342, -118.2436849' (length=24)2 => string '48.856614, 2.3522219000000177' (length=29)3 => string '48.2081743,16.37381890000006' (length=28)4 => string '41.90278349999999,12.496365500000024' (length=36)

What if after a while you use a new theme or plugin. It has a feature which can set the position of a post on a front page. You can pick between slider, sidebar or featured posts etc. This scenario may end up like this:

array (size=6) 0 => string ‘40.7127753, 73.989308’ (length=21) 1 => string ‘34.0522342, -118.2436849’ (length=24) 2 => string ‘48.856614, 2.3522219000000177’ (length=29) 3 => string ‘48.2081743,16.37381890000006’ (length=28) 4 => string ‘41.90278349999999,12.496365500000024’ (length=36) 5 => string ‘left_sidebar’ (length=12) // Yeah, right…

Or even worse:

array (size=5)  0 => string 'left_sidebar' (length=12)  1 => string 'left_sidebar' (length=12)  2 => string 'left_sidebar' (length=12)  3 => string 'left_sidebar' (length=12)  4 => string 'left_sidebar' (length=12)

Your pretty little map is broken now! And you lost all of your entered data. Not funny right?

B-b-b-b-roken?? ;( source https://pixabay.com

Solution

You can never protect your custom fields data from being overwritten or deleted. This is how WordPress works and why it is so flexible. You can reduce that risk though.

How?
By avoiding common names and namespacing all your custom fields keys.

My proposed convention is:

• cpt-name_field-name
  like books_author instead of author, order_items instead of items(solution for most lazy ones :) ).
• purpose_field-name
  like front_page_location instead of location, visited_cities_locationsinstead of location.
• prefix_(cpt-name/purpose)_field-name
  like kg_books_author, kg_visited_cities_locations (for the most strict ones).

That is not all. Additionally, you should always take care of optional parameters of built-in WordPress functions:

• add_post_meta() has $unique to not add the custom field if it already exists.
• get_post_meta() uses $single to retrieve only one record (if you expect only one record).
• update_post_meta() and delete_post_meta() leverage $previous_value to ensure that you update/delete the key you want.

Those parameters are helping in writing better, cleaner and more predictable code.

And that is not all. Use well tested, well written and extendable plugins like Pods Framework or Advanced Custom Fields. These will help manage your custom fields. They are great when it comes to managing the tangled world of your custom data.

Summary

In the ideal world, we should always be aware of what you are adding to the system. We should know what your plugins, themes, and custom functions are doing. That is unfortunately not always possible.

Therefore we should pay attention to the code we produce and tighten up all those loose ends.

That is all folks! I hope you liked it and have a great day!

This post was originally published on my private blog where I write about WordPress and development in general.