Working from home used to have something of a workplace stigma around it. Employers were seemingly sceptical of how you could be productive in such a distracting environment. Needless to say, it's been proven it can be done, but what I wasn't expecting is how it would be the catalyst for an actual increase in productivity. Let's take a look at some of the factors which contributed to this.

Track your productivity

The first step on any great transformative journey is to gather data. Gather data of where you started from, what you do each step of the way, and ultimately where you end up. With something as subjective as productivity, this is hard to do. For me, I've had good results using RescueTime, a tool which shows me a summary of where I spent my time on any given day.

As they say, hindsight is 20/20. Having this kind of information available makes it easy to reflect and see where you wasted time, and where you can win some extra productivity.

(Whenever I see my stats, seeing how long I spend on Slack per day is a bit jarring at first, but then I remember that on average, office workers spend about 28% of their day on email.)

Tracking where your time is spent isn't a step you should skip. It's like training your body. If you are trying to lose 10kg but never set foot on the scales, how will you know if it is working?

If you are trying to boost your productivity, but have no way of measuring it, then good luck to you.

Avoid multitasking

Humans are good at a lot of things, but generally not multi-tasking, or remembering lots of small things. This leads to a well-known problem called "context switching", where your productivity will effectively plummet when you try to switch between multiple tasks.

This happens for a few reasons, but essentially, the "context" that you create around a task consists of lots of small pieces of information which you need to keep in your head to complete the task. If at any point, someone or something interrupts your tasks, all of these small bits of context are at risk of being lost. Even if the distraction is only a minute long, the cost of switching between tasks will make the impact much greater than just 1 minute.

According to Todd Waits

[...] Switching between projects requires an operational overhead for the team member to figure out where he or she left off, what needs to be done, how that work fits in the project, etc. Once a team member is assigned five projects, his or her ability to contribute to any given project drops below 10 percent, with 80 percent effort being lost to switching between project contexts.

The effects of context switching are well known and impossible to conquer. No matter how good you think you are when it comes to multi-tasking, chances are, you are giving yourself far too much credit. The only way to properly combat the effects of context switching is to remove it from the equation as much as possible.

Carl Newport's excellent book "Deep work" takes a deep dive into this topic and expands on systems which you can use to get the most out of the tasks that matter. If you're going to take anything away from this article, let it be this.

Don't multitask. It doesn't work.

Externalise everything

This was the big one for me.

It's easy to say "Don't multitask" I know. In practice, it is a lot harder, because even if you don't plan to do it, all it takes is an errant Slack message and then Boom, context switched. (It's worth noting, RescueTime has an awesome Slack integration to mute notifications during focus time. Killer feature)

How, then, should we solve this? After listening to Chris Bailey's "The Productivity Project", where he touches on the benefits of externalising your todo list, I became a little bit obsessed with lists. At first, it was exactly how Chris suggested it. If you have something you need to do, write it down, so you don't have to think about it anymore, essentially.

Eventually, this evolved into something of a rolling "work journal". I tried a few tools and ultimately settled on Notion (but you could use anything really).

The idea is simple. We know we will be interrupted, and we know that when we are, it will tank our productivity because we will lose all the little bits of context in our head.

What if we could externalise that context though?

When working through complex issues with a lot of moving parts, any time there was a new noteworthy development, such as a discovery, problem, or solution, I would make a note of it. It doesn't need to be too detailed; it is just a note to your future self so that when you are inevitably distracted, your notes should contain all the information you need to pick up right where you left off.

This information could be your current challenges you are trying to solve, todo items of what you still need to complete, or even just small anecdotal quirks about the system you are working with, that you don't want to dedicated mental space to remember, but can't afford to forget.

It doesn't sound like it should work half as well as it does.

Employing this system, I've been able to largely mitigate a lot of the burden I've typically suffered when it comes to context switching. I don't have to worry about taking a lunch break and losing my place. I don't have to dread every incoming slack message, and I am confident that when we return to the office in force, I won't have to worry as much about that casual tap on the shoulder causing my delicate mental house of cards to come crashing down around me.

If this has given you some ideas to boost your productivity, or if you have some tricks of your own, I'd love to hear from you. Leave a comment below, or follow me on Twitter for more content like this.

What is Imperative Programming?

According to our good friend Wikipedia, we have the following definition:

In computer science, imperative programming is a programming paradigm that uses statements that change a program's state.

In essence, this means we are issuing instructions describing both what and how we want the computer to perform its task. Imperative programming makes use of relatively low-level function and API calls to have more absolute control over the implementation details of how something is done.

An example of some imperative code is the following JavaScript:

const domNode = document.getElementById('foo');
domNode.style.color = 'red';

Here, we are telling the browser how to get a certain element, and how to change its color to red. What, and how.

What about Declarative Programming?

By contrast, declarative programming is a higher-level concept. We tell the system what to do, but not strictly how to do it. The implementation details are abstracted away from us, but they are still there. Make no mistake, you can't tell a computer what to do without something telling it how to do it, somewhere down the chain.

