DEV Community: Stuart Dotson

How to find your forgotten software engineer tasks

Stuart Dotson — Fri, 14 Jun 2024 12:47:22 +0000

Do you ever wonder how many software engineering tasks have fallen through the cracks? How many times you've let your coworkers down?

It is extremely easy for this to happen, especially for mentions of your username scattered across various platforms like GitHub, Jira, Google Docs, Slack, and so many others. Each of these mentions represents a time when a coworker asked a question or shared a perspective squarely in your direction. If you like, or at the very least respect your coworkers, these mentions warrant some sort of response, either an emoji reaction or a comment.

Some other software engineering tasks that are easy to lose sight of:

Jira tickets assigned, especially if they are carryovers from the previous sprint and weren't moved over to the current sprint.
GitHub issues and pull requests you've opened for third-party libraries. These issues sometimes take months to be addressed, but it is worthwhile to keep tabs on them so you can help push them along.
GitHub review requests.
Other requests not captured by a Jira ticket.

The solution

BeyondDone has a tool called the Forgotten Task Finder.

This tool will guide you through connecting your GitHub and optionally your Jira account.

After connecting your accounts you'll see a summary of the findings. It even calculates the depth of disappointment you have created in your coworkers. After running through this tool, I learned I created 3 shot glasses full of coworker tears from ignoring their mentions, calculated assuming 0.5 ml tears, a crying rate of 15 ml/minute, and an average of 2 minutes of crying per forgotten mentions. Perhaps a little dramatic, but it drove the point home for me. Even if my coworkers aren't crying, I'm certainly making them feel unimportant by not addressing the comments they've directed at me.

After the summary, you'll see a full log of your regrets, including every unaddressed mention, as well as any open GitHub prs, GitHub issues, Jira tickets, and other tasks across your GitHub and Jira accounts.

Demo

Conclusion

The BeyondDone Forgotten Task Finder is an excellent tool to use to see all the software engineering tasks that have fallen through the cracks.

If you want to use this tool regularly, you'll need to reconnect your GitHub and Jira accounts over and over.

Thankfully, BeyondDone allows users to sign up for accounts. After signing up for an account, you only need to connect your GitHub and Jira accounts once. You'll then get access to a Todos list that gets updated with the latest information every minute. You'll also get access to automatically generated standup updates, a log of your activities, and the ability to add custom todos/accomplishments that exist outside of the GitHub, Jira, and Confluence platforms.

I use BeyondDone every day and it has turbocharged my ability to stay on top of things and sell myself better in standup.

I encourage you all to take a look at BeyondDone's features and sign up today. There's a 30-day free trial and no payment information is required up-front.

How to remember everything for standup

Stuart Dotson — Wed, 12 Jun 2024 13:38:59 +0000

Do you have trouble remembering your software engineering accomplishments and todos for your standup update? Perhaps you work hard. You juggle a lot of tasks. You help your coworkers. But when the daily standup meeting comes around, you can't seem to remember everything.

I'll review the advantages and disadvantages of some common standup preparation strategies so you'll never sell yourself short or forget a task again.

Option #1 Take notes

Many experienced engineers take notes whenever they switch to a different task or leave their desks. They write what they're currently working on, what they've done, and some thoughts on the current task they are working on. You can do the same.

I've encountered a lot of engineers who keep a journal and pen around, but you could also use a note-taking app like Notes, Obsidian, or Notion.

Reference these notes before or during standup.

Advantages

Full creative control. You can have whatever you want in your notes. You are limited only by your imagination.
The notes are wherever you want to keep them, whether that is in a physical journal or your favorite note-taking app.
If you are very particular, extremely disciplined, and extremely organized this may be the path for you.

Disadvantages

Every item needs to be manually entered or written down.
The notes are only as good as your consistency and discipline. If you forget to write something down, that thing won't be in your notes.
Your ability to quickly grok what's going on in your professional life for a standup update depends upon the quality of your note-taking organization.

Option #2 Use bookmarks

The second option involves setting up bookmarks in your web browser so you can quickly review what you've done 5-10 minutes before the standup meeting.

Take a look at our guide on how to track your GitHub todos and accomplishments and how to track your Jira todos and accomplishments. From there, you can set up some bookmarked pages to reference before the standup meeting.

