<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*rGeRLoujwUxdDn94iVFCZg.png" /><figcaption>RTK Query — Powerful data fetching and caching solution built on Redux</figcaption></figure><p>RTK Query is the latest addition to the Redux family and brings a much needed data fetching solution for apps using Redux to manage client side state.</p><p>GitHub: <a href="https://github.com/rtk-incubator/rtk-query">https://github.com/rtk-incubator/rtk-query</a><br>Docs: <a href="https://rtk-query-docs.netlify.app/">https://rtk-query-docs.netlify.app/</a></p><p><em>At the time of writing the library is in alpha so expect there to be changes.</em></p><h4>Overview</h4><p>The new library brings a simple data fetching API similar to <a href="https://react-query.tanstack.com/">ReactQuery</a> and <a href="https://swr.vercel.app/">SWR</a> that’s powered by Redux under the hood.</p><p>In my experience, working on large projects and reading online discussions from developers using Redux day-to-day the biggest issue is the massive flexibility and granular control you have with Redux (sounds like these <em>should</em> good things right?). For managing complex state this flexibility is amazing, but it also leaves you with quite a bit of boilerplate code when you’re doing data fetching.</p><p>Just take a look at this article <a href="https://blog.logrocket.com/data-fetching-in-redux-apps-a-100-correct-approach-4d26e21750fc/">https://blog.logrocket.com/data-fetching-in-redux-apps-a-100-correct-approach-4d26e21750fc/</a> pretty out of date (although only 2 years old) but it shows just how much code you had to write to handle just the basic states and caching in Redux.</p><p><a href="https://redux-toolkit.js.org/">Redux Toolkit</a> was great progress and really reduced the amount of boilerplate code that needed to be written but even in the official docs it’s hard to understand how to setup simple data fetching which most apps will need.</p><p>You’re probably thinking that any good developer would just create an abstraction at the beginning of the project but you’d be surprised how often that doesn’t happen for one reason or another. And even if you did, are you handing all the possible states? Are you handling polling, prefetching, re-fetching?</p><p>ReactQuery and other similar libraries really filled a gap in this area; provided a really small, simple and consistent way to fetch and cache data. They allowed developers to avoid writing this complex code for every project and focus on building the application.</p><p>RTK Query follows these other libraries (better late than never 😉) but with the weight of the larger Redux ecosystem behind it.</p><h4><strong>Where does it fit?</strong></h4><p>I think once RTK Query is production ready it will be a pretty good choice for any application.</p><p>For apps that just need <strong>simple data fetching</strong> you can use the library on it’s own with the ApiProvider that will bootstrap the Redux store for you.</p><p>Applications that are doing more <strong>complex client side state management</strong> can setup the library to <a href="https://rtk-query-docs.netlify.app/introduction/getting-started#add-the-service-to-your-store">work with their existing Redux store</a>. This is great as it allows an application to get started with RTK Query and not have to worry about implementing a separate solution or re-writing as they realise they need something more flexible… just setup <a href="https://redux-toolkit.js.org/">RTK</a> once you need it!</p><h4>Conclusion</h4><p>I’m happy to see the release of this much needed addition to <a href="https://redux-toolkit.js.org/">Redux Toolkit</a> and excited to try it out. Really impressed with the time taken to release this with the first commit being only a couple of months ago.</p><p>As with most of the Redux project the docs are fantastic and there’s an amazing community behind it which is a massive +1 🔥.</p><p>For any apps already using RTK or expecting to need the power of Redux this is a no brainer.</p><p>If you <em>only</em> need a data fetching solution then I would still suggest ReactQuery simply because, for now it is the more mature solution and provides a few more features out of the box with a smaller bundle size (<a href="https://bundlephobia.com/result?p=react-query@2.26.3">7.2kB</a> vs <a href="https://bundlephobia.com/result?p=@rtk-incubator/rtk-query@0.1.0-alpha.0">12.8kB</a> minified + gzipped).</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=392e1c8b78e3" width="1" height="1" alt=""><hr><p><a href="https://javascript.plainenglish.io/lets-review-rtk-query-392e1c8b78e3">A Review Of Redux Tool Kit Query</a> was originally published in <a href="https://javascript.plainenglish.io">JavaScript in Plain English</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

RTK Query — Powerful data fetching and caching solution built on Redux
RTK Query is the latest addition to the Redux family and brings a much needed data fetching solution for apps using Redux to manage client side state.
GitHub: https://github.com/rtk-incubator/rtk-query
Docs: https://rtk-query-docs.netlify.app/
At the time of writing the library is in alpha so expect there to be changes.
Overview
The new library brings a simple data fetching API similar to ReactQuery and SWR that’s powered by Redux under the hood.
In my experience, working on large projects and reading online discussions from developers using Redux day-to-day the biggest issue is the massive flexibility and granular control you have with Redux (sounds like these should good things right?). For managing complex state this flexibility is amazing, but it also leaves you with quite a bit of boilerplate code when you’re doing data fetching.
Just take a look at this article https://blog.logrocket.com/data-fetching-in-redux-apps-a-100-correct-approach-4d26e21750fc/ pretty out of date (although only 2 years old) but it shows just how much code you had to write to handle just the basic states and caching in Redux.
Redux Toolkit was great progress and really reduced the amount of boilerplate code that needed to be written but even in the official docs it’s hard to understand how to setup simple data fetching which most apps will need.
You’re probably thinking that any good developer would just create an abstraction at the beginning of the project but you’d be surprised how often that doesn’t happen for one reason or another. And even if you did, are you handing all the possible states? Are you handling polling, prefetching, re-fetching?
ReactQuery and other similar libraries really filled a gap in this area; provided a really small, simple and consistent way to fetch and cache data. They allowed developers to avoid writing this complex code for every project and focus on building the application.
RTK Query follows these other libraries (better late than never 😉) but with the weight of the larger Redux ecosystem behind it.
Where does it fit?
I think once RTK Query is production ready it will be a pretty good choice for any application.
For apps that just need simple data fetching you can use the library on it’s own with the ApiProvider that will bootstrap the Redux store for you.
Applications that are doing more complex client side state management can setup the library to work with their existing Redux store. This is great as it allows an application to get started with RTK Query and not have to worry about implementing a separate solution or re-writing as they realise they need something more flexible… just setup RTK once you need it!
Conclusion
I’m happy to see the release of this much needed addition to Redux Toolkit and excited to try it out. Really impressed with the time taken to release this with the first commit being only a couple of months ago.
As with most of the Redux project the docs are fantastic and there’s an amazing community behind it which is a massive +1 🔥.
For any apps already using RTK or expecting to need the power of Redux this is a no brainer.
If you only need a data fetching solution then I would still suggest ReactQuery simply because, for now it is the more mature solution and provides a few more features out of the box with a smaller bundle size (7.2kB vs 12.8kB minified + gzipped).