A simple example of declarative programming is the following HTML:

<div>
  <h1 id="foo">My Heading</h1>
</div>

We are telling the browser what we want it to do, but the actual implementation of how it interprets that HTML and renders it to our screen is abstracted away, and out of our hands.

React is Declarative

So when people say React as declarative, what does this mean for us? If you think about it, it makes sense. React shares a lot of similarities with HTML, and the way things used to be done. We can build entire, complex applications without ever having to do direct DOM manipulation for the most part. Sure, there are still some edge-cases where directly touching the DOM and using refs is the best approach, but those cases are few and far between.

Most of the time when writing code for React, you will be composing your applications by nesting components within each other. Some of these components will contain business logic, but even then, chances are you will seldom write imperative code.

Consider the follow React code:

const foo = () => {
  return <h1 style={{ color: 'red' }}>My Heading</h1>;
}

Here, we are telling react to make this component and give it red text, but the actual imperative calls under the hood to make this happen are not our concern. We tell React what to do, and it figures out how.

Other examples of Declarative Coding

Domain-Specific Languages (DSLs) are very often Declarative in nature. This is because the point of a DSL is to provide an interface where the available instructions make sense in the context of the domain. Consider SQL, a DSL for interacting with and querying databases. We could have some SQL like:

SELECT * FROM `users` WHERE `users.date_of_birth` IS NULL;

Here we are telling the database "get me all the users with a null "date of birth" field", and because the DSL is so finely tuned, it almost reads like plain English (although the same cannot be said for some more advanced queries).

The important thing here is that we told the database what to do, and the engineers who implemented the DSL on the backend have done the hard work of figuring out how to do it.

Depending on the situation there is always going to be a need for both declarative and imperative coding. Don't make the mistake of thinking you need to pick one and stick to it. Understanding the differences between these two paradigms, and how they come together is the first step in knowing when and where to use each.

"Innovative tech company looking for 10x developer to take the lead on a greenfield project."

But what is a 10x Developer? How is it possible for one person to do the work of 10? Are they just that good? Are the other 10 people just lazy?

Although some people would certainly argue otherwise, there is no such thing as a 10x Developer. It's just another buzzword used by recruiters and companies to hype people up. Suggesting that one person can perform the work of 10 others is a strange thing to get excited about.

It certainly isn't something that should be desired.

Doing 10x the work of the "average developer" would have a few problems with it if it were even possible.

1. The burnout would be extraordinary. If you are pushing that hard, you won't be able to sustain it for very long.
2. The single point of failure becomes much more dramatic. If your 10x Dev is sick and takes the day off, there goes most of your team's productivity.
3. You wouldn't be fairly compensated. Sure, if you really were delivering that much extra value, you might be compensated above average, but the chances of being remunerated 10x are almost non-existent.

What can we do instead?

As they say, don't put all your eggs in one basket. The real force multiplier in this industry is not single heroes who carry teams to victory. It is the teams themselves, and the potential they unleash through effective communication, collaboration, and prioritisation.

There is no real way to measurably determine how many "developer multiples" a given software engineer embodies, so don't even bother. Productivity will ebb and flow as the various factors and situations surrounding the team changes.

What is known, however, is that effective teams raise each other up, and deliver value greater than the sum of their parts.

An actual force multiplier that you can count on.

Let's take a look at each of these key factors:

Communication

Effective teams have stellar communication. This is especially vital during the extended work from home stint a lot of us have had around the world. Being in the office helps with communication, but the connectivity we enjoy in this modern world makes it entirely possible over the internet as well.

Communication matters because without it, things get lost in the details. Poor communication leads to mismanaged expectations, poorly understood requirements, and general frustration.

Collaboration

As we've established, you can't do it all by yourself, or you shouldn't, anyway. As part of a team, you must work together to deliver the best outcomes possible for your company and your customers. This means you need to deliver high-quality solutions, do doing that requires collaboration.

One person cannot know the best way to do everything, and no matter how good you are, you will make mistakes. Collaboration involves spending time doing pair programming, code reviews, demos, showcases, planning, and meetings.

These might seem like a waste of time.

You might think your time would be better spent writing code and fixing bugs.

This isn't the case. Although writing code and delivering results is important, you'll find it very difficult, almost impossible to do at scale without proper collaboration.

Prioritisation

The key to strong productivity in the eyes of your company is proper prioritisation. Most companies are in business to serve specific customers, and customers generally want certain things more than others.

Product Management and dealing with customer requirements is a whole art of its own, but at the intersection with Engineering, work is divided into tickets and sent over to be developed.

When it comes to software, the golden rule is that there is always more work to do than there is time to do it. The work is never "done", software projects end when their continuation is no longer in the interest of the company, not because all the work was finished. There's always more to do.

This means we need to be careful when selecting what we work on because with the effectively infinite workload, and finite capacity, it becomes a balancing act.