Advantages

Uses dashboards maintained by GitHub and Jira.
Less reliant on self-discipline and superhuman organizational skills.

Disadvantages

The dashboards are not comprehensive and do not include all your todos and accomplishments.
The dashboards are platform-specific. You'll need at least two browser tabs to thoroughly review where you are at.
You'll have to look at timestamps to determine what has happened since the last standup update.

Option #3 BeyondDone App

The final option is the BeyondDone app, which offers you the ability to see all your todos and accomplishments in one special automatically generated standup update page.

There's even a copy/paste button so you can quickly drop the update in Slack.

BeyondDone allows you to configure the cadence and times of your standups so that the standup page always shows the relevant todos and accomplishments since your last standup meeting.

I use BeyondDone every day and it has turbocharged my ability to stay on top of things and sell myself better in standup.

I encourage you all to take a look at BeyondDone's features and sign up today. There's a 30-day free trial and no payment information is required up-front.

How to track your Jira todos and accomplishments

Stuart Dotson — Fri, 31 May 2024 12:37:18 +0000

Hi all. Last week we covered GitHub todos and accomplishments. This week, we'll take a look at Jira.

Jira presents many opportunities for tasks and accomplishments to fall through the cracks. Just like in GitHub, your coworkers can mention you in a comment on an issue assigned to someone else. Assigned tickets can sometimes fall off the Jira Board you look at with your team.

Rest assured that you are not alone. These are challenges faced by a lot of engineers. Thankfully there are solutions for these challenges. I'll describe the Jira todos and accomplishments most software engineers want to track then describe five solutions.

Jira todos and accomplishments

Here is a short list of Jira events and the todo action required from the software engineer:

Jira ticket assigned - Start research and investigation. Write code. Open a pull request. Get the code deployed to production.
Username mentioned in a comment - Respond to the coworker who addressed you in a comment.

In addition, there are Jira accomplishments that the software engineer should remember for standup and their reference:

Jira tickets created and updated
Jira tickets started
Jira tickets completed
Comments and discussions

Option #1 Watch your email inbox

The first alternative is to configure your notifications so that you receive notifications to your email inbox. The exact URL will depend on your Jira configuration, but generally the URL will be https://${your-subdomain}.atlassian.net//jira/settings/personal/notifications, being careful to replace ${your-subdomain} with your subdomain name.

Advantages:

Real-time notifications when things happen.

Disadvantages:

If there are more than just a few of these notifications, it can be easy to lose or forget about them, especially when mixed with your other email.
You still have to devise some sort of system for marking when items are completed. This could be with email filters, tags, or deletion.

Option #2 Jira Your Work page

The second alternative is Jira's Your Work page that you can find at https://${your-subdomain}.atlassian.net/jira/your-work. Here you can see a list of tickets you've worked on, viewed, starred, or been assigned.

Advantages

Built and supported by Jira.

Disadvantages

No sense of completion. You only see tickets that you've "worked on", whatever that means.
No sense of what is a lingering todo item.
Requires you to use this page as your main task management systems. Activity on other platforms, such as on GitHub, are not included.

Option #3 Jira Board

If you're a software engineer using Jira, you're probably doing using it within the context of a team and looking at the board for their team. The URL will look something like https://${your-subdomain}.atlassian.net/jira/core/projects/${project}/board, replacing the ${your-subdomain} and the ${project} with the appropriate values.

The Jira board makes it really easy to see the state of specific tasks, assuming they're represented by a Jira ticket. You can see what needs to be started, what is in progress, and what is completed. There is also a filter where you can toggle only the items you've been assigned.

Advantages

Built and supported by Jira.
The state of tasks is readily apparent.
Relevant GitHub pull requests can be seen by clicking on a specific issue.

Disadvantages

Only Jira tickets that fit the current criteria for the board are displayed. If your Lead or Product Manager forgets to move a ticket from one sprint to the next, the ticket is not visible.
Only work captured by a Jira ticket is displayed. Your comments and Jira ticket updates or ticket creations are not included.
Your tasks are mixed in with everybody else's on your team.
Informal tasks are not captured like being mentioned in a comment.

