Not at runtime, but at design time

image

Once upon a time, a wise old developer gave me advice, which until recently I did not really appreciate.

During the code review, we considered some function that required the program to display a list of letters A-Z (for example, a contact list with a set of buttons that allow you to jump to names starting with a certain letter).

So, a young successful programmer appeared. (Well, that was me.) I decided that instead of the hardcode of the array of all letters, it would be easier to write a for loop that runs from 65 to 90, and then generated the letters by the received character code.

In a JavaScript variant, it will look something like this:

for (let i = 65; i <= 90; i ++) {
 letters.push (String.fromCharCode (i))
}

A wise old developer looked at me and asked why I just did not hardcode this array. It does not look as if the alphabet would be different from one session to another. So why calculate it every time?

I was terrified. “How can you expect me to type every letter, like some kind of child. I am a professional software developer! "I have algorithms and data structures, and a mathematical coprocessor, for heaven’s sake!”

“Good,” he said. “Just use this functionality at design time to generate an array, and then copy and paste it into your working code.”

And then he said this:

“Avoid at runtime what you can do during development.”

Now let's be honest. My little for loop was not going to slow down the application. And modern machines will be so quick to understand this code that no one will even notice. But, as a rule, this is wise advice.

Too often, we write code that converts rarely changing data from one format to another with every request. Think about all the situations when we get content from a database that can change once or twice a year, format it and send it to the browser, without having to slow down the application. This is especially true for sites that are associated with a content management system.

This is why I think that in the coming years such well-known players as WordPress, Drupal, etc., will face a serious problem from such static site generators as Gatsby, Hugo or Jekyll, combined with a smooth build process, headless CMS , cheap CDN and fast continuous integration process.

This pattern was called JAMstack, which means "JavaScript, API, and the markup stack." And the results are very impressive.

The advice of a wise old developer sounds in my ears: “Avoid during program execution what you can do during development.” And over time, I realized that this advice has far-reaching consequences. Not only for software development, but for life too.

Recently, I read Ray Dalio’s remarkable book, Principles: Work and Life. The central theme of the book is that there are far fewer types of problems than real problems. Therefore, if you work on this in advance and find out how you will approach the specific type of problem that you are likely to encounter, then when it comes, you will be much better prepared to deal with it.

In fact, you can make better decisions faster by sorting your approach to various types of problems during “development”, when you are quietly thinking about life, and not during “execution”, when you are faced with an actual problem at the moment and panic.

Dalio implemented this technique by cataloging his approaches as a set of principles. He even went so far that he codified his decision-making process into a set of computer algorithms that he could test on a huge amount of historical data.

Given that he is a multi-billionaire and runs a very successful investment company, I would say that it worked. In fact, Wall Street is starting to hire more programmers than stock traders. So if you have doubts that you have chosen the wrong profession, there is a lot of evidence that the software eats the world.

  • I shared my own tips and lessons learned in a recent interview on the Developer On Fire podcast, which you can listen to here.
  • You can meet JAMstack at Jamstack.org
  • The Netlify blog also has a good overview of static site generators.
  • And here is an article about a specific stack that I recently reviewed and recommended that uses a combination of Gatsby, Contentful, Netlify, and Algolia as an alternative to the traditional CMS for the documentation site.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *