When I was first starting as a junior programmer I would always get lost when looking at backend code.

I assumed that part of it was because I was a junior developer; that I did javascript instead of whatever language was used in that backend; and that frontend development was very different from backend.

I worked with backends in php and python, with several frameworks, and every time I would feel lost during the first couple of weeks. No matter how many times I would encounter the MVC (Model-View-Controller) pattern, I would always feel lost and would have a hard time figuring out in what files was the code I needed to change.

As I worked more and more on such projects, and gained experienced in software architecture, I realized that the problem was not so much the complexity of the code or the patterns, but how the code was organized and structured into different folders and files.

If you did frontend before react and the advent of Component frameworks, you probably faced the same issue. HTML files were in a templates folder, css in a styles and js in script. These folders would then have several levels of subfolders divided by pattern, others by functionality and others would just be random, like utils, assets or whatever name seemed convenient at the time. Things were separated by format, or pattern, or some other random logic that made some kind of sense. The senior engineers in the project always felt the architecture made perfect sense due to habit and would not easily empathize with the hardships of new developers.

Now... Have you ever heard about Hebb's rule? Hebb's rule comes from neuroscience and can be simplified as:

“Neurons that fire together wire together”

One of the main take aways of this rule, is brain plasticity. Brain plasticity is the fact that when different neurons work together to achieve something, they all create stronger connections and group into networks.

Code should be similar. Code that works together to achieve something, starts to be tightly coupled and should be grouped together.

If you have a template, css, js and some assets that render a certain route, they should all be in the same folder that represents that route. If they form a reusable component, they should all be in the folder for that component. This also applies to the backend. If you have an API, with a specific view, that uses a form, and a specific serializer, instead of having a the view in a folder with all the views, the form in one with all the forms and the serializer in one with all the serializers, those files should be together.

Once you understand this, you will understand why JSX, who contradicted all the conventions at the time, is now so widely adopted and paved the way for Component frameworks. Before JSX it was common place to have code split based on file format, and not on functionality. Adding a feature meant adding 3 new files and changing a few more, across different folders and subfolders. JSX allowed for logic, template and style to all co-exist in the same place; making it easier to create or change code when working on a specific functionality.

This also applies to hooks. Before hooks your logic in your component would be spread around different life-cycle methods. Now you can put together the logic that works together, in the form of a custom hook.

Before I go, let me just say that this doesn't mean that you should have a monolith with all your code. No, this means that you should group and split your code based on functionality.

To sum it up:

Code that works together, stays together

Last week I talked about "Less is more" and how you should not add code because you might need it in the future. Today, in our efforts to simplify code and to do more with less, I want to talk about deleting existing code.

First of all, deleting code is hard. Deleting code to simplify it or to completely remove it, can cause all kinds of issues, so before you start deleting code you should ask yourself should I remove this code? In order answer this, I really like to think about a quote from Chesterton. If you are curious, you can listen to the quote in the end of this episode, but for now, let's consider a simplified version of it, adapted to the problem of deleting code. Here it goes:

Don’t ever delete code until you know the reason why it was wrote

If you remember, last week I deleted some frontend code for showing images, but before doing so I asked myself: Can I do this?

I asked myself: Why is this code here, if it is never used? In order to answer this, I went and looked into the backend code into the templates and into the existing code and only by looking at it I realized that the code in question was added for a future case that never happened.

Another way to understand the purpose of the code before deciding if you can delete it, is looking for documentation or tests. Tests are great documentation by the way. Not only do they show you how the code works in a controlled environment, but also they are often added to test edge cases or to fix bugs.

Sometimes even then, the answer is still not clear. In those cases I do a git blame and see why was this code added. If the blame shows me when the code was changed, but doesn't answer the why it was added, I go to the parent commit and redo a git blame. And I keep doing this until I figure out why was this code added in the first place, and if that is still a valid reason for it to exist.

Sometimes there is a valid reason for it to exist. For example, that code deals with an edge case; or it's there to fix a browser inconsistency; or it's not called directly in the code, but some abstract piece of code ends up calling it; etc. etc. etc.

But sometimes, the code is no longer valid. For example, someone forgot to delete it when refactoring; or you stopped using because your product no longer has this functionality; or maybe it's just a case of "We might need this in the future".

When that is the case, then go ahead, and delete that code, and remember, Less is more.

Like many of you, I am currently working from home. I've been doing it for more than a year, and one thing that I noticed while talking to my peers is that is has not been easy to keep a healthy work/life balance.

Working from home has its own challenges. For example, sometimes I feel guilty about my performance during the day. I feel that I am not as focused as I should be, that there are many distractions. Even though this would also happen in the office, since I'm at home, it feels that this is somehow my fault.

Due to that, it is not easy to split my work day from the rest of the day. I've found myself working late, or maybe even going back to work after my work hours. Before, I'd go to work and back, and no matter what, my work PC would stay in the office, forcing a clearer separation. To be able to recreate this separation while working from home, I have put into place several techniques. What works for me, might not work for you, but the issue that they try to tackle is an issue that I think we're all currently facing. That issue is creating boundaries. Boundaries for your work in both time and space.

One technique that I have put into place since day one, was creating a work routine. Like I mentioned before, when you work in an office, you go there, you work, and you come back. Your daily routine working from home should mimic that. For me, it goes something like this: Every morning I wake up, I get ready as if I had to go to the office, I put on work clothes. I take my breakfast, take the kid to school and when it is time to start working, I go into a separate room, close the door and start to work. Maybe 5 minutes later I will be interrupted by someone coming in or something else, but the fact that I do this going to work, closing the door behind me helps me create an artificial separation between my life and my work and sets me into a work mode.