Option #4 JQL Queries

Jira has its own query language because of course it does. Atlassian gazed across a landscape of unimaginable splendor, a real cornucopia of options, and somehow saw a desert.

Look at the JQL documentation page to learn how to use the language. I'll see you in two weeks.

The page to construct your own JQL queries is at https://${your-subdomain}.atlassian.net/issues/DEMO-7?jql=.

You can use these queries to gather issues in a more detailed way:

Current todos: assignee = currentUser() AND statusCategory not in (Done)
Mentions: comment ~ currentUser() AND statusCategory not in (Done)

Here are some other queries for completed actions:

Your activity in a given range: (updated >= ${startDateIso}) AND (creator = currentUser() OR assignee = currentUser() OR assignee was currentUser() OR reporter = currentUser() OR commentedBy = currentUser()

Open up a few browser tabs, learn a bespoke query language, and explore to your heart's content!

Advantages

Built and supported by Jira.
Addresses many disadvantages of a Jira Board or the Your Work page.

Disadvantages

You have to learn the Jira Query language JQL.
You must open several tabs or navigate Jira's interface to find the JQL query page.
Information about updated Jira tickets and when you updated them is lost.
There's no way to tell if you've responded to a mention.

Option #5 BeyondDone App

The final option is the BeyondDone app, which lets you see all your Jira todos and accomplishments in one view.

BeyondDone goes beyond what is offered through the Jira platform in many ways. Jira mentions are displayed and marked done when you respond to the comment. All the Jira tickets you update are included. The diff and date of each update are included. Your Jira comments are displayed and mixed in with all your other activities for your reference.

BeyondDone also aggregates your todos and activity from GitHub. GitHub activity related to Jira tickets is grouped together. You can add your todos and accomplishments when you have items that don't currently have a BeyondDone integration. I've used these to remind myself to resolve Slack conversations or capture work not covered by a Jira ticket.

I use BeyondDone every day and it has turbocharged my ability to stay on top of things and sell myself better in standup and with my supervisor.

I encourage you all to sign up today. There's a 30-day free trial and no payment information is required up-front.

How to track your GitHub todos and accomplishments

Stuart Dotson — Wed, 29 May 2024 13:56:56 +0000

Have you ever seen a GitHub notification, made a mental note to circle back, and then later forgot where it happened or couldn’t find it? Ever get pulled away to attend standup and froze when you were asked what you did and what you still need to do?

Rest assured that you are not alone. These are challenges faced by many software engineers. Thankfully there are solutions. I’ll list the Github todos and accomplishments most software engineers want to track before presenting three solutions.

Github todos and accomplishments

Here is a short list of GitHub events and the todo action required from the software engineer:

Pull request reviewed, changed requested — Make changes.
Pull request reviewed, approved — Look it over, perhaps test again, and merge.
Pull request reviewed, commented — Address the comments.
Pull request in need of review — Request reviews in GitHub and/or some other communication medium.
Pull request with failing status check — Investigate what is breaking the status check and fix it.
Request for pull request review — Review the pull request.
Issue assigned — Work to resolve the issue.
Open Issue — Manage moving the open issue forward by responding to comments.
Mention — Respond to messages directed to them with a reaction or comment.

In addition, there are GitHub accomplishments that the software engineer should remember for standup and their own reference:

Pull requests reviewed, commented, approved, opened, and merged
Repos and issues created
Comments and discussions

Option #1 Watch your email inbox or phone

The first alternative is to configure GitHub notifications so that you receive notifications to your phone and email inbox.

Advantages:

Real-time notifications when things happen.

Disadvantages:

If there are more than just a few of these notifications, it can be easy to lose or forget about them, especially when they’re mixed with your other email and text messages.
The software engineer still has to devise some sort of system for marking when items are completed. This could be with email filters, tags, or deletion.

Option #2 GitHub Notifications

The second alternative is to look at the GitHub Notifications page. The filter option allows the software engineer to view only notifications of interest and decrease the noise on the page. There is also the ability to mark items done. For this option to work, the software engineer needs to look at the Notifications page daily and manually mark items as “done” as they complete them.

Advantages

Built and supported by GitHub.

Disadvantages

Very manual. The software engineer needs to mark things like open pull requests as “done” to remove them from the main Notifications view even when they’re obviously done, such as is the case for merged pull requests.
Requires the software engineer to use the GitHub Notifications page as their task management system. Might be ok if all their work is within the walls of Github, but if they do things in other platforms such as Jira, Slack, or Confluence, it means they’re juggling several different task management systems.

Option #3 BeyondDone App

The final option is the BeyondDone app, which allows you to see all your GitHub todos and accomplishments in one view.

BeyondDone goes beyond what is offered through the GitHub platform in many ways. GitHub todo items are automatically marked done and transferred to an Activity page, where it is organized by date or time. In addition, these items are included in an automatically generated standup update ready for your next standup. The Todos page displays the status checks for your pull requests, so you know when there is a failing build to investigate.

Beyond the GitHub platform, BeyondDone aggregates your todos and activity from Jira and Confluence. Github activity related to Jira tickets is grouped. You can add your todos and accomplishments when you have items that don’t currently have a BeyondDone integration. I’ve used these to remind myself to resolve Slack conversations or capture work not covered by a Jira ticket.

I use BeyondDone daily, which has turbocharged my ability to stay on top of things and sell myself better in standup and meetings with my supervisor.

I encourage you all to sign up today. There’s a 30-day free trial with no payment information required.

4 things I learned writing tests for my CLI

Stuart Dotson — Mon, 20 Apr 2020 19:34:51 +0000

I recently updated tests in my open source library get-open-prs. My goal was to get as close as I possibly could to 100% test coverage. However, there were a few obstacles I had to overcome to do so. get-open-prs is a CLI and has a lot of side effects like printing to the console or waiting for user input.

Stub out console.log

let consoleStub;  

beforeEach(() => {
    consoleStub = sinon.stub(console, 'log');  
});

afterEach(() => {
    consoleStub.restore();
})

// ...then later after executing function with console.log side effect.
assert(consoleStub.calledWith('there'), 'console.log should be called with argument 2');

Stub out a 3rd party module or your own

In my case, I was using Inquirer to print cool prompts to the console to get input from the user. Well, similar to how I did console.log\ in the previous tip.

const inquirer = require('inquirer’);
const inquirerStub = sinon.stub(inquirer, 'prompt');

inquirerStub.withArgs(question).resolves({
  prToOpen: 'pr-url-1'
});

assert(inquirerStub.calledWith(question), 'inquirer.prompt for pr question should be called');

I also implemented a dependency-injection pattern to build the main function orchestrating the various dependencies of printing output, getting prs, and updating configuration values. This makes testing this function a whole lot easier and more precise as I just test the business logic and not “how it is done”. The “how” is tested in other unit tests. You can see what I did here: https://github.com/sdotson/get-open-prs/blob/master/src/getOpenPrs.js

Vary how functions respond on successive calls

Sometimes functions were called multiple times with the same args, but with different results. Did I write crappy non-deterministic code? Not exactly but I did involve a source of entropy in the program: human input. Inquirer prints prompts to the console that is then responded to by our human entropy source. Sinon has this great chaining syntax to describe this scenario:

const inquirerStub = sinon.stub(inquirer, 'prompt');      
inquirerStub.withArgs(question)        
  .onFirstCall().resolves({          
    githubToken: ''        
  })        
  .onSecondCall().resolves({          
    githubToken: 'TOKEN'        
  });

The only downside is that that in the assertion part of the test, you can’t chain callCount to the result of calledWith(). So in the case of Inquirer.prompt(), which is essentially called for every single question, you’ll have to count all invocations instead of just the easier-to-read count for a given set of arguments. Something like:

assert(inquirerStub.callCount === 4, 'inquirer should be called twice for continue and twice for prs');

reset() and restore()

beforeEach(() => {
  sinon.reset();  
});

afterEach(() => {    
  inquirerStub.restore();  
});

One important function to remember is sinon.reset(), which resets both the behavior and history of all stubs. If you just want to reset a specific stub you can use stub.reset().

Another is stub.restore(), which is used to restore the original functionality to the stubbed function. You want your tests to be independent of each other and adding this to stubbed methods will help guarantee that.

If you’d like to learn more about sinon, take a look at the official documentation: https://sinonjs.org/releases/latest/stubs/

Python lists, dicts, and functions for Javascript Engineers

Stuart Dotson — Wed, 01 Apr 2020 03:06:43 +0000

I’ve been getting really into Python recently. There’s been times in the past where I’ve dabbled or built things in Python but something about this recent “build a microservice” project at work has inspired me to learn more and increase my expertise. That project has since left my team’s hands due to sudden company restructuring but I feel happy to pursue the world of Python in my own time for now. Here’s even more things I’ve learned.

For the curious, here’s my previous post: 7 Python basics for JavaScript Engineers.

Merging Arrays/Lists

In Javascript:

// spread two arrays
[...array1, ...array2]

// concat one array onto another
// does not mutate array1
array1.concat(array2)

In Python:

// mutates original list
list1.extend(list2)

// equivalent of spread operator for Python lists
combined_list = [*list1, *list2]

Merging Objects

In Javascript:

// merge multiple objects together
Object.assign({}, object1, object2);

// spread operator for objects is still ... in JavaScript
const mergedObject = { ...object1, ...object2 };

In Python:

// Python uses ** to spread dicts
merged_dict = { **dict1, **dict2 }

Shallow copying gotchas

In the above solutions, only shallow copies are created. If you modify deeply nested values on one, the other will change as well! That’s because objects and arrays more than a level deep are copied by reference and refer to the same place in memory. JavaScript and Python are very similar in this way.

For example in Python:

a = [{ "foo": { "bar": "foobar" }}]
b = [*a]
b[0]["foo"]["bar"] = "foo whoa”
print(a)// [{'foo': {'bar': 'foo whoa'}}]a[0] is b[0]
// True

I talked about this already in-depth in the JavaScript magic show post, but here’s a quick example:

const a = [{ foo: { bar: 'foobar' }}];
const b = [...a];
b[0].foo.bar = 'foo whoa';
console.log(a);
// [{foo: { bar: 'foo whoa'}}]
Object.is(a[0], b[0]);
// true

Most of the time this doesn’t matter, but if you need real deep copies of nested objects and arrays, you need something like copy.deepcopy in Python or immutability-helper for JavaScript.

Keyword and positional function arguments

In Python, you can give folks the option of using keywords for your function arguments or just the standard order position you may be more familiar with. I’ll give an example of each.

def my_func(arg1, arg2, arg3):
  return arg1, arg2, arg3

// called with keywords
my_func(arg1="arg1 value", arg2="arg2 value", arg3="arg3 value")

// called positionally
my_func("arg1 value", "arg2 value", "arg3 value")

You can even mix the different argument styles with the caveat that you cannot do a positional argument after a keyword argument.

This is ok:

my_func("arg1 value", arg2="arg2 value", arg3="arg3 value")

This is not ok:

my_func("arg1 value", arg2="arg2 value", "arg3 value")

In Javascript, every function argument is positional. You can get close to keyword arguments by having a object and destructuring like so:

const myFunc = ({  arg1,  arg2,  etc}) => {
  return [arg1, arg2, etc];
};

Default function arguments

Default function arguments work the same in JavaScript and Python.

JavaScript:

const myFunc = (
  arg1 = “arg1 default”,  
  arg2 = “arg2 default”
) {
  return [arg1, arg2];
};

Python:

def my_func(arg1="arg1 default value", arg2="arg2 default value"):
  return arg1, arg2

I hope this has been helpful for everybody and look forward to sharing more about my journey.

How I handled configuration in my Node CLI package

Stuart Dotson — Mon, 23 Mar 2020 02:10:13 +0000

Many folks in the United States are now working from home and social distancing. I am one of them. After cleaning, noodling on the guitar, reading, and pacing around for some time I decided to revisit an open source project I haven’t touched in a year or two: get-open-prs.

get-open-prs is CLI that allows people to quickly see the pull requests opened by their teammates from the command line. Not only that, it’ll allow you to quickly toggle through them with the arrow keys, and when you hit enter, your browser will automatically open that pull request. It does this by saving a Github personal access token and a list of Github usernames representing your teams. Of course this is overridable and changeable at any point.

I’d like to talk about the biggest change I made to this package, which related to configuration.

I moved away from environment variables for the Github usernames and token to a library called conf. Environment variables were a quick and dirty solution but not terribly user-friendly in my opinion. I had considered node-config as well, but it seems like that solution is more geared towards backend services and not CLIs. The biggest disadvantage is that node-config doesn’t work correctly for globally installed packages.

conf does work because it sets the configuration in a file that is in the operating system default location for application configurations. For mac that would be /Users/username/Library/Preferences. This is determined by a dependency called env-paths.

I added more prompts to automatically guide the user through setting these values for the first time and save them with conf. I feel that this makes this tool way more user-friendly.

The other change I made inspired was inspired partly by my experiences with Clean Architecture. I refactored the main function so that dependencies are injected into a higher order function that then builds the function I use for the app. There’s still more that I can do but I feel a lot more secure that this CLI does what it’s supposed to do with these tests. When I have time, I’d like to write more tests for some of those dependencies to get the code coverage up, and perhaps switch to typescript so I can more explicitly define some of the interfaces.

Check it out! I’m definitely open to feedback, suggestions, and of course, pull requests.

7 Python basics for JavaScript engineers

Stuart Dotson — Mon, 16 Mar 2020 19:38:31 +0000

I’ll be honest. My main expertise and experience is in JavaScript with Node and frontend frameworks like React. I took a Python Introduction to Computer Science course through EdX a few years back and have only really needed to use it sporadically since then. That all changed two weeks ago when a new project started at work. My team was tasked with rapidly getting ramped up on Python and writing a new back-end service in the language.

Here are 7 things I’ve learned so far writing in the Python language every day:

1. Python version management

I feel like it’s less common for folks to alternate between different versions of Node these days but the tool to do that in nvm. Python has competing solutions for this problem. Two of those are conda and pyenv with pyenv-virtualenv.

pyenv allows you to use different versions of python and and pyenv-virtualenv allows you to sandbox different environments with those different python versions so they don’t conflict. For a while pyenv and pyenv-virtualenv were working fine until one day I kept getting really cumbersome openssl issues preventing me from installing dependencies with pip.

I switched to conda. conda is both an environment and package manager. A practice I learned recently was to create a new environment for each project you are working on. So far no issues.

2. Python dependency management

In JavaScript, you are typically using a NPM package registry, using yarn or npm to download those dependencies to your local machine, and the package.json file to list the dependencies that need to be downloaded.

In Python the public package registry is the Python Package Index (PyPI)(https://pypi.org/), you use pip to download dependencies, and the list of dependencies are in requirements.txt and requirements_test.txt.

3. Python property/method reference

You can refer to properties in many different ways in JavaScript and you can use any of them regardless of context. You can refer to the assign property of Object with Object.assign or Object["assign"], the only real rule being that string property names are generally referred to with dot notation and number property names must use the bracket notation.

In Python dot notation and bracket notation communicates the relationship of the property to the object. Classes must use the dot notation and dicts must use the bracket notation. Don’t worry, Python will let you know when you make a mistake with AttributeError if you try to use dot notation with a dict and object is not subscriptable when you use bracket notation for a class property. Those errors are forever burned into my mind.

4. Python async/await

Finally something familiar to JavaScript folks and more or less works the same. In JavaScript async/await works out of the box assuming you’re using a recent enough version of Node. In Python you need to import in asyncio and make sure the async/await happens within the context of a created event loop. JavaScript also doesn’t allow you to await in a global context. This might change with the proposal for global await but for now you have to use await within the context of a async function.

5. Python types

Most of the JavaScript I write these days is with TypeScript. Python has the typing standard library package which can be extended with pydantic.

6. Python case

JavaScript favors camelCase. Python favors snake_case. I suppose you see a bit of both in out in the wild in terms of API JSON formats.

One way Python tackles this is you can use pydantic for your type models so that you can use the idiomatic snake_case in your Python service yet use camelCase for the output when you JSON serialize. Here’s one tutorial.

7. Python anonymous functions

In JavaScript, anonymous functions are declared like so: () => {}. You can assign this to a var const myFunc = () => {} or even declare and invoke in place as an immediately invoked anonymous function (() => {})().

In Python the equivalent is a lambda function:

def add_one = lambda x: x + 1

In the above example we are declaring a function that accepts argument x and returns x + 1. You might be wandering why on Earth this is called a “lamba function”. According to this informative article from Real Python, lamba functions have roots in something called “lambda abstractions” that were developed as a part of “lambda calculus” in the 1930s, which is one of the foundational building blocks of functional programming..

Conclusion

I hope to write a few more of these posts as long as I’m continuing to write Python at work and learning things. I’m enjoying it quite a bit, in a way that feels different than when I was in a similar situation learning Go for another service at work some time ago.

Javascript Magic Show: Mutability

Stuart Dotson — Thu, 27 Feb 2020 00:36:53 +0000

Ladies and gentlemen, boys and girls, welcome to the Javascript magic show!

Today we will explore a few mysterious and tantalizing feats of magic. Hold on to your socks as we dive into the first trick.

Magic Trick #1

Take a look at this box, completely empty, no trapdoors, no hidden pouches, just a regular ‘ole Javascript object.

const box = {}; 
console.log(box); 
// {}

Now if you take a look in our very stylish hat, it is also a regular run of the mill Javascript object.

const hat = box;
console.log(hat);
// {}

We’re going to place this bunny rabbit in the box, say a few magic words, and voila, the rabbit is going to teleport into the hat. Don’t worry folks, there’s breathing holes in the box. We’re not going to have an unconscious bunny on our hands.

box.rabbit = 'hi there';

“Abracadabra!”, I say as I wave my hands over the closed box.

What’s in the hat now? Any guesses?

console.log(hat);
// { rabbit: 'hi there' }

The rabbit is now in the hat! Truly incredible. How about we check what’s in the box?

console.log(box);
// { rabbit: 'hi there' }

Oh dear. This is a little disturbing. It seems that we’ve cloned the rabbit instead of teleporting it. Is it the exact same rabbit rabbit in the hat and box or is it two separate rabbits? We can check for equality to find out.

console.log(hat === box);
// true

gasps in the audience. The same exact rabbit exists in two places at once! In fact, according to this equality check, the hat and the box are the same thing. What manner of sorcery is this? Let’s go further down the rabbit hole…

Magic Trick #2

For the next trick we’ll have several boxes within the box. This time, we’ll use Object.assign to copy the entire object and use that structure for the hat as well. Both the hat and the box will have several boxes inside.

const box = { innerBox: { innerMostBox: {} } }; 

// we're creating a copy here, right? TOTAL SAFETY. Right? RIGHT?!?!?!?! 
const hat = Object.assign({}, box); console.log(hat); 

// { innerBox: { innerMostBox: { rabbit: 'hi there' } } }

Let’s put the rabbit in the box and take a look at what’s in the hat.

box.innerBox.innerMostBox.rabbit = 'hi there';
console.log(hat);

Since we had that misstep with magic trick #1, let’s see if we’ve done anything disturbing with the fabric of space and time.

console.log(hat === box); 
// false 
console.log(box.innerBox === hat.innerBox); 
// true 
console.log(box.innerBox.innerMostBox === hat.innerBox.innerMostBox); 
// true 
console.log(box.innerBox.innerMostBox.rabbit === hat.innerBox.innerMostBox.rabbit); 
// true

Wow. Only slightly less disturbing. The hat and the box are no longer the same exact thing but not the inner boxes and the rabbits are referring to one thing in two places. Uhhh…let’s try something else here…

Magic Trick #3

I really liked the movie Inception. Let’s get a few volunteers from the audience and send them on a hypothetical mission. This trick will be a combination of the previous tricks. Don’t worry! They were outliers. There’s no way something disturbing could happen three times in a row.

First we’ll define their adventures.

const startHypotheticalAdventure = (team) => { 
  const alertTeam = awakenTeamInDreamWorld(team);
  const resultsOfAdventure = sendTeamOnAdventure(alertTeam);
  return resultsOfAdventure;
};

const sendTeamOnAdventure = (team) => {
  // lucky team member is killed with a coffee mug
  const luckyTeamMember = team.find((teamMember) => {
    return teamMember.name === 'Bob';
  });
  luckyTeamMember.alive = false;

  // luckier team member is beaten up by a bunch of school children 
  let luckierTeamMember;
  team.forEach((teamMember) => { 
    if (teamMember.name === 'Rick') { 
      luckierTeamMember = teamMember;
    } 
  });
  luckierTeamMember.dignity = false;

  // luckiest team member hides and loses self-respect
  const luckiestTeamMember = team.find(teamMember => teamMember.name === 'Matt');
  const hidingPlace = { 
    secretPassageway: { 
      secretRoom: { 
        trapDoor: { 
          closet: [luckiestTeamMember] 
        } 
      } 
    } 
  };
  const cloneOfHidingPlace = Object.assign({}, hidingPlace);
  cloneOfHidingPlace.secretPassageway.secretRoom.trapDoor.closet[0].selfRespect = false;

  return [luckyTeamMember, luckierTeamMember, luckiestTeamMember];
};

const awakenTeamInDreamWorld = team => team.map(teamMember => { 
  teamMember.awakenedInDreamWorld = true;
  return teamMember;
});

Then we’ll define our team, put them to sleep, and send them on this hypothetical adventure.

// we're hoping this will just happen in our imagination 
const team = [
  { name: 'Bob', dignity: true, selfRespect: true }, 
  { name: 'Rick', dignity: true, selfRespect: true }, 
  { name: 'Matt', dignity: true, selfRespect: true } 
]; 

const hypotheticalTeam = startHypotheticalAdventure(team); 

// hypothetical team is a mess, no dignity, no self-respect, 
// and not alive! Good thing this is a dream.... 
console.log(hypotheticalTeam); 

// the team is still intact here. Right? RIGHT?!?!? 
console.log(team);

OHHHH THE HUMANITY!!!! WHAT HAVE WE DONE!?!?! shakes fist at the clouds

What was supposed to be a hypothetical exercise has turned into a real tragedy. Matt has no self-respect, Rick has no dignity, and Bob is dead.

Pulling back the curtain

Since you all look pretty frightened and disturbed, I’m going to break the cardinal rule of magic and explain how these tricks work.

These tricks work on the principle that Javascript arrays and objects are passed not as new values, but references to values. So when we assign hat to the value of box we are actually saying that those two variables will refer to the same place in memory. Same thing goes for arrays and objects we pass into functions of any sort, whether they are forEach, map, reduce, or anything else.

For the first trick, when we assigned hat to the value of box, it was kind of like we showed the audience a box, put a sheet over it, then revealed the box again, only this time we’re calling it a hat. This is less disturbing because our concept of reality isn’t threatened, but rather, your concept of my mental stability.

The second trick employed Object.assign, which contrary to popular belief, only performs a root level copy of the object. If there are nested objects and arrays, those will still refer to the same place in memory.

Finally, for the third trick, I wrote some awful code that represents the kinds of problems these Javascript phenomenon can cause in the wild. Imagine a more complex example where there are more variables involved. More mutations. You’d have quite a mess on your hands. In the unfortunate case of magic trick #3 we accidentally sent our team on a real adventure instead of a hypothetical one and Bob is dead.

Here are a few suggestions I have for avoiding accidental “magic” in the real world:

Use map properly. A map is designed to return a new array but only if you return a new value in the iterator function and avoid mutations. If you are mutating things, or interacting with state outside the function scope, you should take a look at perhaps forEach or a for loop.
Don’t lie to me. When I see a function that returns a value and that value being assigned to a new var, my assumption is that the function isn’t changing the value being passed in as an argument. I’m expecting that a whole new value is being returned.
If you are mutating the original reference, don’t make it seem like the function is creating a new value. Return nothing and perhaps add a comment. For example, mutateOriginalArray(array) instead of const newArray = mutateOriginalArray(array).
Be aware of the limitations of Object.assign as a way of copying objects. This only returns a new object at the root level. Perhaps this is ok. If you are hoping for a deep copy, it’ll be more work, because you’ll need to make copies of every nested objected and array as well.
Make copies of objects and arrays where practical. Consider using an immutability library. Other options include using Array methods that return a new array like .slice(), .filter(), and .map(). The spread operator ... and Object.assign are good options as well, keeping in mind their limitations.