A Review Of Redux Tool Kit Query was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Review Of Redux Tool Kit Query

<p>As a developer you’ve probably seen or heard the famous quote;</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/638/1*4LGIZZadglcdwXSlGk4IzQ.jpeg" /><figcaption>Premature optimisation is the root of all evil</figcaption></figure><p>It serves as good advice to help you avoid overengineering and reduce time to getting user feedback. But, like most rules there’s subtalties to when it should be applied.</p><h3>The problem</h3><p>Let’s imagine… you create a component for a page your team is working on to display a small list of users.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/5b18b391fa53ff0ed79814bc78b9abb7/href">https://medium.com/media/5b18b391fa53ff0ed79814bc78b9abb7/href</a></iframe><p>As per the requirements, it takes a small list of users and sorts them by name in alphabetical order. The sort should be pretty quick since there’s only a couple of items in the array, no point prematurley optimising right?</p><p>Well, a few weeks go by and you come back from a day off, greeted by a defect with your name on. It describes your teams page being pretty slow.</p><p>You take a look and see that your UsersList component now looks a little different than when you last worked on it.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/c8d09ed7da30fb672d8e298ed97dcd23/href">https://medium.com/media/c8d09ed7da30fb672d8e298ed97dcd23/href</a></iframe><p>While you were off there was a requirment change and a junior teamate picked up the work.</p><p>Instead rendering a few users with a simple sort, the component now renders a large list of all users with a complex (and very slow!) sorting algorithm.</p><h3>Solution</h3><p>In a big team with rapidly evolving requirements as a senior engineer sometimes you need to use forward thinking and apply premature optimisations. This doesn’t mean over engineer everything, but <strong>take a moment to think what good small optimisations you can make to best set up the component you’re working on for future development</strong>.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/c06006411431172483bb0dd46d3b62e4/href">https://medium.com/media/c06006411431172483bb0dd46d3b62e4/href</a></iframe><p>Going back to our example, we need to realise that the doing a sort on a list of items is something that could potentially take a large amount of time; even if it doesn’t right now. As an optimisation we simply wrap the sort in a useMemo hook to stop it having to re compute the sorted array on each re-render, only doing it when the users array changes.</p><p>This doesn’t just set up a good foundation for future developers to work on but can also serve as a reminder for them to take a second to think about the performance of the changes their making.</p><h3>Generally applicable</h3><p>This type of beneficial premature optimisation isn’t just relevant to React, the idea of setting up good foundations to avoid performance issues can be aplied to everything from CSS to architecture.</p><h4>Warning</h4><p>Don’t spend hours working on adding nano second optimisations to all your code, just focus on the big, easy wins. It’s about balancing the time it takes to do the premature optimisation over the time it could save in the future.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=21207c05d088" width="1" height="1" alt="">

As a developer you’ve probably seen or heard the famous quote;
Premature optimisation is the root of all evil
It serves as good advice to help you avoid overengineering and reduce time to getting user feedback. But, like most rules there’s subtalties to when it should be applied.
The problem
Let’s imagine… you create a component for a page your team is working on to display a small list of users.
https://medium.com/media/5b18b391fa53ff0ed79814bc78b9abb7/href
As per the requirements, it takes a small list of users and sorts them by name in alphabetical order. The sort should be pretty quick since there’s only a couple of items in the array, no point prematurley optimising right?
Well, a few weeks go by and you come back from a day off, greeted by a defect with your name on. It describes your teams page being pretty slow.
You take a look and see that your UsersList component now looks a little different than when you last worked on it.
https://medium.com/media/c8d09ed7da30fb672d8e298ed97dcd23/href
While you were off there was a requirment change and a junior teamate picked up the work.
Instead rendering a few users with a simple sort, the component now renders a large list of all users with a complex (and very slow!) sorting algorithm.
Solution
In a big team with rapidly evolving requirements as a senior engineer sometimes you need to use forward thinking and apply premature optimisations. This doesn’t mean over engineer everything, but take a moment to think what good small optimisations you can make to best set up the component you’re working on for future development.
https://medium.com/media/c06006411431172483bb0dd46d3b62e4/href
Going back to our example, we need to realise that the doing a sort on a list of items is something that could potentially take a large amount of time; even if it doesn’t right now. As an optimisation we simply wrap the sort in a useMemo hook to stop it having to re compute the sorted array on each re-render, only doing it when the users array changes.
This doesn’t just set up a good foundation for future developers to work on but can also serve as a reminder for them to take a second to think about the performance of the changes their making.
Generally applicable
This type of beneficial premature optimisation isn’t just relevant to React, the idea of setting up good foundations to avoid performance issues can be aplied to everything from CSS to architecture.
Warning
Don’t spend hours working on adding nano second optimisations to all your code, just focus on the big, easy wins. It’s about balancing the time it takes to do the premature optimisation over the time it could save in the future.