Focus on the most urgent work that is required to delight the target customer. If it isn't required as part of your "Minimum Lovable Product" for any given release, re-assess if it needs to be done.

There is no secret sauce to being a lone wolf heroic developer. The real magic happens when teams unite. It takes some time for new teams to gel, once they have become properly integrated, they are a force to be reckoned with. Whether you have a new or existing team, keep these points in mind and do what you can to improve cohesion.

There is no challenge a cohesive team cannot tackle.

There are a lot of people who don't consider web development to be true software development. There are even more who consider neither of these things to be Engineering, but that is not the case.

The following excerpt comes from Engineers Australia

Software Engineering is about creating high-quality software in a systematic, controlled, and efficient manner. It is an approach to designing software to maximise quality and reliability by treating it as a formal engineering process.

In other words, Software Engineering means approaching software design and development with engineering processes. Taking this approach helps the Engineer to ensure higher quality and reliability.

As with everything, there are varying degrees of skill and care with which you can approach the art of Software Development. It is possible to build a system without applying any quality gates, without doing proper design, and without having proper processes in place. If you're lucky, maybe some of the systems will even work when you're done. "Maybe" isn't good enough for businesses, though. "Maybe" has no place in enterprise software or any software at scale.

If you are a professional developer, you have a responsibility to your employers and your clients to deliver robust, quality software. That kind of software is made by applying engineering practices.

Ensure that you and your team are writing clean code. The code should be simple to understand by reading it for the most part. It should be well-documented enough that the more complex parts are still understandable. Your code should be well tested, and your tests should run in CI on every commit. Systems should be planned out and documented well before any code is even written. Plans and designs are easier and cheaper to change than code.

Use the planning phase to identify design flaws, and improve where you can. Coworkers should review your plans and designs the same as they do with your code.

Your team needs to communicate well, and often. Nobody expects one person to have all the answers. If you are unsure of how to solve a problem or approach a situation, don't be afraid to ask for help. Two heads are better than one, and effective communication and teamwork lead to well-engineered systems.

At the end of the day, it's not what you make, or what language you use that determines whether you are a Software Engineer. What matters is how you solve the problems you are presented with, and how you deliver value to your stakeholders.

So why should you care about this old text editor? You should care because it is pretty much ubiquitous, and is worth learning unless your heart already belongs to an alternative like emacs or even nano (if you really want to). Vim is scary at first. It does so much, and its shortcuts are not likely ones that you have used before. Even quitting out of the software is notoriously tricky for newcomers. Once you have learnt the basics though, they will be the gift that keeps on giving, and I'll tell you why.

Ubiquity

Vim is everywhere, even when it isn't. For instance, pretty much any Linux or Mac operating system you touch will have Vim installed and ready to go. With the advent of "Windows Subsystem for Linux" on Windows 10, Vim is now readily available on Windows as well (and could be downloaded anyway before this). Most code editors also have Vim emulation plugins available, so even if you don't want to use Vim directly, you can still get all of the benefits it brings from the comfort of the code editor or IDE you know and love.

Portability

With Vim, you learn the shortcuts and commands once and take them with you everywhere. As mentioned above, any code editor you use will have Vim bindings, and many coding websites like Codewars also support Vim mode. What this means is that all of your devices, editors, and environments can share the same keybindings easily. You don't have to manage the mental burden of memorising different shortcuts for different setups.

Productivity

The real secret sauce that makes learning Vim worthwhile is the productivity benefits it offers. A key principle of Vim is to deliver maximum productivity and functionality from the keyboard, without needing to move your hand to the mouse, and without needing to leave the home row so much on the keyboard. This is the main factor that leads to some of the weird shortcuts and keybindings, like :w to save instead of the more commonly used +s.

The main factor which drove me to become familiar with Vim was the portability so that I would be more productive while working in remote ssh environments. Once I started incorporating it into my daily workflow through the JetBrains IdeaVim plugin, and the corresponding VS Code plugin, I realised that the shortcuts and keybindings themselves were actually a huge time saver even when not working with remote systems. I quickly found myself using v and hjkl to select chunks of text instead of lifting my hand to use the mouse. I often use vim to save, search, replace, copy, paste, and delete text, even though VS Code and PHP Storm have all these features natively. The reason is simple. It's just faster and more natural to do it all in Vim.

Learning Vim is daunting at first, but give it some time, it will almost certainly be an investment which pays itself off in spades and serves you well for years to come.

The method examined here isn't just for iframes though, it will work in any case where you have access to another page's window object (so popups, and embedded web-browsers can join in on the fun too). Iframes are easy to play with though, so we will use them for this example.

Establishing 2-way communication between a child page and its parent can be done a few ways, but generally, the recommended approach is to use window.postMessage, if the technologies you are using support it (sorry IE users).