In order to create this separation, I think it is important to create a dedicated workspace. This does not mean having a whole office for working, no. If you have that, that's great, but if you are like me, you just dedicate some space in a corner to set up a work desk. Maybe that space is even shared with others or is temporary. Either way, it is important that it is ready for work and nothing else and that that is your work place. You should not work from your bed, you should not work from your couch, you should only work there. You are not doing this for your employers, you are doing this for yourself, to create a physical boundary between your personal life and your work life.

So, back to my day, I keep working until lunch time. After that I go back to work and when it gets to the end of the day, I do a leave work routine. Once again, having this kind of routine is really important to create boundaries.

My leave work routine consists of turning off my work PC, taking it away from the desk and switching it with my personal laptop. I do this because I am trying to make it as hard as possible to go back to work. I have previously found myself several times working past my working hours or even working after dinner just o finish one last thing.

I think it is very important to create a boundary between your work and your personal life in all of your digital devices. If like me you have a company computer and your own, you can do like I do and just swap the PCs, or even put the company computer in a drawer. I used to do that, because I was working at night, after getting my kid to bed. If you don't have a company computer, you can still make it hard to work past work hours by having different user accounts in the same computer or logging out of your work email. Same applies to your cellphone. I turn on night mode; I disabled all notifications. I do all of that and I even went as far as uninstalling slack from the cellphone. If someone really needs to reach me after my work hours, they have my phone number.

After that, I go and do my come back home routine. Maybe that will be changing to cozier clothes, doing a bit of meditation or spend some time with my kid. The idea here is that I do something to create a separation from my previous mindset of working back to an at-home mindset.

I think it is also important to dedicate time to yourself and respect that time. You should create clear time boundaries between work and personal life. Something I didn't do before working remotely, but that I do nowadays, is putting my lunch break in my calendar. This way I am sure that I am taking my lunch break and that no one will put a last minute meeting when I was about to take it.

Similarly, I added to my calendar when my day is over. I am lucky to work at a very humane company, where I am allowed to finish early some days to pick up my kid from school. By adding that to my calendar I am sure that no one will put a meeting on those hours and that I can dedicate that time to the other things that matter to me, like my family and my own personal well-being. This not only helps me, but also signals to others that I am not available.

I hope this will help some of you, like it helped me during the last year and remember to respect your own time and your own personal well-being. Remember to create boundaries. Remember to leave work at the home office.

Last week I talked about "Less is more" and how you should not add code because you might need it in the future. Today, in our efforts to simplify code and to do more with less, I want to talk about deleting existing code.

First of all, deleting code is hard. Deleting code to simplify it or to completely remove it, can cause all kinds of issues, so before you start deleting code you should ask yourself should I remove this code? In order answer this, I really like to think about a quote from Chesterton. If you are curious, you can listen to the quote in the end of this episode, but for now, let's consider a simplified version of it, adapted to the problem of deleting code. Here it goes:

Don’t ever delete code until you know the reason why it was wrote

If you remember, last week I deleted some frontend code for showing images, but before doing so I asked myself: Can I do this?

I asked myself: Why is this code here, if it is never used? In order to answer this, I went and looked into the backend code into the templates and into the existing code and only by looking at it I realized that the code in question was added for a future case that never happened.

Another way to understand the purpose of the code before deciding if you can delete it, is looking for documentation or tests. Tests are great documentation by the way. Not only do they show you how the code works in a controlled environment, but also they are often added to test edge cases or to fix bugs.

Sometimes even then, the answer is still not clear. In those cases I do a git blame and see why was this code added. If the blame shows me when the code was changed, but doesn't answer the why it was added, I go to the parent commit and redo a git blame. And I keep doing this until I figure out why was this code added in the first place, and if that is still a valid reason for it to exist.

Sometimes there is a valid reason for it to exist. For example, that code deals with an edge case; or it's there to fix a browser inconsistency; or it's not called directly in the code, but some abstract piece of code ends up calling it; etc. etc. etc.

But sometimes, the code is no longer valid. For example, someone forgot to delete it when refactoring; or you stopped using because your product no longer has this functionality; or maybe it's just a case of "We might need this in the future".

When that is the case, then go ahead, and delete that code, and remember, Less is more.

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road.
The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”.

Today I want to talk about a coding principle that I think really shapes the way I code. This principle is "Less is more".

Last week I was working on improving web vitals, namely on loading images on scroll. Usually I would just add the loading="lazy" attribute to the images and be done with it.

The thing is, on this particular page we used some legacy code to load the images that used divs and background images. This code used some complex logic, and it impacted our templates, the frontend and the backend.

As I was working on the frontend version of the code I noticed that a parameter was never used. My first reaction was to delete it, but before I could do that I had to check if the equivalent version of the backend code used it. Turns out it did. I proceeded to see if any of these functions was ever called with that parameter. Turns out they weren't, so I could safely delete the parameter and simplify the whole code.

This means that whoever implemented this code, did so thinking "What if we need this in the future?". As someone from their future who had to work on their code, I can safely say we don't need this, and we never did.

Whoever wrote that code spent time working on a future case that never happened, making their code more complex to use, harder to maintain, harder to read and harder to change. This code was 7 years old. By removing it I made life easier for me and for whoever has to work on it next.

So, next time you think "What if we need this?", remember that you don't need it right now, and that you can always add it later. Remember that if you add it, you are making your code harder to use, maintain, read and change for yourself and for others. Remember that less is more.