Argument for Premature Optimisations as a Senior Engineer

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*BAUYIArrhtC1aJ5M" /><figcaption>Photo by <a href="https://unsplash.com/@williamtm?utm_source=medium&amp;utm_medium=referral">William Hook</a> on <a href="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>The modern version of the classic science fiction book 1984. People sat on their phones scrolling through their friends photos on Instagram. As they scroll, their camera watches their face as each post comes into view. Noting which ones encite a reaction, both positive or negative, which helps improve the algorithm that is becoming ever more personalised to them. The algorithm that ensures people are seeing the content that releases the most dopamine and in turn keeps them on the app longer…but maybe this isn’t just science fiction.</p><p>I see so many articles debating whether companies like Facebook are watching you through your phone camera, and as a developer I wouldn’t doubt it for a second. Knowing how simple it is to do and how much some companies rely on data, why wouldn’t they?</p><p>Let’s look just how easy it is to implement a very basic feature like this into a simple app.</p><h3>Setup</h3><p>For this example I’m using a basic <a href="https://docs.expo.io/">Expo</a> app. Simply install the cli and run expo init face-reaction-app and pick the blank managed template.</p><h4>The app</h4><p>To demo this we’ll create a basic app that lets the user scroll through photos. We’ll use some photos from <a href="https://unsplash.com/">Unsplash</a>.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/88de643d5e3f3c03483bca87a22f7ae7/href">https://medium.com/media/88de643d5e3f3c03483bca87a22f7ae7/href</a></iframe><p>Just run yarn start to start the app.</p><h4>The goal</h4><p>We want to make sure our users are seeing photos that make them happy. The best way to check this is to flag the images that make the user smile.</p><h4>Detecting a smile</h4><p>If you asked a developer just 5 years ago to detect if a person is smiling from a live video feed, they’d probably run a mile. These days it’s literally an out of the box feature using Expo.</p><p>Just run expo install expo-face-detector expo-camera and you’ll have everything you need.</p><h4>Implementing</h4><p>First, we’ll write the detector</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/1443d66db7862ce06701b3bb3278b3ea/href">https://medium.com/media/1443d66db7862ce06701b3bb3278b3ea/href</a></iframe><p>This code creates a new component that handles the camera permissions and renders the camera with the FaceDetector <a href="https://docs.expo.io/versions/latest/sdk/facedetector/#event-shape">settings</a>, locked to the front facing camera.</p><p>The camera component has a event handler that gets called when it detects a face with a number of <a href="https://docs.expo.io/versions/latest/sdk/facedetector/#event-shape">properties</a>. We can add simple logic here to call our isSmiling prop with true if the smiling probability is over 50%, otherwise call with false .</p><p>Now we can use our new detector component in the app to show a user a message when they smile.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/414fc4cfe5f908cffe2cc48f47aa9d5e/href">https://medium.com/media/414fc4cfe5f908cffe2cc48f47aa9d5e/href</a></iframe><p>And that’s it! An image gallery app that detects a user smiling at an image, in under 100 lines of code.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/600/1*FVlGka6Q-laSx1zqcRM-Fg.gif" /></figure><h4>Overview</h4><p>The app we just built only shows a message when the user smiles but we could easily call an API to flag the images that the user smiles at. We could use that data to add a wholesome feature that lets the user look back at all the images that made them smile. Or, we could use it alongside many other data points to continuously train an AI, that decides what content to show to keep the user scrolling for longer and show them more ads.</p><p>This is just a basic example, but with a bit of work there are so many other data points that you could get from the camera:</p><ul><li>Emotion detection</li><li>Age validation</li><li>Ethnicity</li><li>Gender</li><li>Whether the user shows the screen to another person</li></ul><p>Plus many more with similar techniques using the location services, and microphone.</p><p>Although this topic is no longer a question of whether it is possible or not, now the question focuses more around how ethical this is as a form of data collection and whether this practice should really be used or not.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=f523601d2eeb" width="1" height="1" alt="">

Photo by William Hook on Unsplash
The modern version of the classic science fiction book 1984. People sat on their phones scrolling through their friends photos on Instagram. As they scroll, their camera watches their face as each post comes into view. Noting which ones encite a reaction, both positive or negative, which helps improve the algorithm that is becoming ever more personalised to them. The algorithm that ensures people are seeing the content that releases the most dopamine and in turn keeps them on the app longer…but maybe this isn’t just science fiction.
I see so many articles debating whether companies like Facebook are watching you through your phone camera, and as a developer I wouldn’t doubt it for a second. Knowing how simple it is to do and how much some companies rely on data, why wouldn’t they?
Let’s look just how easy it is to implement a very basic feature like this into a simple app.
Setup
For this example I’m using a basic Expo app. Simply install the cli and run expo init face-reaction-app and pick the blank managed template.
The app
To demo this we’ll create a basic app that lets the user scroll through photos. We’ll use some photos from Unsplash.
https://medium.com/media/88de643d5e3f3c03483bca87a22f7ae7/href
Just run yarn start to start the app.
The goal
We want to make sure our users are seeing photos that make them happy. The best way to check this is to flag the images that make the user smile.
Detecting a smile
If you asked a developer just 5 years ago to detect if a person is smiling from a live video feed, they’d probably run a mile. These days it’s literally an out of the box feature using Expo.
Just run expo install expo-face-detector expo-camera and you’ll have everything you need.
Implementing
First, we’ll write the detector
https://medium.com/media/1443d66db7862ce06701b3bb3278b3ea/href
This code creates a new component that handles the camera permissions and renders the camera with the FaceDetector settings, locked to the front facing camera.
The camera component has a event handler that gets called when it detects a face with a number of properties. We can add simple logic here to call our isSmiling prop with true if the smiling probability is over 50%, otherwise call with false .
Now we can use our new detector component in the app to show a user a message when they smile.
https://medium.com/media/414fc4cfe5f908cffe2cc48f47aa9d5e/href
And that’s it! An image gallery app that detects a user smiling at an image, in under 100 lines of code.

Overview
The app we just built only shows a message when the user smiles but we could easily call an API to flag the images that the user smiles at. We could use that data to add a wholesome feature that lets the user look back at all the images that made them smile. Or, we could use it alongside many other data points to continuously train an AI, that decides what content to show to keep the user scrolling for longer and show them more ads.
This is just a basic example, but with a bit of work there are so many other data points that you could get from the camera:

Emotion detection
Age validation
Ethnicity
Gender
Whether the user shows the screen to another person

Plus many more with similar techniques using the location services, and microphone.
Although this topic is no longer a question of whether it is possible or not, now the question focuses more around how ethical this is as a form of data collection and whether this practice should really be used or not.

Apps are watching you

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*sCXU-_6D8ZTYjqJc" /><figcaption>Photo by <a href="https://unsplash.com/@flowforfrank?utm_source=medium&amp;utm_medium=referral">Ferenc Almasi</a> on <a href="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p><strong>Test Driven Development (TDD)</strong> is a widely used term in the developer community, but until you really understand why it’s useful, it can be hard to see the benefit. Simply put, TDD is writing tests to define how your code should work, then writing code to make those tests pass.</p><p>This article will go through the basic way to develop using the TDD process by writing a simple function that adds two numbers together.</p><p><strong><em>Note:</em></strong><em> This article expects you have a basic understanding of Jest.</em></p><h3>Setup</h3><p>We’ll set up a super simple project to get up and running, we won’t do anything fancy.</p><p>Start by creating a new directory /tdd-basics .</p><h4>Install the dependencies</h4><p>Let’s initialise our new project. I’m using yarn but npm works too!</p><pre>yarn init</pre><p>For running tests we’re going to need Jest, a simple JavaScript testing framework. Not too important for this project but Jest should usually be a dev dependency since it’s only needed when developing.</p><pre>yarn add --dev jest </pre><h4>Add test script</h4><p>To run Jest we need to create an script in our package.json</p><pre>{<br>  ...<br>  &quot;scripts&quot;: {<br>    &quot;test&quot;: &quot;jest&quot;<br>  },<br>  ...<br>}</pre><h4>Create files</h4><p>For this exercise we need two files, one for our tests and one for our code.</p><pre>touch sum.js sum.test.js</pre><h3>Writing the tests</h3><p>Before we can write any tests we need to import the sum function so we can use it.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/4acc00bbb0454cbb50532650de0d7593/href">https://medium.com/media/4acc00bbb0454cbb50532650de0d7593/href</a></iframe><h4>First test</h4><p>Our first test will be to check the happy path scenario to make sure the function does what it’s supposed to.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/8ddc2ea8d69aec3173e1d431ff4cef39/href">https://medium.com/media/8ddc2ea8d69aec3173e1d431ff4cef39/href</a></iframe><p>Very simple, we just call the function a few times and make sure the output is what we expect.</p><h4>Further tests</h4><p>We can’t just write tests to check the happy path, we need to cover any potential edge cases.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/bb02183c68fd1c8dfdc11b2b44da5a9c/href">https://medium.com/media/bb02183c68fd1c8dfdc11b2b44da5a9c/href</a></iframe><p>Our sum function should only take two arguments and those arguments should both be integers. We are putting down our requirements of how we expect the function to work in these scenarios into the tests.</p><p>If we run the test now you’ll see they all rightfully fail.</p><pre>FAIL  ./sum.test.js<br>  ✕ adds the first number to the second (2 ms)<br>  ✕ only adds the first two arguments<br>  ✕ non integer args should throw error (17 ms)</pre><h3>Implementing the function</h3><p>First we need to create the basic function.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/49dbb4590ea22db7e293b0395af2c1a2/href">https://medium.com/media/49dbb4590ea22db7e293b0395af2c1a2/href</a></iframe><p>Now we can run the tests again.</p><pre>FAIL  ./sum.test.js<br>  ✕ adds the first number to the second (2 ms)<br>  ✕ only adds the first two arguments (1 ms)<br>  ✕ non integer args should throw error (17 ms)</pre><pre>● adds the first number to the second</pre><pre>TypeError: sum is not a function</pre><pre>2 | <br>      3 | test(&quot;adds the first number to the second&quot;, () =&gt; {<br>    &gt; 4 |   expect(sum(1, 2)).toBe(3);<br>        |          ^<br>      5 |   expect(sum(2, 2)).toBe(4);<br>      6 |   expect(sum(10, 21)).toBe(31);<br>      7 | });</pre><pre>at Object.&lt;anonymous&gt; (sum.test.js:4:10)</pre><p>Still all failing! Looks like we forgot to export the function.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/01c98fe58dafb9f8d8fd37f1deab1936/href">https://medium.com/media/01c98fe58dafb9f8d8fd37f1deab1936/href</a></iframe><p>If we run the tests now…</p><pre>FAIL  ./sum.test.js<br>  ✓ adds the first number to the second (8 ms)<br>  ✓ only adds the first two arguments (1 ms)<br>  ✕ non integer args should throw error (7 ms)</pre><p>That’s a little better… we just need to satisfy the last test case.</p><p>We need to throw an error if the arguments aren’t integers. For simplicity we’ll use Lodash. Let’s add it as a dependency.</p><pre>yarn add lodash</pre><p>Adding the type check to the code.</p><iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/1b3d51df3e8ad49a4fdd09721111e94a/href">https://medium.com/media/1b3d51df3e8ad49a4fdd09721111e94a/href</a></iframe><p>We’re just checking if either of the arguments isn’t an integer and throwing a TypeError with a descriptive message.</p><p>Let’s run the tests one last time</p><pre>PASS  ./sum.test.js<br>  ✓ adds the first number to the second (10 ms)<br>  ✓ only adds the first two arguments (1 ms)<br>  ✓ non integer args should throw error (10 ms)</pre><p>And we’re done! We’ve written a simple function to add two numbers that satisfy our tests.</p><h3>Conclusion</h3><p>Test Driven Development isn’t just about writing tests, it’s a way of defining requirements for how some code should work, that you can then lean on as you write your code. This is just a simple example, but you can see how writing the tests before you start coding allows you to catch mistakes and develop quicker.</p><p>It also gives you the flexibility to change the implementation quickly without worrying that you’ve broken something.</p><p>TDD can seem like extra development work but it pays off in the long run with a reduction of regression defects, reduced developer time and no retroactive test writing.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=26b5a42acd2e" width="1" height="1" alt=""><hr><p><a href="https://javascript.plainenglish.io/test-driven-development-in-javascript-an-intro-26b5a42acd2e">An introduction to Test Driven Development in JavaScript</a> was originally published in <a href="https://javascript.plainenglish.io">JavaScript in Plain English</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

Photo by Ferenc Almasi on Unsplash
Test Driven Development (TDD) is a widely used term in the developer community, but until you really understand why it’s useful, it can be hard to see the benefit. Simply put, TDD is writing tests to define how your code should work, then writing code to make those tests pass.
This article will go through the basic way to develop using the TDD process by writing a simple function that adds two numbers together.
Note: This article expects you have a basic understanding of Jest.
Setup
We’ll set up a super simple project to get up and running, we won’t do anything fancy.
Start by creating a new directory /tdd-basics .
Install the dependencies
Let’s initialise our new project. I’m using yarn but npm works too!
yarn init
For running tests we’re going to need Jest, a simple JavaScript testing framework. Not too important for this project but Jest should usually be a dev dependency since it’s only needed when developing.
yarn add --dev jest 
Add test script
To run Jest we need to create an script in our package.json
{
  ...
  "scripts": {
    "test": "jest"
  },
  ...
}
Create files
For this exercise we need two files, one for our tests and one for our code.
touch sum.js sum.test.js
Writing the tests
Before we can write any tests we need to import the sum function so we can use it.
https://medium.com/media/4acc00bbb0454cbb50532650de0d7593/href
First test
Our first test will be to check the happy path scenario to make sure the function does what it’s supposed to.
https://medium.com/media/8ddc2ea8d69aec3173e1d431ff4cef39/href
Very simple, we just call the function a few times and make sure the output is what we expect.
Further tests
We can’t just write tests to check the happy path, we need to cover any potential edge cases.
https://medium.com/media/bb02183c68fd1c8dfdc11b2b44da5a9c/href
Our sum function should only take two arguments and those arguments should both be integers. We are putting down our requirements of how we expect the function to work in these scenarios into the tests.
If we run the test now you’ll see they all rightfully fail.
FAIL  ./sum.test.js
  ✕ adds the first number to the second (2 ms)
  ✕ only adds the first two arguments
  ✕ non integer args should throw error (17 ms)
Implementing the function
First we need to create the basic function.
https://medium.com/media/49dbb4590ea22db7e293b0395af2c1a2/href
Now we can run the tests again.
FAIL  ./sum.test.js
  ✕ adds the first number to the second (2 ms)
  ✕ only adds the first two arguments (1 ms)
  ✕ non integer args should throw error (17 ms)
● adds the first number to the second
TypeError: sum is not a function
2 | 
      3 | test("adds the first number to the second", () => {
    > 4 |   expect(sum(1, 2)).toBe(3);
        |          ^
      5 |   expect(sum(2, 2)).toBe(4);
      6 |   expect(sum(10, 21)).toBe(31);
      7 | });
at Object.<anonymous> (sum.test.js:4:10)
Still all failing! Looks like we forgot to export the function.
https://medium.com/media/01c98fe58dafb9f8d8fd37f1deab1936/href
If we run the tests now…
FAIL  ./sum.test.js
  ✓ adds the first number to the second (8 ms)
  ✓ only adds the first two arguments (1 ms)
  ✕ non integer args should throw error (7 ms)
That’s a little better… we just need to satisfy the last test case.
We need to throw an error if the arguments aren’t integers. For simplicity we’ll use Lodash. Let’s add it as a dependency.
yarn add lodash
Adding the type check to the code.
https://medium.com/media/1b3d51df3e8ad49a4fdd09721111e94a/href
We’re just checking if either of the arguments isn’t an integer and throwing a TypeError with a descriptive message.
Let’s run the tests one last time
PASS  ./sum.test.js
  ✓ adds the first number to the second (10 ms)
  ✓ only adds the first two arguments (1 ms)
  ✓ non integer args should throw error (10 ms)
And we’re done! We’ve written a simple function to add two numbers that satisfy our tests.
Conclusion
Test Driven Development isn’t just about writing tests, it’s a way of defining requirements for how some code should work, that you can then lean on as you write your code. This is just a simple example, but you can see how writing the tests before you start coding allows you to catch mistakes and develop quicker.
It also gives you the flexibility to change the implementation quickly without worrying that you’ve broken something.
TDD can seem like extra development work but it pays off in the long run with a reduction of regression defects, reduced developer time and no retroactive test writing.

An introduction to Test Driven Development in JavaScript was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

An introduction to Test Driven Development in JavaScript

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*I29_k3ALEaxc47un" /><figcaption>Photo by <a href="https://unsplash.com/@anniespratt?utm_source=medium&amp;utm_medium=referral">Annie Spratt</a> on <a href="https://unsplash.com?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure><p>Writing quality code is an art, an art that requires periods of patience and focus. When working on complex code, a developer has to keep many things in their head, from requirements to low level state, and to get to that productive state it takes time.</p><p>Unfortunately for most, losing that focus doesn’t take much. Having to answer a quick Slack message, although it may take only a few seconds, can be enough of a context switch to impact efficiency.</p><p>Communication is vital between everyone in a team, but the way most organisations handle it does not work well for developers. The solution is asynchronous communication.</p><h3>What is asynchronous communication?</h3><p>Most online communication in an organization is done synchronously, which mirrors how we do in-person communication such as meetings. <strong>Synchronous communication is when you expect a response to your communication immediately.</strong></p><p>Alternatively, <strong>asynchronous communication is expecting to get a response at some point in the future</strong>. For example, you send an email; I open and respond to the email several hours later.</p><p><em>For any developers, these concepts will sound very familiar as they are used as a way to describe how certain actions in code are handled.</em></p><p>Before we look at how we can move towards async communication we need to understand why synchronous communication has its downsides.</p><h3>The problems with synchronous communication</h3><figure><img alt="" src="https://cdn-images-1.medium.com/max/800/0*OVsVZR1t1RhuKX52" /><figcaption>Forms of synchronous communication — Credit to ec4u.com</figcaption></figure><p>While synchronous communication has many benefits and is something we do every day, it’s not the best form of communication for everything.</p><p>Working on a large team, with many people and many of those moving, it becomes hard to scale communication, especially for key individuals who have to be in communication with many different groups.</p><p>The advent of modern tools, such as email and chat apps, makes it easier but there is still a limit to the amount of real time chats a person can effectively manage.</p><p>Paired with the task of coding, a large amount of sync communications can cause a number of negative effects:</p><ul><li><strong>Reduced development time: </strong>As I talked about in the intro, the context switching required to reply to messages further reduces the already limited amount of time developers have to focus on their tasks.</li><li><strong>Low quality code: </strong>Interrupted focus when working on complex code, paired with less development time, can lead to the introduction of bugs and vulnerabilities.</li><li><strong>Increased stress: </strong>Developers can become worried about managers thinking they are not working or missing out on important discussions if they don’t quickly react to messages. Stress can really impact concentration and focus.</li><li><strong>Rushed discussions result in bad solutions:</strong> When constraining discussions on an issue to relatively short real-time meetings / chat conversations, you reduce the amount of time for people to give well-considered and well-researched contributions.</li></ul><p>An email notification can be just as distracting as someone walking over to you and starting a conversation.</p><h3>How can async help?</h3><p>Moving towards a more async process can have great benefits, both for a project and the developers.</p><h4>Better developer experience</h4><p>Developers are given time to do what they’re best at… writing code. They are saved from some of the juggling acts of delivering their work and being in constant communication.</p><p>They are given the space to tackle their work in a way they feel works best for them. This not only makes them more productive but also makes their day to day work more enjoyable.</p><h4>Improved planning</h4><p>Not only does async help improve the output from developers but it can also improve your planning.</p><p>Unlike sync communication, when working async you are not able to rely on last minute rushed chats to make decisions or ask questions. This forces you to plan ahead and ask the right questions enough in advance to allow for people to respond.</p><p><strong>Example:</strong> It’s the first day of a sprint and you are doing sprint planning, but some of your stories are missing information. If you’re working synchronously, you may ask the relevant people to join to get the necessary information… In async you can’t ask them to join; you have to be planning ahead. Those questions should have been asked beforehand so the information was already available when it was needed.</p><p>The above example not only reduces the people needed for the planning session and reduces the risk if they’re not available but it also reduces the time needed for the session. This leaves more time for the team to work on stories.</p><h4>Reduces points of failure</h4><p>No matter how hard you try, it is very likely that there will be a number of key individuals that are necessary to answer certain questions or make certain decisions. In a larger organisation these people may be required in many different meetings, so if you need to have them in your sync meeting you’ll have to find a time that will work for them.</p><p>With an async process, people like that don’t become bottlenecks for others. Most questions they are needed for can be asked of them in a longer, well-thought-out question and they can then take their time to respond.</p><h4>Better discussions</h4><p>Unlike the rushed answers or replies of ‘I’d need to check on that’ that come from real-time meetings, async allows the participants in a discussion to properly think through their responses. It allows for time to do more in-depth research and to properly consider all elements of the discussion.</p><h3>Balance between the two</h3><p>Async is great and effective, but in reality you need a mix of both for optimum communication. These following are times when you should probably stick with sync communication most of the time:</p><ul><li><strong>Back-and-forth discussions: </strong>Some discussions require a little more real-time communication to effectively argue your point or explain certain topics. Discussions that involve a lot of questions being asked can sometimes be done better in real-time. This kind of discussion would ideally be done as a precursor to something more formal.</li><li><strong>Final stage interviews: </strong>Determining if a potential employee is a good fit for a team is something that can’t be easily done without an informal person to person chat.</li><li><strong>Creative discussions: </strong>Creative and exploratory concepts can be hard to communicate through text.</li><li><strong>Sensitive topics: </strong>Certain discussions need a more personal side to them. Being given praise or informed about a promotion has much more impact when done in a personal way. <em>(Side note: some sensitive discussions may make people uncomfortable and they may prefer it to not be in person or over the phone. Consider the individual person where possible.)</em></li><li><strong>Team building: </strong>Teams work better when they get along and enjoy working together. Hackerthons, meals out and other non-work events can be great for helping teams collaborate better and for mental health.</li></ul><p>There also needs to be some structure around time to respond to a query, as it’s not practical to wait forever. A good idea would be to expect 48 hours to be a maximum expected time for a reply. This, alongside a system to determine priority, would work well.</p><h3>How to implement async</h3><p>Going async can seem like a daunting change, especially for very traditional organisations. Luckily, it can be incrementally adopted quite easily.</p><h4>Basics</h4><p>Start by being conscious of the amount of real-time communication that you are using to ask questions or have discussions. Each time you are about to use one of these, take a minute to think whether there is a way you can make this async. A couple of examples of this are:</p><ul><li>If you’re about to send a message to start a conversation regarding the status of a few stories, write one message asking all the questions you want answered instead.</li><li>If you’re about to schedule a meeting and know you need some people just to answer a couple of questions, add those questions into the meeting notes instead so those people can add their responses and then are no longer required for the actual meeting.</li></ul><p>Let your team know that regular questions from you do not need immediate replies, but work out a way to signal that a query is urgent. Slack and similar tools provide a way to mute notifications but still show them if the sender marks them as urgent.</p><h4>Further adoption</h4><p>To fully embrace async you will need to define a structured process for ways of working and communicating that can be easily referenced by anyone unsure whether they should use sync or async communication. As this is used, have constant feedback and look to see what areas are working well and which need further improvement.</p><p>Use tools such as issue, trackers, chat systems and email which have many great features to allow for async communication. Define the role that each plays in your process documentation and try to stick to it as closely as possible, flagging any need to diverge as a sticking point that needs improving.</p><h4>Specific to developers</h4><p>Encourage developers to block out time to focus on development or have a certain time of the day / sprint where you schedule most of the meetings that require developers to be involved.</p><p>If you work in teams, use your more senior / lead devs to be the representative for your team who can then pass the information on to the rest of the team.</p><h3>Remote working</h3><p>When combined with remote working, async unlocks even more amazing benefits. This is by no means a comprehensive list…</p><ul><li>Allows for developers to work at the time they feel the most productive. No more having to force yourself to fit into 9–5 work days.</li><li>Enables more distribution . You can hire people from places that would normally have too much of a time difference.</li><li>Lets developers easily fit work in alongside their personal life.</li></ul><h3>Conclusion</h3><p>It can be hard to change people’s traditional ideas of ways to work and their processes but asynchronous communication can be a great way to improve productivity, especially when working with developers.</p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=b7e25c7ea1f5" width="1" height="1" alt=""><hr><p><a href="https://medium.com/swlh/increasing-developer-efficiency-with-async-communication-b7e25c7ea1f5">Increasing developer efficiency with async communication</a> was originally published in <a href="https://medium.com/swlh">The Startup</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>

Photo by Annie Spratt on Unsplash
Writing quality code is an art, an art that requires periods of patience and focus. When working on complex code, a developer has to keep many things in their head, from requirements to low level state, and to get to that productive state it takes time.
Unfortunately for most, losing that focus doesn’t take much. Having to answer a quick Slack message, although it may take only a few seconds, can be enough of a context switch to impact efficiency.
Communication is vital between everyone in a team, but the way most organisations handle it does not work well for developers. The solution is asynchronous communication.
What is asynchronous communication?
Most online communication in an organization is done synchronously, which mirrors how we do in-person communication such as meetings. Synchronous communication is when you expect a response to your communication immediately.
Alternatively, asynchronous communication is expecting to get a response at some point in the future. For example, you send an email; I open and respond to the email several hours later.
For any developers, these concepts will sound very familiar as they are used as a way to describe how certain actions in code are handled.
Before we look at how we can move towards async communication we need to understand why synchronous communication has its downsides.
The problems with synchronous communication
Forms of synchronous communication — Credit to ec4u.com
While synchronous communication has many benefits and is something we do every day, it’s not the best form of communication for everything.
Working on a large team, with many people and many of those moving, it becomes hard to scale communication, especially for key individuals who have to be in communication with many different groups.
The advent of modern tools, such as email and chat apps, makes it easier but there is still a limit to the amount of real time chats a person can effectively manage.
Paired with the task of coding, a large amount of sync communications can cause a number of negative effects:

Reduced development time: As I talked about in the intro, the context switching required to reply to messages further reduces the already limited amount of time developers have to focus on their tasks.
Low quality code: Interrupted focus when working on complex code, paired with less development time, can lead to the introduction of bugs and vulnerabilities.
Increased stress: Developers can become worried about managers thinking they are not working or missing out on important discussions if they don’t quickly react to messages. Stress can really impact concentration and focus.
Rushed discussions result in bad solutions: When constraining discussions on an issue to relatively short real-time meetings / chat conversations, you reduce the amount of time for people to give well-considered and well-researched contributions.

An email notification can be just as distracting as someone walking over to you and starting a conversation.
How can async help?
Moving towards a more async process can have great benefits, both for a project and the developers.
Better developer experience
Developers are given time to do what they’re best at… writing code. They are saved from some of the juggling acts of delivering their work and being in constant communication.
They are given the space to tackle their work in a way they feel works best for them. This not only makes them more productive but also makes their day to day work more enjoyable.
Improved planning
Not only does async help improve the output from developers but it can also improve your planning.
Unlike sync communication, when working async you are not able to rely on last minute rushed chats to make decisions or ask questions. This forces you to plan ahead and ask the right questions enough in advance to allow for people to respond.
Example: It’s the first day of a sprint and you are doing sprint planning, but some of your stories are missing information. If you’re working synchronously, you may ask the relevant people to join to get the necessary information… In async you can’t ask them to join; you have to be planning ahead. Those questions should have been asked beforehand so the information was already available when it was needed.
The above example not only reduces the people needed for the planning session and reduces the risk if they’re not available but it also reduces the time needed for the session. This leaves more time for the team to work on stories.
Reduces points of failure
No matter how hard you try, it is very likely that there will be a number of key individuals that are necessary to answer certain questions or make certain decisions. In a larger organisation these people may be required in many different meetings, so if you need to have them in your sync meeting you’ll have to find a time that will work for them.
With an async process, people like that don’t become bottlenecks for others. Most questions they are needed for can be asked of them in a longer, well-thought-out question and they can then take their time to respond.
Better discussions
Unlike the rushed answers or replies of ‘I’d need to check on that’ that come from real-time meetings, async allows the participants in a discussion to properly think through their responses. It allows for time to do more in-depth research and to properly consider all elements of the discussion.
Balance between the two
Async is great and effective, but in reality you need a mix of both for optimum communication. These following are times when you should probably stick with sync communication most of the time:

Back-and-forth discussions: Some discussions require a little more real-time communication to effectively argue your point or explain certain topics. Discussions that involve a lot of questions being asked can sometimes be done better in real-time. This kind of discussion would ideally be done as a precursor to something more formal.
Final stage interviews: Determining if a potential employee is a good fit for a team is something that can’t be easily done without an informal person to person chat.
Creative discussions: Creative and exploratory concepts can be hard to communicate through text.
Sensitive topics: Certain discussions need a more personal side to them. Being given praise or informed about a promotion has much more impact when done in a personal way. (Side note: some sensitive discussions may make people uncomfortable and they may prefer it to not be in person or over the phone. Consider the individual person where possible.)
Team building: Teams work better when they get along and enjoy working together. Hackerthons, meals out and other non-work events can be great for helping teams collaborate better and for mental health.

There also needs to be some structure around time to respond to a query, as it’s not practical to wait forever. A good idea would be to expect 48 hours to be a maximum expected time for a reply. This, alongside a system to determine priority, would work well.
How to implement async
Going async can seem like a daunting change, especially for very traditional organisations. Luckily, it can be incrementally adopted quite easily.
Basics
Start by being conscious of the amount of real-time communication that you are using to ask questions or have discussions. Each time you are about to use one of these, take a minute to think whether there is a way you can make this async. A couple of examples of this are:

If you’re about to send a message to start a conversation regarding the status of a few stories, write one message asking all the questions you want answered instead.
If you’re about to schedule a meeting and know you need some people just to answer a couple of questions, add those questions into the meeting notes instead so those people can add their responses and then are no longer required for the actual meeting.

Let your team know that regular questions from you do not need immediate replies, but work out a way to signal that a query is urgent. Slack and similar tools provide a way to mute notifications but still show them if the sender marks them as urgent.
Further adoption
To fully embrace async you will need to define a structured process for ways of working and communicating that can be easily referenced by anyone unsure whether they should use sync or async communication. As this is used, have constant feedback and look to see what areas are working well and which need further improvement.
Use tools such as issue, trackers, chat systems and email which have many great features to allow for async communication. Define the role that each plays in your process documentation and try to stick to it as closely as possible, flagging any need to diverge as a sticking point that needs improving.
Specific to developers
Encourage developers to block out time to focus on development or have a certain time of the day / sprint where you schedule most of the meetings that require developers to be involved.
If you work in teams, use your more senior / lead devs to be the representative for your team who can then pass the information on to the rest of the team.
Remote working
When combined with remote working, async unlocks even more amazing benefits. This is by no means a comprehensive list…

Allows for developers to work at the time they feel the most productive. No more having to force yourself to fit into 9–5 work days.
Enables more distribution . You can hire people from places that would normally have too much of a time difference.
Lets developers easily fit work in alongside their personal life.