So let's create a basic page to act as our parent.

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Parent Page</title>
  </head>
  <body>
    <h2>Container</h2>
    <textarea id="output" cols="30" rows="10" disabled>awaiting data...</textarea>
    <div>
      <input type="text" id="field" value="type something fun here" />
      <button id="send">Send</button>
    </div>
    <div>
      <iframe
        height="500px"
        id="inner"
        src=""
        frameborder="0"
      ></iframe>
    </div>
  </body>
</html>

Here we have a very basic page. I will use a disabled textarea for showing data from incoming messages from the embedded page, and an input and button for sending messages to said page. Aside from that, we have the guest of honor, the iframe itself, currently with no source for it, because we need to make a page to embed first. Let's do that.

The Embedded Page

This is the page which will be running inside the iframe or popup. Structurally we will make something very similar to the parent page.

<!-- inner.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Embedded Page</title>
  </head>
  <body>
    <h2>Embedded</h2>
    <textarea cols="30" rows="10" disabled id="output">awaiting data...</textarea>
    <input type="text" id="field" />
    <button id="send">Send</button>
  </body>
</html>

Now we need to load this page into the iframe. The easiest way to do this is with something like the npm package serve. If you have npm installed, navigate to the directory where these files are located, and run npx serve.

You should get some output indicating which port the assets are being served on. In my case, they are being served on port 5000. When I visit http://localhost:5000 I will be served the parent page, index.html, and if I visit http://localhost:5000/inner.html, I will get the page I want to embed.

This means I can use that URL as the source for my iframe, so I will set that as the value of my src attribute now.

<iframe
    height="500px"
    id="inner"
    src="http://localhost:5000/inner.html"
    frameborder="1"
></iframe>

With that out of the way, if we visit the index.html page we should now see the iframe containing our other page below it. The next step is to write some JavaScript to facilitate communication between the two pages.

The JavaScript

Firstly, we need to write some code on the index page which will wait for the iframe to load, and the get the reference to its window object so that we can call the window.postMessage function on it.

We will also need to add an event listener to send a message when we click our send button, and an event listener to display any messages we receive from the embedded page.

In index.html, create a <script> tag before the end of your </body> tag which contains something like the following snippet.

<script>
      // assign variables with references to the DOM nodes we will be interacting with
      const output = document.getElementById("output");
      const iframe = document.getElementById("inner");
      const button = document.getElementById("send");
      const field = document.getElementById("field");
      // we will assign this value once the iframe is ready
      let iWindow = null;

      // This event listener will run when we click the send button
      button.addEventListener("click", () => {
        // don't do anything if the iframe isn't ready yet
        if (iWindow === null) {
          return;
        }

        // otherwise, get the value of our text input
        const text = field.value;

        // and send it to the embedded page
        iWindow.postMessage(text);
      });

      // This event listener will run when the embedded page sends us a message
      window.addEventListener("message", (event) => {
        // extract the data from the message event
        const { data } = event;

        // display it in our textarea as formatted JSON
        output.value = JSON.stringify(data, null, 2);
      });

      // Once the iframe is done loading, assign its window object to the variable we prepared earlier
      iframe.addEventListener("load", () => {
        iWindow = iframe.contentWindow;
      });
    </script>

That JavaScript alone won't do much though, we need to add the corresponding code in the embedded page, so add another script tag in inner.html containing the following

<script>
      // set up references to DOM nodes
      const output = document.getElementById("output");
      const button = document.getElementById("send");
      const field = document.getElementById("field");

      // create a variable for the parent window. We will assign it once we get the first message.
      let parent = null;

      // add an event listener to send messages when the button is clicked
      button.addEventListener("click", () => {
        // don't do anything if there is no parent reference yet
        if (parent === null) {
          return;
        }

        // otherwise get the field text, and send it to the parent
        const text = field.value;
        parent.postMessage(text);
      });

      // add an event listener to run when a message is received
      window.addEventListener("message", ({ data, source }) => {
        // if we don't have a reference to the parent window yet, set it now
        if (parent === null) {
          parent = source;
        }

        // now we can do whatever we want with the message data.
        // in this case, displaying it, and then sending it back
        // wrapped in an object
        output.textContent = JSON.stringify(data);
        const response = {
          success: true,
          request: { data },
        };
        parent.postMessage(response);
      });
    </script>

Save all your files, refresh your browser, and give it a try.

Using this method of sending messages opens up a whole new level of interactivity when it comes to popups, iframes, and embedded browsers, paving the way for some pretty cool interactions if you play your cards right.

Pastebin links to source:

• index.html - https://pastebin.com/A0HFp6c5
• inner.html - https://pastebin.com/ba6TNXK5

Gone are the days when the only way to get a quality education was via formal education institutes. Self-learning is bigger than ever, and it doesn't look to be going anywhere. This is thanks to the ubiquity of information provided by the internet. The vast wealth of quality information available online is mind-boggling. Having an effective method for gathering and synthesizing this information is crucial.

The following principles will help you to become a better student, and master the art of learning.

Have a goal