Conclusion
It can be hard to change people’s traditional ideas of ways to work and their processes but asynchronous communication can be a great way to improve productivity, especially when working with developers.

Increasing developer efficiency with async communication was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Increasing developer efficiency with async communication

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*NE-gNniorEDguCWG" /></figure><p>As developers, we tend to be very optimistic and we often give lower estimates than we should. Even when working on a project with little amounts of pressure, we usually underestimate the time or complexity of a task.</p><p>There are many reasons that cause us to underestimate, and most come down to the old saying:</p><blockquote>You don’t know what you don’t know.</blockquote><p>No-one can always anticipate every issue that might arise, and there will always be times when even the biggest overestimate will be wrong, but making sure to keep that simple quote in mind will help you make better judgements when estimating work.</p><p>Let’s look at a few of those areas that can trip you up and how to avoid them:</p><h4>Lack of understanding</h4><p>Whether it’s new technology, new codebase or new business requirements, there will always be times when you don’t know things. This is usually the reason why we underestimate and this is especially true for more junior developers.</p><p>The solution to this one is really simple — take time and <strong>clarify:</strong></p><ul><li>Define what needs to be done to complete the piece of work</li><li>Plan how you will go about doing the work with the technology being used</li><li>Identify any potential blockers that you might run into</li></ul><p>This isn’t going to be 100% effective every time, but spending that little bit of time can help you find some of those issues that you didn’t know about. Utilise the resources you have available. More experienced developers, or people with more detailed knowledge in a certain area, can provide guidance on potential issues that a lot of planning may not have prepared you for.</p><h4>Changing business requirements</h4><p>It’s pretty likely that whatever you’re working on depends on the business requirements, and sometimes those requirements have to change for one reason or another. This can be very frustrating, especially when the requirements are coming from people with limited technical knowledge who don’t understand how those changes affect the amount of work required<a href="https://xkcd.com/1425/"> (classic xkcd)</a>.</p><p>Since we can’t change the fact that requirements will always change at some point, we have to make sure to be clear with our stakeholders. Whether we’re working in a team or alone, we have to make sure to clarify what work is to be done as part of the task and communicate clearly that the estimate is for that work and any changes to requirements could affect that. If requirements do change, we should always take some time to properly estimate the impact of the change on our original estimate.</p><h4>Outside influences</h4><p>If you’re working in a team or using external services, you’ll know there can be the occasional downtime or bug. These can become blockers if they impact the work you’re doing, and if you’re dependent on someone else to fix the issue then there can be a big risk to your estimate.</p><p>There’s a couple of ways to reduce the impact when these blockers inevitably come up:</p><ol><li>Add in some padding to your estimate to allow yourself some extra time in case of small blockers.</li><li>Try and identify any potential blockers before estimating.</li><li>Raise the blocker to make the relevant stakeholders aware of risk to the work being delivered.</li></ol><p>There’s no bulletproof way to estimate complex work with so many possible unknowns, so we as developers need to take a little more time to consider the potential issues and make sure to communicate to stakeholders as blockers come up.</p><h4>Further reading</h4><p><a href="https://intersog.com/blog/tech-tips/how-to-estimate-software-development-projects-realistically/">https://intersog.com/blog/tech-tips/how-to-estimate-software-development-projects-realistically/</a></p><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=21bf24552862" width="1" height="1" alt="">

As developers, we tend to be very optimistic and we often give lower estimates than we should. Even when working on a project with little amounts of pressure, we usually underestimate the time or complexity of a task.
There are many reasons that cause us to underestimate, and most come down to the old saying:
You don’t know what you don’t know.
No-one can always anticipate every issue that might arise, and there will always be times when even the biggest overestimate will be wrong, but making sure to keep that simple quote in mind will help you make better judgements when estimating work.
Let’s look at a few of those areas that can trip you up and how to avoid them:
Lack of understanding
Whether it’s new technology, new codebase or new business requirements, there will always be times when you don’t know things. This is usually the reason why we underestimate and this is especially true for more junior developers.
The solution to this one is really simple — take time and clarify:

Define what needs to be done to complete the piece of work
Plan how you will go about doing the work with the technology being used
Identify any potential blockers that you might run into

This isn’t going to be 100% effective every time, but spending that little bit of time can help you find some of those issues that you didn’t know about. Utilise the resources you have available. More experienced developers, or people with more detailed knowledge in a certain area, can provide guidance on potential issues that a lot of planning may not have prepared you for.
Changing business requirements
It’s pretty likely that whatever you’re working on depends on the business requirements, and sometimes those requirements have to change for one reason or another. This can be very frustrating, especially when the requirements are coming from people with limited technical knowledge who don’t understand how those changes affect the amount of work required (classic xkcd).
Since we can’t change the fact that requirements will always change at some point, we have to make sure to be clear with our stakeholders. Whether we’re working in a team or alone, we have to make sure to clarify what work is to be done as part of the task and communicate clearly that the estimate is for that work and any changes to requirements could affect that. If requirements do change, we should always take some time to properly estimate the impact of the change on our original estimate.
Outside influences
If you’re working in a team or using external services, you’ll know there can be the occasional downtime or bug. These can become blockers if they impact the work you’re doing, and if you’re dependent on someone else to fix the issue then there can be a big risk to your estimate.
There’s a couple of ways to reduce the impact when these blockers inevitably come up:

Add in some padding to your estimate to allow yourself some extra time in case of small blockers.
Try and identify any potential blockers before estimating.
Raise the blocker to make the relevant stakeholders aware of risk to the work being delivered.

There’s no bulletproof way to estimate complex work with so many possible unknowns, so we as developers need to take a little more time to consider the potential issues and make sure to communicate to stakeholders as blockers come up.
Further reading
https://intersog.com/blog/tech-tips/how-to-estimate-software-development-projects-realistically/

Senior UI Architect

Dillon Erhardt

Community contributions

Recent activity

The state of Frontend

DevTubes

CodeUp Sheffield

Latest articles

A Review Of Redux Tool Kit Query

Argument for Premature Optimisations as a Senior Engineer

Apps are watching you

An introduction to Test Driven Development in JavaScript

Increasing developer efficiency with async communication

Developers suck at estimating

Expertise in the latest technologies

Weekly UI Newsletter