Don't set some nebulous goal like "Learn to code" or "Learn about Finance". These are too vague and have no defined success criteria. The most important thing about sustainable learning is setting a goal, and keeping it in sight.

Define what success would look like for you, and work backwards from there. You can always adjust this as you go, it isn't set in stone. Instead of "Learn to code", be more specific. "Learn enough JavaScript to make my personal website". Instead of "Learn about Finance", how about "Learn enough about personal finance to understand and put in place an effective monthly budget".

Try to keep the scope of any single goal small so that it remains achievable. Don't decide to "Learn Nuclear Physics" and then give up after a week when you realise what a massive undertaking that is.

Know how you will use this information

Human brains are a funny thing. They are capable of storing vast amounts of information, but only when the circumstances are right.

Synapses are the physical representation of memory in your brain. They form and strengthen through use and repetition. To keep information and store it for long-term use, you need to build synapses. This process is easier when the information you are trying to store is relatable. If you are learning something new, with no frame of reference for how it will help you in the long run, or how it relates to what you already know, forming new synapses and linking this information into your existing memories will be harder.

To combat this, having a plan for how you will use this new information, and where it fits into your knowledge and skill set is important. If we take a look at the earlier example of "Learn enough JavaScript to make my personal website", we can see the context for this information right there in the goal. You want to make a website. You know what a website is and how they work from a high level, but now you want to dig in and learn the inner workings. Having this frame of reference will allow you to construct a more robust mental model, and keep the information far easier than if you dive into the deep end and have no way to build the information upon what you already know.

Take Initiative

As with anything worth doing, the key to success is consistency. Nobody can learn for you or force you to learn. Your learning and development is your own responsibility. You may be fortunate enough to have resources made available to you to assist you in your endeavour. Some companies offer workplace L&D programmes. If yours doesn't, don't fret. There are enough free and affordable resources available that it is a non-issue. One thing which you might be lacking is time.

A lot of us lead busy lives, and finding a chunk of time to dedicate to learning can be tricky. For some people, waking up at 4 am is an option. Maybe negotiating with your boss to dedicate some time to learning is a possibility. Whatever your situation, there is a way you can make it work. If you resolve to better yourself, you will find the way that works for you.

Everything in moderation

Too much of anything is bad for you. This is true for physical exercise, and mental exercise too. Make sure that you balance your learning efforts with adequate rest and recovery time. We know synapses are important for forming and retaining memories and skills. Sleeping is an important part of the Synapse creation and maintenance process. When we sleep, our minds and bodies undergo important routines to make sure everything is in working order. Our brains clear out built-up waste products and strengthen new and existing synapses. Without sleep, your learning capacity plummets. Do not take time out of your sleep cycle to focus on learning, find the time somewhere else if you can.

This barely scratches the surface of the wonderful world of self-learning, but hopefully, it is enough to inspire you to take the leap, and actively work towards cultivating knowledge of your own accord.

These are 5 methods and principles you can employ today to start seeing immediate returns in your productivity.

Be deliberate in what you want to achieve

There is no way to know how productive you are if you have nothing to measure against. One of the biggest boosts to productivity you can get without having to do much at all is to set deliberate goals for what you want to do today and this week.

At the start of each week, take a moment to think about 3 things you want to have ticked off by the end of Friday. These should be high-level items, and your daily objectives will help you meet these goals.

At the start of each day, consider what you have accomplished so far this week, and what you would need to do today to stay on track. Write down 3 objectives somewhere (I prefer a physical medium, but apps like Sunsama work great for this too). As you go through the day, when you finish a goal, tick off the item.

It can take a bit of calibration to get a good feel for how big these tasks should be. I found myself writing down far too much at first. I was lucky if I was able to finish the first item on the list. After about a week of tweaking, I’ve reached a scope that works well for me. This technique is invaluable when it comes to projecting how much work I will get done in a week, and making it happen.

Don’t write perfect code

Not straight away, at least. Many developers have fallen prey to the temptation to write perfect code in a single go. It rarely happens. Think of writing code the same way you would draw a picture. Start with a rough outline of what you want, and iteratively add details until you end up with something great.

Leonardo da Vinci didn’t paint the Mona Lisa by perfecting her head before moving on to her neck, he worked through countless iterative refinements over the whole image.

A good principle to help remember this is the “3 E’s of code”

• Effective — Write the code solve the problem
• Efficient — Improve the code to make it more optimised
• Elegant — Refine the code to make it beautiful (don’t skip this step. Efficient code isn’t worth much if no one can read it)

In that order. Don’t start the next step until the previous one is complete.

This methodology ties in well with the next point.

Use TDD wherever you can

Test-Driven Development is great. It is basically a free productivity boost. Writing your tests as you go and refactoring code once it passes fits in perfect lock-step with the 3 E’s mentioned above. Don’t write your tests after you are finished with the code. If you do this, one of two things are likely to happen:

1. You will be told to skip the tests and move on
2. If you do write the tests, you will base them on the output of the code, and if you have bugs, so will the tests

Writing tests as specifications — distilled business requirements — ensures that your code is working as you write it and that the testing cannot be skipped. This results in higher quality work, fewer bugs, and less cause to come back and rework things later. If that isn’t a productivity gain, I don’t know what is.

Work in batches

A fact of life for most jobs is that you will often receive small tasks which people ask you to do. Being a developer is no different, and depending on your role you might get a couple of these a week, or dozens of them per day!

The key thing here is that many of these tasks are not urgent at all, and can be delayed without any adverse impact. If you delay enough similar tasks, you will be able to group them all together and action them all at once. This approach of doing the work in batches has various benefits. On the one hand, you are reducing the amount of context-switching you do, so you will naturally get productivity gains there. You will also be able to consolidate the setup and teardown overhead associated with small tasks. In most cases, the setup work required to do one task is the same as the work required to do 10 similar tasks. consolidating this overhead can save you a lot of time which could be better spent elsewhere.

Be Relentless

Perhaps the most important thing when it comes to getting stuff done. Sometimes you have to just power through. Using the other tactics described above will put you in a position to identify the work which needs to be done, and give you tools to do it efficiently, but at the end of the day, you just have to do it. I set myself a hard requirement of AT LEAST checking off the first item on my 3 item list every day. On good days I can get two or three high-level items checked off, but if you check off one meaningful objective each day — as long as you have set yourself valuable targets — you will be smashing out work and ticking boxes like nobody’s business.

Why is consistency important?

Consistency is crucial when it comes to code quality because consistency leads to predictability. A solution with a high degree of quality will be predictable in the way it functions. You will be able to look at code, and without any domain knowledge, you should have a pretty good idea what’s going on. To quote Robert C. Martin — author of the excellent “Clean Code” — “You know you are working on clean code when each routine turns out to be pretty much what you expected”.

Many aspects inform the predictability of the code. One of the most commonly focused aspects — with good reason — is tests and testability. Tests can be considered the ultimate manifestation of predictability. They describe the behaviour of the code to the reader in a reliable way. It provides predictability in the extreme, which is why tests are so valued.

Consistency has a similar effect. When your code has standard naming conventions, consistent indenting and spacing, and standardised architecture and interface, It is easier to work with and can be developed faster, and with greater confidence.

How can consistency be improved?

There are several vital factors which you can focus on when it comes to improving code quality through consistency.

Spacing and Indenting

This one might seem reasonably benign — especially in languages like PHP and JavaScript where the spacing and indenting don’t have any functional impact — but do not underestimate the benefits of well-formatted code. When code is formatted consistently, the readers get the advantage of being able to read and understand the code with greater ease. This benefit is the same one you get when you read a well-structured webpage or article. The visual flow of information — while not affecting the content directly — changes the way the data is perceived and ingested. Consider this first example:

JavaScript without whitespace and indenting

A simple example, but already we can see that with the formatting stripped away, it is hard to read at a glance. Let’s see what happens when we add some spaces.

Just like syntax highlighting, spacing and indenting can convey meaning. It can tell the viewer about how the code they are looking at will behave, but only if you let it. This aspect of code style is very subjective, so work with your team to find a spacing and indenting style which everyone is happy with, and strictly enforce it with tools like eslint, or whatever linting tool supports your language of choice.

Variable Naming and Casing

There are many different ways to name variables. From the hard to understand single-letter variables, through semantically named variables, there is a lot to consider.

The most important thing here is once again consistency. Work with your team to identify a standard which everyone is happy to follow. Don’t let this be a single person’s decision. It doesn’t matter how good your standards and style guides are if everyone hates following them.

Choose a casing style and stick to it. Don’t go around mixing snake_case and camelCase. It will be confusing and hard to follow in the long run. If most of your code has snake_case variables, and then just one variable is declared in camelCase, you might spend an undue amount of time trying to understand why this variable is unique, when at the end of the day there is no reason aside from inconsistency.

Architecture

Consistent architecture is a vital part of building quality into your solution. As mentioned above, the key benefit of being consistent is having things work pretty much how you would expect. It makes systems safe to depend on, and it makes it easier to make educated guesses about how the system works. Being able to make these educated guesses about how parts of the project will come together is crucial.

If you look at one part of the system and come to understand it, you might assume that other analogous parts of the system would follow the same rules. If you delve into these other systems only to discover that they are inconsistent, that is no good at all.

Consistent architecture is the sort of thing that needs to be planned. If you try to free-style it, you will likely end up with an inconsistent amalgamation of different patterns which don’t necessarily blend. To avoid this unfortunate state, you should have a pretty good idea what sort of application architecture you are going to go with before you start writing code. In this instance, it also doesn’t hurt to record architectural decisions using something like the aptly named Architectural Decision Records (ADR). This acts as a sort of documentation for the architecture and can help explain to others further down the line why particular decisions were made, what alternatives were considered, and other useful fragments of information like this.

Consistency leads to predictability, reliability, and ultimately quality. If you care about quality code, consistency in everything you do should be your first port of call.

Effective code reviews require striking a careful balance between technology and communication. Proper consideration needs to be given to the code, and any quality or functionality issues. Identifying issues is all well and good, but if you cannot deliver the feedback effectively and respectfully, it might do more harm than good to your team cohesion. The point of a code review is not to show that you are smarter than the other person, or to point out everything they did wrong. At its core, a code review is a collaborative process, and a quality filter to ensure that your team’s outputs are as good as they can be. After all, no one produces perfect work, no matter how much experience they have.

How, then, can we structure our code reviews to ensure that people are respected, and feedback is heard? The following is a set of soft principles which I have found to be effective when giving and receiving code review feedback. These aren’t silver bullets, and your mileage may vary.

Us against the problem

A principle which is more often applied to relationship advice, using this to frame all of your feedback is very effective. Your feedback should not target the author personally; it should target the issue in the code itself. Rather than writing “You did this wrong”, flip it around and focus on the problem itself. Of course, even if you do flip it around, it isn’t constructive to say “This is wrong”, which leads us to our next point.

Offer a solution, not just a problem

“This is wrong” is pretty much the epitome of unhelpful. Of course, in some cases, it might be something simple like a typo, but sometimes you will encounter implementation issues where the approach in question will not work. In these cases, it is important to offer a potential solution to the problem. After all, if the author knew the “correct” way of doing it, chances are if it is a deeper issue than a typo, they probably wouldn’t have included the issue in the first place. For this reason, rather than “This is wrong”, it is preferable to take the time to provide extra detail around why you believe it is an issue, and how it could potentially be solved. A potential piece of feedback following this principle might look something like “This will not work because of {reason}. Instead, consider {alternative}”.

Keep pull requests short

Ask any people-manager, giving good feedback is time-consuming. One issue which you have likely noticed if you’ve been involved with a variety of code reviews is that long pull requests don’t tend to get the same level of care and thought as their short counterparts. This isn’t always the case of course, but it is hard to argue against the fact that it is easier to give in-depth feedback on a small diff of say 60 lines than it would be to review one of 600 lines.

Naturally, all 600 of those lines are going to need to be reviewed at some point. By following good ticket and branch management processes, and decomposing work to small enough chunks, you can significantly reduce the cognitive burden of any given code review, which will result in more focus, and high-quality feedback.

Not only criticism

At its core, code reviews are essential feedback sessions. Because of this, you should avoid only ever giving critical feedback. Critical feedback is so vital to personal growth because it highlights what we can improve and do better, but it is only one side of the equation. To be an effective giver of feedback, you also need to offer praise when people do good things, which they should continue doing. To this end, when you see something particularly noteworthy in a code review, it can be a great idea to flag it as being well done.

Do note that the other principles still apply here. Do not praise the author directly. Telling someone “you’re great” is not good praise, because being great is not something which someone can do more of explicitly. Instead, focus on what they did and why it is noteworthy. Flagging someone’s approach to solving a particular problem and saying “I like this solution because {reason}, good work” is vastly more helpful, because it focuses on what the author has done, rather than who or what they are. Keep your praise — and your criticism — centred on the output, and the situation. Don’t make it personal in either case.

Don’t be a dictator

Developers are opinionated. They like doing things their way, and a lot of the time they don’t like the alternatives (look at vim and emacs). These opinions can become an issue when it comes time for code reviews if there aren’t some established boundaries around how feedback should be applied. I follow the idea that bugs and functionality issues are blocking issues, and I won’t approve a code review while these issues persist. On the other hand, if I raise feedback and it is something opinionated or subjective, It is reasonable for the recipient to reject the feedback in a lot of cases (unless it goes against your code standards or negatively affects code quality).

To effectively apply this point, the language you use in your comments will be pivotal. If someone has done something which you subjectively thing could be better, don’t tell them to change it, instead, prompt them to see if they would consider making a change. They might be open to the idea, and didn’t know the solution you do, so try phrasing your comments like “consider doing it this way instead, because {reason}”, rather than “change this because {reason}”.

If you don’t have code standards around this particular issue, and it isn’t technically wrong, they don’t have to change it, but you can still raise it if you think there is room for improvement.

Everyone has a say

As mentioned at the start, these are my personal preferences, and you might like some of them, you might hate them. This one is pretty important, in any case. Code reviews are a team process. It doesn’t matter how great and well designed your processes are if the people who have to follow them hate doing so. Creating the code review process and setting the parameters of what is acceptable and what isn’t should be a collaborative process. Everyone affected should have a say, and the process should be open to review and revision regularly. Designing the code review process as a team will ensure that you end up with a process which everyone understands, and is happy to follow.

These are just a few principles which I have found to be very useful in code reviews. Generally, if everyone approaches code reviews with mutual respect, and a desire to make the code as good as it can be, the benefits you will get from the whole process will be greater than if everyone tries to push their code-style agendas. Do you have any excellent code review tips I haven’t covered? Please leave them in the comments below!

According to Goodhart’s law, “When a measure becomes a target, it ceases to be a good measure”. One fantastic example of this would be using a team’s velocity — something which is traditionally measured — as a target. Following Goodhart’s law, velocity is very likely to rapidly become meaningless, as teams provide artificially bloated estimates so that their velocity is perceived as being higher than it would be with more “honest” estimates. If you are measuring something which can be manipulated, and treating it as a target, it will invariantly be manipulated.

Another example of a potentially lousy target metric is Utilisation. Of course, you don’t want your team to be under-utilised, but Utilisation above a certain point has a negative effect. Queue Theory tells us that as Utilisation approaches 100%, Lead Time approaches infinity, and this holds for software teams as well. If your planned work consumes 100% of your team’s capacity, what happens when unplanned work pops up? When your ultimate goal is to get software out, an arbitrarily long lead time is not ideal.

What, then, are we to measure? And what are we to use as targets? The following are a set of metrics which through research conducted by Forsgren et al. (2018) have proven to be reliable indicators of high performing teams, without falling prey to Goodhart’s law.

• Lead Time: The amount of time it takes to get a piece of work from the backlog, into production.
• Deployment Frequency: How often your team releases new code into a production environment.
• Time to restore: In the event of an outage, the amount of time it takes for all systems to restore to working order.
• Change fail rate: The frequency with which changes pushed to production result in a fault.

Another essential step in moving towards a more data-driven culture for your team is to make these metrics clearly visible for all to see. Put your metrics up on the wall, post them in slack on a schedule, do whatever you have to do to get the data into the spotlight. Constantly visibility of data informs decisions. If your data is trending in the wrong direction, this is an indicator that something needs to change.

There is a strong correlation between teams which were determined to be “high performers” and teams who adopted Lean management practices. Forsgren notes “At the heart of Lean management is giving employees the necessary time and resources to improve their own work. This means creating a work environment that supports experimentation, failure, and learning, and allows employees to make decisions that affect their jobs.”

It is worth noting that the targets described above are made more attainable by Agile and Lean approaches, such as reducing batch sizes. Reduced batch sizes offer multiple benefits, including shortened cycle times, more frequent feedback, decreased risk (and ease of reverting if something does go wrong).

When it comes to software, what do you measure? What have you had success with, and what have you moved away from? Leave your thoughts in the comments.

Static Typing

Essentially, static typing means that variable types are checked at “compile-time”, or before the code is executed.

Let’s look at an example in TypeScript:

function foo(a: number) {
    if (typeof(a) === 'number') {
        return 'number';
    } else {
        return 'not number';
    }
}foo(1);
foo('1'); // this will throw a compiler error, because it is not a number

Attempting to pass a string into the function foo after explicitly stating it accepts numbers, would cause it to throw an error such as

Argument of type '"1"' is not assignable to parameter of type 'number'.

Dynamic Typing

On the other hand, dynamic typing means that the variables’ types are checked on the fly, as the code is executed. Consider the following PHP code.

function foo($a) {
    if (gettype($a) === 'integer') {
        return 'integer';
    } else {
        // This will never be evaluated
        return 'not integer';
    }
}

echo foo(1); // integer

Depending on what value is passed into the function foo, the variable $a could technically be any type, and it is only known which one when the code is executed.

On the other axis of our Types quadrant, we have Strong and Weak typing. This is a bit more confusing because there is no universal consensus on what these terms mean, even though they get thrown around a lot. That being said, let’s try to understand them.

Strongly Typed

A lot of — but not all — developers agree that the essence of a strongly typed language is the fact that it converts a variable or value’s type to suit the current situation automatically. This means the "123" is always treated as a string and is never used as a number without manual conversion or intervention. Consider the following Python code:

z = x + y; // This will fail

This fails and returns the following error:

Traceback (most recent call last):
  File "main.py", line 3, in <module>
    z = x + y;
TypeError: unsupported operand type(s) for +: 'int' and 'str'

This is because the two variables which we tried to add together and assign to z were different types, and as the error says, adding an int and a string is not supported.

Weakly Typed

A weakly typed language is — as you might expect — the opposite of what is described above. The interpreter or compiler attempts to make the best of what it is given by using variables in ways that might seem confusing at first, but make sense once we understand what they are doing.

This means that in some situations — for example — an integer might be treated as if it were a string to suit the context of the situation.

To demonstrate, let’s try the above example again in a weakly typed language, like JavaScript:

const z = x + y; // 12

Note that this returned 12, instead of 3. This is because rather than performing a math operation as we requested, it treated both values as strings, and concatenated them together, resulting in the string “12”.

Wrapping up

Hopefully, this sheds some light on the minutia of language typing systems for those who do not already know. This is just a fundamental summary, and there is, of course, a lot more to it, but this should hopefully be a good starting point in understanding the finer details of your favourite programming languages.