DEV Community: Sandra Spanik

5 Things That Might Surprise You About Your First Software Engineering Job

Sandra Spanik — Thu, 28 Oct 2021 17:39:43 +0000

So you've spent the last few months navigating the treacherous interview seas and have eventually emerged employed. Congratulations! Whilst getting your foot in the tech door might be the end of a long road, it also marks the beginning of a hopefully even longer one, one accompanied by its own, unique set of challenges.

In this article I will outline 5 things I learned over my first half year as a software engineer that I found surprising. Of course, everyone's experience will be unique based on their background and the nature of the role they've accepted, but I believe the points below are general enough to apply to most freshly minted paid developers.

1. The codebase is intimidating

And I mean truly, deeply, gut-wrenchingly intimidating. I can pretty much guarantee that the first time you examine the codebase, you'll have no idea what's going on. Your mind will be occupied by vast swathes of cluelessness and panic, punctuated by the occasional impostor-syndrome-esque thought here or there. If you don't cry at least once during your first few weeks, your stoicism rivals that of Seneca.

Perhaps you've only learned JavaScript, whereas the codebase is in TypeScript, perhaps you're encountering a library (or 53) you've never heard of before or using an exotic framework the workings of which you cannot even begin to fathom. Perhaps your eyes are widening as you first dip your toes into AWS at the sheer number of otherworldly sounding services they offer, or perhaps you are exasperating over GCP's inscrutable UI. Or perhaps, as was the case for me, you're experiencing all of above simultaneously.

This is all okay and normal, and you should seek comfort in the knowledge that even seasoned developers struggle in the first months after changing a job. It takes a while to build up company-specific domain knowledge that allows you to understand how everything links up together. Have faith - the impossible will eventually come to pass and you'll one day realise that you've learned enough to start making meaningful, albeit small, contributions to the codebase. I promise!

If you're anything like me, you'll then explain your mini-breakthrough to your colleagues in way too much detail, enthusiastic and wide-eyed, and receive minimal reactions, because the task you're taking pride in is one they could literally do in their sleep, so they probably don't even realise you're currently boasting. But that's okay. You do you.

2. Expectations are low

Thankfully, the expectations placed upon you are likely to be in line with just how useless you feel. You know nothing, your colleagues know that you know nothing, and your manager, too, is in on the secret.

The skill level required to enter a software development profession as a junior is relatively low compared to other professions - you largely need to demonstrate your knowledge of a few programming languages and your enthusiasm for learning. It's as if you were hired as a doctor based on knowing the anatomy of the left hip and right arm and having successfully administered a few band-aids before.

During my interview, I asked my manager how she'd define success in my first year in the role, to which she replied she'd basically expect me to be largely learning and figuring things out throughout the entirety of the first year. In any reasonable workplace, your senior team members will be ready and willing to help you find your footing.

Your standard workplace will not demand that you conduct large chunks of independent work until you are ready. I have to admit that this feels frustrating to me - in an ideal world, I'd already know the tech stack intimately and be able to make large, independent contributions to the codebase. But in reality, I still have to rely on my colleagues to make significant changes, especially when it comes to data engineering and infrastructural work.

And when I say I rely on my colleagues, what I really mean is that we set up pair programming sessions to work through the challenging tasks together. For me, pairing has been integral to developing new skills. There's a balance to strike here - too much pairing will drain either party, but a reasonable amount will support the junior's learning while solidifying the senior's skillset.

3. Communication is key

Software engineering is a highly collaborative profession and as such you will be in constant close contact with your team. Being able to admit when you don't know something, being able to ask for help, and being able to voice any additional support needs you might have are all qualities that will make your life easier.

It can be intimidating to bring up concerns or to admit to struggling with a task. But unless your colleagues are superhuman and possess the skill of telepathy, which is even rarer than the mythical skill of exiting vim without using google, the only way things can improve is if everyone is on the same page. Get comfortable with asking for help.

This can be especially tricky in a work-from-home context, where as a beginner you might feel completely isolated with nobody physically around to ask for assistance. But if you're working remotely, communication becomes even more important, since in the absence of spending time together and socialising, your colleagues won't have the chance to pick up on you having a tough time unless you make this explicit. I've tried to live by the adage that over-communicating is better than under-communicating, and it's served me really well so far.

You have to be your own biggest advocate and try to make sure that you have everything in place that you might need to eventually grow into a valuable and knowledgeable team member. Most companies will have structures in place that will allow you to feed back your needs to the team, for example via retros or debriefs. But it will be your own responsibility to use this opportunity fully and speak up for yourself. After all, it's something nobody else is able to do on your behalf.

4. Learning is non-linear

If you've come straight out of a bootcamp or an academic degree, you might find that the way in which you are now expanding your knowledge starkly differs from what you're used to. It's likely that you will no longer come across new topics in an organised, linear fashion, but instead encounter new, seemingly unrelated problems every day. An exception to this might be graduate programs or internships at large organisations.

But in most medium or small companies, you will no longer be spoon-fed information in the exact order it's deemed most accessible by teaching experts. There will be no carefully crafted tutorials on how your internal tech stack works and interlinks. You will have to go searching for relevant material online, read a lot of documentation and ask your colleagues many questions. It's now up to you to identify where you lack the basic building blocks you need to master a technology, and to go fill these gaps independently.

As someone who went to a 9-month bootcamp which encouraged us to build lots of applications independently, I was used to producing a shiny new app every month or so, from scratch to finish. It felt like I was making massive leaps and continuously absorbing the maximum amount of information my brain would allow me to store.

Nowadays, I feel like my pace has slowed down significantly - for one, the tools I'm learning are trickier to master, and often send me down a rabbit hole of other concepts I need to understand before I can fully comprehend the problem at hand - my own brain's private version of npm dependency hell. Secondly, once you find a solution to your problem, you are likely to have other sprint priorities to return to, and will as such be forced to stop exploring the subject. This means your learning style will likely change from continuous, long chunks of deep subject exploration to discrete, smaller bits and pieces here and there.

This is not to say I haven't learned much over the last half year - the opposite is true. It's just that the learning has been more incremental and less organised. I've really benefited from documenting everything I've learned and taking notes on how I solve certain issues. More likely than not, the same issues will resurface elsewhere, so having notes to rely on instead of my own leaky memory has been super useful.

5. It's not just about writing code

Code comprehension

Say goodbye to visions of yourself banging out line after line of novel code from 9 to 5. The reality is that most days, you will end up reading more code than you write. You will spend ample time building a mental model of how a specific part of the codebase works, until you eventually distil your newfound knowledge into a few lines of code that achieve the required change. These will then go through a code review and if deemed acceptable, become part of the codebase.

Algo-what?

While you're at it, you can also say goodbye to sorting algorithms, hacker rank problems and Big O complexity. Be prepared to not encounter problems that require a ton of algorithmic thinking, at least for now, while you're still a baby dev. This is not to say there is no value in continuously practicing these in your own time - if you have spare energy, by all means, do. But don't expect the job to contain a lot of opportunities to implement the types of algorithmic problems most employers still ask during interviews. Weird, it's almost as if the recruitment process doesn't actually reflect the job accurately... 🧐

Discovery

Not all tasks are glamorous. By this I mean, not all tasks involve solving interesting problems programatically. Sometimes, your job will be to read frequently incomplete and badly written documentation to figure out how the tools you are using work. Setup, configuration, and similar, arguably boring preparatory tasks, are part of the deal - especially when starting new projects or breaking novel ground and doing discovery surrounding existing projects. I suppose that this is the price we pay to earn a decent salary and have fun coding whilst tackling the other, less config-heavy tasks.

Meetings

Expect many meetings. Sprint planning, retros and daily stand-ups. Making sure there's alignment within your team, as well as cross-team alignment. Socials, if you're lucky. In any case, seeing people in 2D on a screen will quickly become part of your daily routine.

Conclusion

Being a software engineer means being in constant contact with people. It's a highly collaborative discipline, and you will benefit from being able to communicate well. The codebase will initially seem indecipherable, but be patient and kind to yourself - things will eventually click. Your colleagues will help you, but you should also be prepared to do a lot of research and learn new tools independently. Be ready to spend more time reading code than writing it.

Have my first 6 months as a software engineer been at times arduous and challenging? Yep. Has it all been worth it? Absolutely. In my own, biased, opinion of course.

The JavaScript Reduce Method

Sandra Spanik — Wed, 21 Jul 2021 20:48:04 +0000

Until recently, the only thing I've ever successfully reduced was myself - to tears. Much like the world's billionaires have recently embarked on journeys to shoot their wealthy bottoms to outer space, so, too, have I embarked on an epic adventure to understand the reduce method. Would you like to accompany me on my journey to finally, once and for all, understand the notorious, the dreaded, the one-and-only reduce method? Great. Welcome on board Rocket JavaScript. 🚀

What is the reduce method?

Javascript comes with a bunch of inbuilt array methods designed to make our lives easier. They provide out-of-the-box, frequently needed functionality for iterating through or manipulating arrays in specific ways. There's quite a few of them and whilst it's completely unnecessary to remember them all, it's a good idea to have some solid intuitions about what can be achieved using them.

According to MDN, the reduce() method executes a callback function (that you provide) on each element of the array, resulting in a single output value. Apart from the callback function, it can also take in an initial value.



//reducer is the callback function, initialValue is the optional second param
array.reduce(reducer [, initialValue])

The reducer function

The callback function takes four arguments, but the last two can frequently be omitted, depending on what we want to achieve. The function is then applied to each element in the array, eventually returning a single value.

Accumulator - this accumulates the reducer function's return values
Current Value - the current element being processed
Current Index (optional) - index of the current element being processed
Source Array (optional) - the array we are calling the reduce method on



function reducer(accumulator, currentValue, currentIndex, array){}

This can all sound very confusing, so let's break it down and examine the syntax.

Let's assume we want to write a function that adds up all items in an array and returns their sum. The initial array we want to sum is the following. Let's ignore the fact it clearly adds up to 10 and pretend our mathematical ability is low enough to require us to find a programmatic solution to what we perceive to be an impossible numeric challenge.



const arr = [1,2,3,4]

Now let's look at how to apply the reduce method.



//define the reducer function, provide it with its first 2 parameters
//returns the sum of the accumulator and currentValue
const calculateSum = (accumulator, currentValue) => accumulator + currentValue

//apply reducer function to array
arr.reduce(calculateSum)

Above, we've told the reducer function to return the sum of the accumulator and the current value being processed. This means that as the reducer iterates through the array, each new number will be added to an ever-increasing sum held in the accumulator. Still confusing? I agree. Let's add in some console.logs to understand how the process executes.

Explanation

Throughout the article, I will post images to show how the accumulator and currentValue of the callback function change. I will then explain the image using words, which might or might not be useful for you. If you're a visual learner, you might find the images on its own more useful and feel confused by the text. Feel free to skip the bits that are not useful to your particular learning style.



const calculateSum = (accumulator, currentValue) => {
    console.log('accumulator: ', accumulator);
    console.log('currentValue:', currentValue);
    return accumulator + currentValue;
  };

arr.reduce(calculateSum)

On the first iteration, the accumulator is the first item of the array, 1. The currentValue, or the item being processed, is the following item, 2. As we apply the reducer function to 2, the reducer returns the sum of the accumulator, 1 and the currentValue, 2.
The return value of the reducer, 3, becomes the new accumulator. The currentValue shifts to the next item in the array, which happens to also be 3. The function to add the accumulator to the currentValue is applied to the currentValue of 3, which makes 3 + 3 and results in 6.
6 therefore becomes the new accumulator. The next item in the array, the currentValue, is now 4. The reducer that adds up the accumulator and currentValue now gets applied to 4. 6 + 4 is 10, and because there are no more items in the array, this becomes the final return value.

Phew. Turns out, not only is this array method hard to understand, it's also hard to describe. If my words confused you, I encourage you to step through the image line by line in your own time.

Note: By the way, this is not a common real-world use case for the reduce method. If all we want to do is sum an array of numbers, we might as well just use a for loop or forEach. Nevertheless, using reduce in this way serves as a good illustration of how the method works. We will encounter a few such 'bad-use-but-good-explanation-cases' over the course of this article.

Initial Value

We can also tell our reduce method to initialise the accumulator at an arbitrary value of our own choosing, by passing in the optional parameter of initialValue.



arr.reduce(reducer, initialValue)

Let's recycle above example.



const arr = [1,2,3,4]

const calculateSum = (accumulator, currentValue) => {
    console.log('accumulator: ', accumulator);
    console.log('currentValue:', currentValue);
    return accumulator + currentValue;
  };

//here we tell the reduce method to initialise the accumulator at 10
arr.reduce(calculateSum, 10)

In the previous version of this example, the first accumulator was 1, which is the first value of the array. Here, we override this value by adding a second argument to the reduce method, the initialValue of 10. 10 now becomes our first accumulator, and the reducer is applied to the first item in the array.

Here's a summary of how passing in the optional initial value parameter affects the execution of the reduce method.

initialValue	accumulator	currentValue
not passed	`accumulator = array[0]`	`currentValue = array[1]`
passed	`accumulator = initialValue`	`currentValue = array[0]`

Setting the initial value something other than a number, (e.g. an empty array or object) allows us to do some neat stuff with our reducers. Let's walk through a couple of examples.

1. Counting using reduce

Let's say we're looking to write a function that takes in a string and returns an object with a letter count for the given string. If our string was "save the bees" our desired return value would be

{ s: 2, a: 1, v: 1, e: 4, " ": 2, t: 1, h: 1, b: 1 }



const string = "🚫🚫🚀🚀 less rockets, more bees pls"

const letterCountReducer = (acc, value) => {
  acc[value] ? ++acc[value] : (acc[value] = 1);
  return acc;
};

//the accumulator is initialised as an empty object
[...string].reduce(letterCountReducer, {})

Explanation

image showing the beginning of the execution order of above process

Because we passed in the initial value of an empty object, the accumulator is initialised as an empty object.
As we iterate over the array, we can check whether each letter exists as a key in the accumulator object. If it does, we increment it by 1, if it doesn't, we initialise it with a value of 1.
We return the new accumulator that now accounts for the letter we just iterated over, and move on. Eventually we'll return an accumulator that contains an object with all the letters accounted for.

2. Flattening arrays using reduce

Let's assume we have an array of arrays. Three types of animals, dying to be together, separated by indomitable array walls.



//BOO! An unnatural habitat
const zoo = [
  ['🐇', '🐇', '🐇'],
  ['🐷', '🐷', '🐷'],
  ['🐻', '🐻', '🐻'],
];

How do we break them free?



const flatten = (acc, animalArray) => acc.concat(animalArray);

zoo.reduce(flatten, []);
//returns ["🐇", "🐇", "🐇", "🐷", "🐷", "🐷", "🐻", "🐻", "🐻"]
//YAY! A natural habitat!

Explanation:

We provide an empty array as the accumulator.
The reducer concatenates the first current value, here named animalArray, to the empty accumulator. We return this new array, now filled with 3 bunnies.
This becomes the new accumulator, to which we now concatenate the next currentValue, or animalArray. The second item in the original array is an array of pigs. We return the new accumulator consisting of bunnies and pigs, and move on to the bears. The accumulator is now an array of bunnies and pigs. To this, we concatenate the current value - the bear array.

Note: While this example serves to illustrate the workings of the reduce method, in practice, I'd opt for the arr.flat() method which does exactly what it says on the tin.

3. Deduplicating arrays using reduce

Let's assume we have an array with duplicates and want to end up with an array of unique values instead.



//initial arr
const arrOfDupes = ["🚀", "🚀", "🚀", "🌍"];

//desired output
 ["🚀", "🌍"];

const dedupe = (acc, currentValue) => {
  if (!acc.includes(currentValue)) {
    acc.push(currentValue);
  }
  return acc;
};

const dedupedArr = arrOfDupes.reduce(dedupe, []);

Explanation

We start with the initial value of an empty array, which becomes our first accumulator.
As the reduce method iterates over the array, the callback function gets applied to each item in the array. It checks for the absence of the current value from the accumulator. If this is the case, the current value gets pushed into the accumulator.
The accumulator gets returned, either unchanged or with an additional unique value.

Note: While this example serves to illustrate the inner workings of the reduce method, in practice, I'd opt for deduplicating an array of primitives by using Sets, which is a more performant approach.



dedupedArr = [...new Set(array)];

4. Grouping items using reduce

Let's assume we want to group an array of objects by property. We start with an array of objects and end up with an object that includes two arrays where the objects are grouped by a selected property.



//initial array of objects to be grouped
const climateBehaviours = [
  { description: "Recycle", greenPoints: 30 },
  { description: "Cycle everywhere", greenPoints: 40 },
  { description: "Commute to work via plane", greenPoints: -70 },
  { description: "Replace beef with veg", greenPoints: 50 },
  { description: "Build a rocket for space tourism", greenPoints: -500 },
];

//desired output: an object with two groups
{
  goodClimateBehaviours: [{}, {}, ...], // greenPoints >= 0
  badClimateBehaviours: [{}, {}, ...],  // greenPoints < 0
};

Let's code this up.



//reducer function
const groupBehaviour = (acc, currentObj) => {
  currentObj.greenPoints >= 0
    ? acc.goodClimateBehaviours.push(currentObj)
    : acc.badClimateBehaviours.push(currentObj);
  return acc;
};

//initial value 
const initialGrouping = {
  goodClimateBehaviours: [],
  badClimateBehaviours: [],
};

//applying the reduce method on the original array
const groupedBehaviours = climateBehaviours.reduce(groupBehaviour, initialGrouping);

In bad news for the Musks, Bezoses and Bransons of this world, this is what we end up with.



console.log(groupedBehaviours)

{
  goodClimateBehaviours: [
    { description: "Recycle", greenPoints: 30 },
    { description: "Cycle everywhere", greenPoints: 40 },
    { description: "Replace beef with veg", greenPoints: 50 },
  ],
  badClimateBehaviours: [
    { description: "Commute to work via plane", greenPoints: -70 },
    { description: "Build a rocket for space tourism", greenPoints: -500 },
  ],
};

Explanation

The initial value is an object with two properties, goodClimateBehaviours and badClimateBehaviours. This is our first accumulator.
The callback reducer function iterates over the array of objects. Each time, it checks whether the current object has greenPoints greater than 0. If so, it pushes the object into accumulator.goodClimateBehaviours, otherwise the object is pushed to accumulator.badClimateBehaviours. The accumulator is then returned.
An accumulator eventually containing all objects will be returned as the final return value.

5. Manipulating more complex data structures using reduce

In the real world, the power of reduce gets harnessed most commonly when manipulating more complex data structures. Let's say we have an array of objects with an id, description and outcomes array, where each outcome can be desirable or not. We want to transform this array into a single object that looks quite different.



const climateActions = [
  {
    id: 'space_tourism',
    description: 'build rockets for space tourism',
    outcomes: [
      { outcome: 'rich people can go to space', isDesirable: false },
      { outcome: 'is pretty cool', isDesirable: true },
      { outcome: 'increased emissions', isDesirable: false },
      {
        outcome: 'investment diverted from green energy to space tourism',
        isDesirable: false,
      },
    ],
  },
  {
    id: 'trees_4_lyf',
    description: 'stop burning down the amazon',
    outcomes: [
      { outcome: 'air for all', isDesirable: true },
      { outcome: 'our kids might live', isDesirable: true },
      {
        outcome: 'reduce threat of imminent extinction',
        isDesirable: true,
      },
      {
        outcome: 'make greta happy',
        isDesirable: true,
      },
      {
        outcome: 'make bolsonaro sad',
        isDesirable: false,
      },
    ],
  },
];

Our aim is to transform this array into a single object which has the id as keys, and an object with arrays of good outcomes and bad outcomes, as shown below.



const climateInitiatives = {
  'space_tourism': {
    badOutcomes: [
      'rich people can go to space',
      'increased emissions',
      'investment diverted from green energy to space tourism',
    ],
    goodOutcomes: ['is pretty cool'],
  },
  'trees_4_lyf': {
    badOutcomes: ['make bolsonaro sad'],
    goodOutcomes: [
      'air for all',
      'our kids might live',
      'reduce threat of imminent extinction',
      'make greta happy',
    ],
  },
};

Here's one way to implement this transformation, using reduce.



const reducer = (acc, currentObj) => {
  const newAcc = {
    ...acc,
    [currentObj.id]: { badOutcomes: [], goodOutcomes: [] },
  };

  currentObj.outcomes.map(outcome => {
    outcome.isDesirable
      ? newAcc[currentObj.id].goodOutcomes.push(outcome.outcome)
      : newAcc[currentObj.id].badOutcomes.push(outcome.outcome);
  });

  return newAcc;
};

const res = climateActions.reduce(reducer, {});

We could also, instead of using the map method, use a reduce within the reduce, but we might break the matrix in doing so. 🤯

Explanation

The first accumulator is an empty object. The current value, named current object here, is the first object in the original array.
The reducer function initialises a new variable, newAcc. newAcc is an object, with the spread of the current (still empty) accumulator. We assign a new property to newAcc, with the key being the current object's id, and the value being an object with the bad and good outcomes arrays. [currentObj.id]: { badOutcomes: [], goodOutcomes: [] }
We then map over the current object's outcomes array and depending on whether the outcome is desirable, push it into or new variable newAcc's outcomes array.
We return the newAcc, which becomes the acc on the next round of iteration, so when we spread it, we don't lose its contents.

Conclusion

What have we learned? Hopefully, the reduce method (and also that I am clearly not a huge fan of billionaires squandering resources on the selfish pursuit of space travel at a time when we should all focus on preventing catastrophic global heating, but that's just my opinion 🔥).

Reduce is undoubtedly one of JavaScript's more tricky inbuilt methods. But as is the case with most coding, the best way to truly understand it is to practice. If the examples in this article made sense - great! If not - also great, one more opportunity to play around and practice until things click. And I promise, they eventually will.

Now, let's go and reduce some code. Also our emissions. 🍃

Blaming Git Blame

Sandra Spanik — Wed, 23 Jun 2021 18:16:09 +0000

In this article I make a case for renaming the feature git blame to a neutral equivalent (e.g. git author or git inspect). I argue that the use of git blame primes workplaces and teams for blame culture and contributes to unhelpful feelings of shame. The language we use shapes our cognition, feelings and behaviours in small but systematic ways, and it is for this reason that I argue renaming the otherwise useful feature git blame is long overdue. I also investigate the source code of git in an attempt to understand how the feature got introduced, and connect with its author to find that he, too, wishes the feature was named differently.

What is git?

Git is an open source version control tool with widespread adoption that allows individuals to track changes to files over time and revert back to previous versions of files at any time. It is extremely useful for collaboration and has become the de-facto standard for software engineering teams. While there are alternative version control systems, many companies consider a basic command of git a pre-requisite for employment.

What is git blame? 😳

Git blame is a git command which reveals what revision and author last modified each line of a file.

When I was first shown the feature, I chuckled nervously at the discovery. Being new to tech, I generously allow for the possibility that my code might not yet be, objectively, what one would call "the shit". Naturally, I immediately imagined my colleagues repeatedly invoking my name using git blame, subconsciously adding the tiniest bit of additional frustration to an ever-growing stinking pile of frustrations upon each discovery of me as the culprit. In 21st century language, I'd summarise my feelings about learning of git blameas follows: 👀.

Whilst my instinctual reaction was that of pre-emptive shame creeping in, it was quickly countered by some good old rational thinking. I feel safe in my workplace, knowing that my colleagues aren't on the hunt to assign blame for mistakes, and that my organisation values collaboration over rockstar developing.

I was told that the main utility of the feature is not enabling team members to blame each other for their poor code contributions, but enabling individuals to find out who would be the best person to ask about a specific part of a codebase. The ability to quickly identify the author of a given part of the codebase for follow-up questions is handy, and saves time.

If you're asking yourself, why would the feature be named blame instead of author, when it primarily gets used to identify the code's author, then you and I are asking ourselves the same question.

Git blame is harmful 🤕

Let's assume we agree that git blame shouldn't get used with the intent of assigning blame within teams. A big assumption to make, that I bet some teams with archaic or authoritarian work philosophies would disagree with. But philosophical differences regarding effective collaboration are beyond the scope of this article.

Okay, so we're assuming we all agree - let's not blame each other and instead primarily use git blame to find the code's author in a blame-free context. Great. But even so, 2 issues remain:

Why should the onus be on us developers to do mental gymnastics and internally rebrand git blame as git author, when in fact, the feature itself could just be named git author in the first place?
Even though we can agree to see beyond its literal meaning, the naming of the feature still continues to affect us in systematic ways.

This is because language subconsciously shapes the way we think, feel and behave. Repeated exposure to the word blame in a work context is harmful. It feels implausible that in today's climate, where we rightfully pay attention to our language more than ever, a feature like git blame should be allowed to peacefully continue existing and priming workplaces for blame culture.

Language measurably shapes our cognition 🧠

The language we use demonstrably influences how and what we think. For example, existing cross-cultural differences in how we perceive time, distance and size can be traced back to how different languages construct these abstract ideas. Also, speakers of languages which use grammatical genders such as Russian or German are heavily influenced by the arbitrary grammatical gender of nouns. These speakers' visual representations of such nouns and their instinctive associations depend heavily on the noun's otherwise random gender. Even visual perception is not immune to the effect of language. For example, Russian speakers are better at distinguishing between shades of blue than English speakers because they have more words to describe them. You can read more about all of this here.

Language has a priming effect 🗣️

Priming is a phenomenon whereby exposure to one stimulus influences a response to a subsequent stimulus, without conscious guidance or intention. For example, exposing someone to the word "yellow" will evoke a faster response to the word "banana" than it will to an unrelated word like "sofa". Priming takes place outside of our conscious awareness, but it plays an important role in our daily lives. From influencing how we interpret information to our behaviour, priming can play a part in our perceptions, emotions, and actions. Marketers, advertisers and even social media engineers have sought to exploit this effect.

It's reasonable to assume that seeing the word blame repeatedly primes us for negative affective responses. If you are committing new code, thinking of the word "blame" is likely to introduce just the slightest bit of fear, shame or guilt. On the flip side, if you are the one investigating changes and see your colleague's name next to the word "blame", you will be more likely to actually assign blame to them and associate their name with a negative affective state.

Now let me pre-empt some questions a reader might have at this stage.

If it bothers you so much, why don't you just alias it? ❄️

I'm aware that git has a neat alias feature that allows you to replace any command with another. Technically, nothing's stopping me from renaming git blame to git candyfloss. But the feature is ubiquitous and difficult to avoid, so creating an alias in my local device would barely reduce my exposure to it.

image of VSCode blame extension

There are useful git extensions that display git blame, and even Github itself has a UI version of git blame that shows you the author and the name of the commit associated with each part of the codebase. According to the 2020 Stackoverflow Annual Developer Survey, more than 82% of us use Github, so the word blame really is near impossible to escape.

image of Github's blame interface (yes, this is what Github looks like in light mode)

If it bothers you so much, why don't you just use git annotate? ❄️

git annotate is another git command with nearly the same functionality. Whilst git annotate doesn't differ from the criticised feature by much, it doesn't solve the issue for the exact same reasons described above.

Having justified why git blame is worth discussing, let's now delve into its history.

What's to blame for git blame? 🔎

Git was created in 2005 by none other than Linus Torvald, the creator of Linux, who was at the time working on his operating system with a dispersed team of volunteer developers. Working remotely before it was cool, he was using the proprietary version control software BitKeeper, which was made available to his team for free. Until, one controversy later involving an engineer being accused of reverse-engineering the software, BitKeeper's founder Larry McVoy withdrew the agreement.

Torvalds soon announced he would go on a week-long holiday, and in true vacation spirit, created the first version of the version control tool that 82% of today's nearly 27 million developers use, probably all whilst reclining on a beach chair and sipping on a cold one.

actual footage of Torvalds implementing git (probably)

Git's success was a surprise to him. It's safe to say that carefully naming projects sensitively, especially those he never expected to take off in such spectacular fashion, wasn't Torvalds' priority nor inclination.

“The in-joke was that I name all my projects after myself, and this one was named ‘Git’. Git is British slang for ‘stupid person’,” Torvalds tells us.

That's right. Git is actually a British swear word. If you've previously noticed this and chuckled at the fact that git is eponymous with the swear word popularised by The Beatles and Ronald Weasley, the joke's on you - git's creator knew this full well. The README of Git elaborates even further:

"Git", the "stupid content tracker", can mean anything, depending on your mood

Random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
Stupid. Contemptible and despicable. Simple. Take your pick from the dictionary of slang.
"Global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
"Goddamn idiotic truckload of sh*t": when it breaks.

Open source

Git's maintenance continued to be led by one of the most active early contributors Junio Hamano, who is said to remain somewhat of a benevolent dictator to the git community up to this day. It's important to note that git is by no means one man's toy. It is the result of a decade and a half of collaboration and hard work by an active and caring community.

Their Code of Conduct speaks of a community that is respectful and kind. But the extent to which this is true is unclear to me because I am neither a contributor myself nor am I impervious to stories about the patriarch himself, Linus, occasionally telling contributors they should probably be retroactively aborted. A man who enjoys to jokingly call out stupid people who write stupid patches for being so stupid that it's a surprise they've managed to find a tit to suck on as stupid babies, is not a man I associate with creating welcoming communities.

Torvalds letting us all know what he really thinks of our code contributions (probably)

Whilst I must admit that I personally enjoy his particular brand of dark humour, I'd advocate for being more mindful of the power dynamics we are all part of, because whether we like it or not, our words can have unintended harmful consequences.

A theory started forming in my head: perhaps git blame was the result of the same strain of dark humour? Maybe a seemingly innocent but really quite insensitive joke that feels so on brand for the Linux creator's past? I say past here, because the man is apparently evolved now.

I'd like to think that, having known the many millions of developers who'd come into contact with the concept of blame on a daily basis as a result of a mildly amusing joke, the naming of git blame would have been reconsidered. I'd say, it's about time we retroactively abort it.

Getting to the bottom of git blame 🕵🏼‍♀️

Spoiler alert: as you might have already guessed, astute reader, my naive assumption that git blame started as a joke is, in fact, completely wrong. But let's dig into how I derived at this sobering conclusion.

Thankfully, git is so spectacularly useful that I didn't have to stop at simply theorising about my burning question of how, when and why git blame was introduced. The beauty of git itself being an open source project made with git, means that anyone can check out who authored which changes when.

In search of some answers, I put on my detective hat, raised a monocle to my eye, and downloaded Git's source code repo. To search for the earliest introduction of the string "blame" into the codebase, I used git log --all -p --reverse --source -S 'blame' .

The first mention of "blame" I found was in the documentation intended for users migrating from CVS, a competing version control tool. The changed file, in classic Linus fashion, begins with the following sentence: "OK, so you're a CVS user. That's ok, it's a treatable condition, and the first step to recovery is admitting you have a problem". Had programming not worked out for the man, standup comedy would have been a solid second choice.

Here's the bit that features the word "blame".

Author: Linus Torvalds torvalds@linux-foundation.org
Date: Wed Jun 8 13:19:31 2005 -0700

So, something has gone wrong, and you don't know whom to blame, and
you're an ex-CVS user and used to do "cvs annotate" to see who caused
the breakage. You're looking for the "git annotate", and it's just
claiming not to find such a script. You're annoyed.

Yes, that's right. Core git doesn't do "annotate", although it's
technically possible, and there are at least two specialized scripts out
there that can be used to get equivalent information...

The text suggests ex-CVS users were predicted to expect the command git annotate to produce what we now know as the git blame output, based on CVS itself supporting an annotate command. Neither of the commands existed in git at the time (although now, they both do).

At this point, it seemed to me like the jury was still out on whether the naming of git blame was the result of a joke or an intentional, serious, naming decision. But from reading through the documentation, it started seeming more and more like git blame was the result of a work ideology that starkly departs from mine, and embraces a culture where assigning blame is the norm and tolerance for mistakes is scant.

Still hungry for answers, I dug deeper and uncovered git's public mailing list archives.

The real origin of git blame 💫

In May 2005, a member of the git open source community sent an email, wondering how to replicate the CVS annotate feature. Linus replied saying that whilst he knows how to do it (obviously 💅), he's hoping someone else will, because he generally doesn't care about the feature enough. So much for my Torvalds-joke hypothesis.

Junio Hamano came forward and implemented a slow yet working algorithm in Perl, which became the base of future git blame implementations. Then, 2 people independently created their own versions - one of which became git annotate, named consistently with SVN, and the other became git blame .

Here's the "guilty" commit.

Author: Fredrik Kuivinen frekui@gmail.com
Date: Tue Feb 21 00:40:54 2006 +0100

Add git-blame, a tool for assigning blame.

I have also been working on a blame program. The algorithm is pretty
much the one described by Junio in his blame.perl. My variant doesn't
handle renames, but it shouldn't be too hard to add that. The output
is minimal, just the line number followed by the commit SHA1...

So here we go, git blame turns out to be described by its creator as a tool for assigning blame and was originally unequivocally intended to do exactly what it says on the tin - assign blame.

Admittedly, the finding is no sensation - my detective work has led me to the outcome most would have rightfully assumed to be true by default, without feeling the need to go off and do hours of research on the topic in the hope of discovering that, surely, this was all down to a simple misunderstanding or innocent joke gone awry.

However, Fredrik was not the first one to have implemented a "blame" algorithm. As he says in his commit message, he was working off of Junio's blame.perl, which makes copious use of the words blame and guilt itself, as shown below, in an excerpt from the blame algorithm's description.

How does this work, and what do we do about merges?

The algorithm considers that the first parent is our main line of development and treats it somewhat special than other parents. So we pass on the blame to the first parent if a line has not changed from it. For lines that have changed from the first parent, we must have either inherited that change from some other parent, or it could have been merge conflict resolution edit we did on our own.

The following picture illustrates how we pass on and assign blames.

In the sample, the original O was forked into A and B and then merged into M. Line 1, 2, and 4 did not change. Line 3 and 5 are changed in A, and Line 5 and 6 are changed in B. M made its own decision to resolve merge conflicts at Line 5 to something different from A and B:

+
+                A: 1 2 T 4 T 6
+               /               \ 
+O: 1 2 3 4 5 6                  M: 1 2 T 4 M S
+               \               / 
+                B: 1 2 3 4 S S
+

In the following picture, each line is annotated with a blame letter.
A lowercase blame (e.g. "a" for "1") means that commit or its ancestor is the guilty party but we do not know which particular ancestor is responsible for the change yet. An uppercase blame means that we know that commit is the guilty party

Even I, self-appointed Language Police Officer™, can see nothing wrong with the above description. In the world of algorithms, removed from humans, the words "guilt" and "blame" are simply the most succinct descriptions of the variables' functionality. In this context, the drawbacks of their negative connotations don't outweigh their utility.

But the rabbit hole goes even deeper than Junio's blame.perl. Turns out, another competing source control tool called Subversion had already implemented a blame feature all the way back in 2003!

The usage of the term blame is likely the result of 2 things: the word's variable naming utility and the collective mindset at the time.

Contacting The Author 🗯️

When I contacted the git feature's author, Fredrik Kuivinen, he told me that he mainly called it blame because it had been called blame elsewhere already. He also added the following:

"In hindsight, I should have taken the opportunity to come up with a better name, e.g., "praise" which has been suggested by others."

I felt vindicated. My temporary career change to detective had been worth it - after all, the author himself appears to agree a naming change would be beneficial!

But at the time Fredrik was implementing the feature, coming up with a better name would have required an implausible amount of foresight on his part. Firstly, he would have had to anticipate the success of git and the future ubiquitousness of the feature. Secondly, he would have had to anticipate a cultural shift in tech.

Moreover, the same command already existed elsewhere, and going with the default produces less friction than changing the status quo. And judging by mail exchanges, other contributors also preferred the naming of "blame" over "annotate".

Therefore, we will be assigning NO blame to Fredrik for implementing the feature in this article.

What have we learned? 🎓

The term blame in a version-control context existed elsewhere prior to git, because it is a succinct descriptor, and a reflection of the collective prevalent mindset at the time that no single individual is responsible for.
Using words with negative affect in internal variables might in some cases well be the most elegant naming solution. But to, in 2021, name external commands in the same way, demonstrates either a lack of empathy for the end user or a lack of awareness of the significant impact language has on us all.
Open source is magnificent. More work than I could have previously imagined went into git. I'm grateful for the hard work that continues to set the foundations of all technology that surrounds us.

This doesn't seem like such a big deal, why get hung up on it? 💁🏼

I agree that on an individual level, the existence of git blame feels easy to brush off. Once the initial twinge of surprise at discovering the feature subsides, it's easy to go back to work and never question it again. But as I've explained above, the language we are exposed to continues to affect us in subtle but real ways.

So whilst the effect of git blame on any one person might be negligible, its cumulative effect on an entire industry that encounters the feature every single day is significant. Over time, tiny amounts of shame and hesitation encountered by millions add up to a mountain of innovations foregone.

Moreover, many clearly still find it amusing that git blame exists. To those who do, I'd say: get with the times, folks. Being a dick is 2000 and late.

And although I have no science to back this up, I have the suspicion that some are more affected by the feature than others. Those who engage in more introspection, those who feel they have more to lose if they commit the wrong code, those who experience a wider range of emotions overall. As we move towards creating a diverse workforce open to individuals from any background, we would do well to also adjust our language to be more inclusive, thus allowing anyone to feel welcome and contribute with confidence.

So now, only one question remains... who is confident in C and wants to submit a revolutionary patch to git? 🤩

Why You Should Learn Next Next

Sandra Spanik — Fri, 28 May 2021 16:25:32 +0000

So you've learned React. You know, at least vaguely, what the virtual DOM is and are comfortable with using hooks including useState , useEffect and useRef. What is the logical next step? I think you'll find the answer to this question within the question itself.

The Next Episode

Next is a framework built on top of React that purports to make the development process even more palatable. Personally, I enjoy working with React already, so I was surprised to find the extent to which Next delivers on its promise.

Key Features

What exactly makes learning Next a worthwhile endeavour? There's a lot that sets Next apart from simply using React, but let's start with 3 key features that Next implements to solve common React problems.

1. Server-Side Rendering (SSR)

Upon inspecting the source code of a classic React application in the browser, you will notice that it doesn't contain much. Typically, the only html sent from the server is a <div> with the id of root. The rest of the page gets rendered on the client side, i.e. inside the browser of the user.

Of course, client-side rendering is what makes React powerful in the first place and enables it to utilise its virtual DOM, based on which the real DOM tree gets selectively updated. Instead of rewriting the entire DOM tree every time a change is made by a user, the virtual DOM is capable of selectively updating only those elements that are currently being manipulated.

But React's biggest advantage can also be its biggest disadvantage in some specific cases. NextJS addresses these out-of-the-box, by default, whilst preserving React's other cool features.

Initial Load Time

Loading the DOM in a React application can take some time, and depending on the internet speed of the user, this might result in a blank screen being displayed for longer than is optimal.

SSR reduces the perceived load time of pages because the components are already pre-rendered into html pages on the server, as demonstrated in below video. Even though the actual time taken to load the contents of the DOM is similar, the non-SSR page on the left displays a blank page until all scripts are loaded, whereas the SSR page on the right appears to the user with instantaneously visible content.

Video demonstrating the difference in perceived page load times for non-SSR (left) and SSR (right). Network throttling enabled and set to ‘Regular 4G’ on Chrome Dev Tools. Credit: S. Karavadi's excellent article.

Data Fetching

Imagine you're fetching data, because why wouldn't you be. After all, we're all just slaves to the data, much like dogs are slaves to the ball. A standard React application would need to load all its scripts first to realise it even contains a hook designed to fetch data. Only then would it be able to send a request for the data and wait for its response.

We typically handle this by introducing spinners or similar components designed to tell the user the application is still waiting to receive its data. With Next, you are able to pre-fetch some data at build time, way ahead of the user's request to see it.

SEO

Although React already touts improved SEO capabilities compared to standard Javascript-heavy web apps, Next elevates these to the next level. In standard React applications, search engine crawlers will typically only see the initially empty html page being sent from the server. Pre-rendering your pages on the server side addresses this potential hiccup and allows search engine crawlers to see the content of the application and consequently to be able to index it properly.

2. Simplified Routing

Say goodbye to React-Router-DOM and its ever-changing documentation (although, I do appreciate you, maintainers!). Say hello to defining pages and routes within your folder structure instead! Next comes with a folder called pages, which you can fill with... well, pages. Each file inside the pages folder willl automatically convert to an eponymous route.

/pages 
    /about.js
    /index.js
    /projects.js
    /writing.js

The above folder structure would translate to an application that has the following routes:

/pages/index.js - BASEURL/

/pages/about.js - BASEURL/about/

/pages/projects.js - BASEURL/projects/

/pages/writing.js - BASEURL/writing/

Neat, right? The file index.js maps directly onto the route / by default. Next can also easily handle nested routes, like so.

/pages 
    /index.js
    /snoop
        /dogg.js
        /doggydogg.js
        /index.js
        /lion.js

The above folder structure would translate to an application with the following routes:

/pages/index.js - BASEURL/

/pages/snoop/index.js - BASEURL/snoop/

/pages/snoop/dogg.js - BASEURL/snoop/dogg/

/pages/snoop/doggydogg.js - BASEURL/snoop/doggydogg/

/pages/snoop/lion.js - BASEURL/snoop/lion/

What about dynamic routes with dynamic parameters? Not a problem for Next either.

/pages
    /index.js
    /about
    /products
        /index.js
        /[productId].js

By wrapping a file name in square brackets, you can indicate to Next that you're defining a dynamic route, the parameter of which you can then access from within your code.

/pages/products/[productId] - BASEURL/products/{param}/

I'll go into more detail about how to access dynamic parameters in an article that focuses specifically on routing. But for the purposes of this article, just let it be known that handling routing is pretty intuitive and doesn't involve importing any additional libraries.

3. Backend Capabilities

NextJS also enables us to incorporate backend code that, say, communicates with a database or with the filesystem. You might find yourself writing NodeJS code inside a Next application to perform CRUD operations or authenticate users. The benefit of building a full-stack application using Next is that you no longer have to switch between separate projects to fine-tune your application.

Files that live inside the folder pages/api, which is created by default, will be treated as API endpoints. For instance, a route resulting from the file-path pages/api/artist.js would return a JSON response with a status code of 200, if it had something akin to the following backend code in it:

export default function handler(req, res) {
  res.status(200).json({ name: 'Snoop Doggy Dogg' })
}

I initially had no idea Next was capable of this. Knowing that I can create RESTful APIs using a React framework that I intuitively only associated with frontend capabilities continues to blow my mind.

That's It?

Nope, I barely scratched the surface. I found a very concise but technical summary of cool Next features on Reddit by none other than the (then) lead maintainer of Next. I encourage you to read it if you want to know more but can't be bothered actually spending hours sifting through the sizeable official Next documentation (which itself, by the way, ticks all "great docs" boxes in my opinion).

Still Not Convinced?

Another consideration is that NextJS is not just some fad that will blow over in a couple of months. Initially released by Vercel in 2016, it's become a well-established framework with an ever-growing community of users, making it a sought-after skill in the job market.

NextJS is here to stay, and slay.

Arguably, NextJS is already famous enough to render this article pretty much pointless. One last proof of Next's supreme rendering capabilities.

How to Ace the Behavioural Interview

Sandra Spanik — Tue, 11 May 2021 18:42:34 +0000

As you might have already guessed, this article is not about technical interviews, coding challenges, let alone about (shudders) algorithms. I'm not qualified to give anyone advice on above, but having transitioned to tech from mental health, I do know a thing or two about human behaviour. By extension, I'm declaring myself qualified to dish out advice on behavioural interviews.

This article is about all aspects of the interview process that are NOT strictly coding-related, and will be particularly useful to those who are transitioning careers to tech from a different industry.

Let's go! 🤸‍♀️

The Tech Recruitment Process 🧭

Typically, interviews in the tech industry have at least 4 rounds, although of course the exact schedule will vary from company to company.

The Application/Recruiter Email
The Recruiter Screening Call
The Technical Interview/The Takeaway Coding Challenge
The Behavioural Interview

Rounds 1, 2 and 4 all have to do with who you are as a person, as much as they have to do with your skills. There is a 100% likelihood you will have to tell your interviewers about yourself and your background, and unless you come across as someone your interviewers would enjoy working with, no amount of skills will help you land your dream role. It's not easy to get an offer, especially if you're switching careers from a different industry, so being prepared to talk about yourself eloquently might well be what distinguishes you from your competition.

Interviewing Well is a Skill. ⌛

The good news is that interviewing, just like any other skill, is one you can improve with practice. It certainly took me a lot of practice to sound confident and convincing in interview situations - I'm still not amazing at it. The last in-person interview I went to pre-career-switch to tech ended in tears - not only did I come across as an idiot, I also knocked over a glass of water onto the interviewer sat across me.

Why was it such a nightmare? Because I hated the sound of the job, and, as a result, was woefully underprepared to talk about myself and my motivation for applying to it. Why did you apply for it, if you hated the sound of it, I hear you ask? Excellent question. I had no idea what I was doing with my life, I hear myself answer.

This brings me to my first piece of advice, which I'll kick the useful part of this article off with.

1. Make Sure You Like What You're Applying To. 💫

If you don't show enthusiasm for the role or find yourself having to fake it, your interviewers will sense this and offer the role to a more motivated candidate. If you hate the way social media has contributed to the polarisation of society, try not to apply for a job at Facebook, unless you believe you can fix it (please... someone fix it. anyone..? ). If the sound of working for a local start-up that creates a productivity management tool sounds boring beyond belief to you, manage your own productivity better by saving yourself the hassle of an application.

2. Ten Applications A Day Keep the Salary At Bay. 👩‍💻

I see a lot of well-intentioned advice encouraging candidates to apply to ten positions a day. In my potentially controversial opinion, this is complete nonsense. In the best case scenario, you'll hear back from numerous companies, which will mean that you're now involved in too many recruitment processes at once. This won't give you enough time to do your due diligence and bring your best self to each interview. In the worst case scenario, you've spread yourself too thin and given each application so little thought that you barely hear back from anyone. I'd recommend you go for quality instead of quantity. One or two applications per day are plenty, especially if you're tailoring your CVs and cover letters uniquely to each position you apply to. Which is something you should really be doing!

3. Prepare Answers to Common Questions in Advance. 📝

The chance of you not hearing the following words from an interviewer at some point during the process is precisely zero: so, could you please tell us a bit about yourself... Knowing this gives you the power to absolutely ace this question. Below is a list of other guaranteed questions you might want to prepare for. The list should be particularly relevant to those who are transitioning careers, i.e. the target audience of this article.

Tell us a bit about yourself.
What prompted you to start coding?
What do you particularly like about front-end/back-end/data science/whatever-the-job-is?
Tell me about a time in your life when you successfully worked as part of a team.
Tell me about a time in your life when you successfully dealt with a challenging situation.
What made you apply to this particular position, in our particular company?
What are your favourite coding-related resources?
Do you have any questions for us?

I can pretty much guarantee that most of above questions, or some permutations thereof, will be asked. There is no reason you should have to think about these on the spot and struggle with a coherent reply. Take your time to think about these questions beforehand, and write your answers out. Read them, tweak them for maximum impact, commit them to memory.

Every interview is slightly different so you will still get ample space to improvise, but pre-empting as many questions as you can will make you a better candidate. This seems like extremely obvious advice, but many still don't follow it - make sure you slot yourself into the category of those who do to capitalise on this opportunity. I'd argue that preparing replies to commonly asked questions is the one easiest and most impactful step any candidate can take to stand out.

4. Talk to Yourself. Out Loud. Seriously. 📢

When preparing for your interview, don't do it in silence. Practice your replies out loud to get more familiar with how you want to convey your points. Interviews are by default a performative action, and like every performance, the more you do it, the better you get at it. Some even go as far as to advise candidates to record themselves and analyse how they come across - I'd say that's a step too far, but there's nothing wrong with standing in front of a mirror (or a willing other) and rattling your script down until you're happy with your "act".

5. Do Some Detective Work. 🔎

In this situation only, being a stalker is a perfectly acceptable way to be. Researching your interview panel is useful for two reasons. Firstly, you might get a better idea of what life at the company you're applying to is like, and what your job might entail. Having this knowledge will help you craft better answers during the interview. You might even pick up an impressive tidbit of information that you can impress the panel with during your interview. Secondly, you might get a better sense of the type of person the company hires. If you see any red flags here, run.

6. Leverage Your Non-Tech Background. ✨

No CS degree? No problem! Whatever it is you've been doing with your life, you must have learned a thing or two. The trick is to tailor your story towards the job you want and make your diverse background sound like a benefit, rather than a drawback of hiring you.

Did you work in hospitality before? You must know how to deal with people and be able to spontaneously improvise solutions to tricky situations really effectively! Were you in customer service? Your communication skills must be off the charts. Were you an athlete or a musician? Wow, I bet you have tons of discipline and will code us all under the table in a couple of years. Did you spend a few years traveling? How resourceful and adaptive that must make you! Are you perhaps a parent? You win by default, you literally created a human being. You must be incredibly organised and excellent at time management to juggle all that AND change your career.

Soft skills are important in any environment, and software engineering is no exception. Make your background work for you!

7. Bring Your Whole Self. ⭐

Don't hide your personality - display it proudly! Unless your personality sucks, in which case, definitely hide your personality. But seriously, your future employers are interested in who you are as a person as much as they are interested in your skills. You won't exist in a vacuum, on the contrary, you will constantly be interacting with others and contributing to a team, so being a person who's easy to get on with will go a long way.

You don't have to rely on solely professional examples to illustrate who you are - you are way more than just your previous jobs or studies. Feel free to draw on other areas of your life for examples of what makes you uniquely you. For example, I have a thing for acrobatics and enjoy balancing people on my shoulders. During my interview, I used the example of acrobatics to illustrate my approach to teamwork - in acrobatics, communication is just as important as skill and no human pyramid would ever go up would the entire team not be on the same page regarding effective communication.

8. The Fear Won't Persevere. 🙀

There is an aspect of interviewing that is unique to the interview itself and cannot be replicated during solo practice in front of a mirror - I mean the nerve-wracking, anxiety-inducing, "this-is-a-live-situation-and-I-only-have-one-chance" part of it all. I don't know about you, but I'm pretty much shaking before any interview. Even if on the surface I look calm and ready, you're likely to find vomit on my sweater already - mom's spaghetti. (I really hope this is a reference people get. I'm not that weird, I promise.)

Jokes aside, some adrenaline is helpful and leads you to think clearer, but too much of it can muddle your thoughts. I've found it helpful to internally reframe The Fear™ as simply Extreme Excitement™. I'm not dreading this and shaking out of fear, I just can't wait to seize this opportunity, that's all!

This, too, is a practicable skill. Even if you tend to get very unsettled by interviews at the moment, it doesn't mean you always will. The more interview processes you go through, the more practice you get with regulating your interview feelings, meaning you will interview better in the future.

9. Normalise Rejection. ❤️‍🩹

If you get rejected, you're just one interview closer to the interview that will result in a job offer. I know, this is easier said than done. But try to bear in mind that you're not alone. The struggle is real for all of us. Rejection is tough, but completely normal - just another day at the office, even for experienced developers. But equally importantly, don't beat yourself up over feeling down. We all have different emotional spans, and being someone who takes rejection to heart more significantly than others does not make you a worse (or better) candidate. Your feelings are valid, so accept them and let yourself experience them fully, prior to moving on.

10. Always Ask For Feedback. 🙋

If you've spent weeks of your life interviewing for a company and made it all the way through to the behavioural interview, the least the company can do after deciding to offer the job to someone else is provide you with useful feedback. If they don't do this, it means you likely dodged a bullet anyways. Frequently, the feedback you will receive will be useful and inform your next attempt. Other times, the feedback will be that you were this close to getting an offer, but someone else with the slightest bit of more directly relevant experience was in the end deemed a better choice. Whilst this type of feedback is not super useful, it should hopefully serve to raise your spirits and reassure you that you're very, very close. Either way, asking for feedback can only result in positive outcomes.

11. Don't Lie. 🤥

Last but not least, be honest - with yourself and with your interviewers. Pretending you are really into animations, when in reality you've barely ever encountered an SVG before, is unnecessary. At best, you might get offered the job and realise you've sold yourself as an expert when in reality you have no idea what you're doing, in which case you'll be found out immediately. At worst, faking expertise might lead to you coming across as cocky and never getting offered the job in the first place.

Nobody, I repeat, NOBODY, is an expert at everything. Senior devs get better at knowing exactly what it is they don't know, which makes it easier to ask the right questions and seek out answers in the right places. But even seniors would be lying if they claimed they're the absolute bee's knees at every single topic. If you're only just starting your tech career, it's much wiser to openly admit your technical gaps and frame them as areas of growth you are aware of and excited to explore.

Still with me?

Wow, you must really want that job. Now go get it! 🎉🎉

Let me know if I missed out on any techniques you might be aware of in the comments, and feel free to connect with me on Twitter or LinkedIn.

Coding Advice I Wish I'd Trusted Earlier

Sandra Spanik — Thu, 22 Apr 2021 14:03:37 +0000

I've recently celebrated my 1 year anniversary of picking up coding. A lot has changed in the past year, and I've been fortunate enough to recently get hired by a tech company for my very first software engineering role.

I know, I know... There's a plethora of advice articles like these out there, as was the case a year ago. Despite having read many myself when I was starting out, I remember being dismissive of some their advice, especially in cases where it was misaligned with my pre-existing intuitions. Umm, how about I ignore 24 different articles I've read that advise me to do a thing and instead proceed NOT to do it, thanksss. 💅

For example, having an online presence seemed a yucky and unnecessary waste of time. I'm now glad I re-examined my stance, because I was approached for my current position by a recruiter on LinkedIn. This wouldn't have happened, had I stubbornly clung to my notion that I can do this my own way without resorting to what I at the time considered to be nauseating concepts such as digital self-marketing.

So, in full acknowledgement that the body of literature is already vast, I'll add another voice "from the other side", in the hope that I might convince someone as stubborn as I was to give the below advice some consideration.

Without further ado, here's the advice I'd give my younger self as well as anyone else starting on their coding journey.

1. Consider Whether a Bootcamp is Right for You 🗺️

Do you need to attend a bootcamp in order to learn to code? Absolutely not. Are all the resources you need to learn to code available online for free? Absolutely yes. So, will you still benefit from completing a bootcamp? 🤔 Also yes! A curriculum designed by expert teachers will make it easier to learn things in the right order and avoid diving into topics that require pre-existing knowledge. For example, you should really start by learning vanilla JavaScript and regular DOM manipulation before exploring React. Otherwise, your mental model of how the frontend works will be lacking.

But bootcamps are a GIANT commitment. Before you dish out money and scale back other responsibilities to make time for what is a very intense experience - please make sure you actually like coding. This might seem self-explanatory, but there is a surprising amount of students who invest money and time prior to making sure they have a long-term interest in the subject.

Thankfully, a lot of cheap Udemy or free Youtube tutorials exist to help with this. Having a solid mental model of a programming language will set you up for success and make it easier to keep up with a bootcamp's fast pace. I started with Colt Steele's Udemy Modern Python Bootcamp, then continued with his Web Development Bootcamp before enrolling in an actual bootcamp. I could go on about what an excellent teacher with equally excellent pet-naming conventions Colt is (his chicken is called Stevie Chicks, guys, need I say more), but I'd only sound like a silly fan-girl. Instead, I will leave you with the names of some equally great instructors who also offer high-quality free or cheap courses: Angela Yu, Andrei Neagoie, Jose Portilla, but the list goes on.

2020 might have brought a pandemic, Zoom meetings and Cyberpunk 2077, but it has also graced us with an ever-increasing amount of online content creators putting out accessible courses. Take your pick!

2. Choose the Right Bootcamp 💻

If you are going down the bootcamp route (and your success doesn't by any means hinge on this, there are other ways), a word of warning: choose your bootcamp carefully. I could write a whole article on solid criteria to judge a bootcamp by (should I? Let me know in the comments), but ultimately, some of these will be subjective. Different teaching styles and curriculums suit different circumstances and learning styles. Personally, I was glad to have steered clear of bootcamps that either don't have an entry exam, or have an extremely easy one (e.g. "write a function that returns the sum of 2 numbers", or "return the first item in this array"). Bootcamps typically last anywhere between 3 to 9 months, and I am mistrustful of curriculums that promise to teach you all you need to know in a junior role within this time period without requiring any pre-requisites on your part.

I'm also sceptical of bootcamps that teach more than 2 languages - you might end up replacing depth of understanding with breadth and leave the bootcamp not feeling confident you can actually fully utilise the tools you now list on your CV. A good way to judge the quality of a bootcamp is to find graduates and look at their projects or portfolio sites - you might need to do some LinkedIn, Github or Twitter stalking to gather a large enough sample size to conclusively determine a bootcamp's quality. Connecting with and speaking with ex-students is also a great idea.

Lastly, check out SwitchUp and Coursereport for rankings and reviews.

3. Create a LinkedIn Profile - Early 👔

Whether you've chosen to do a bootcamp or are a brave self-learner, do not underestimate the power of networking. This one was the toughest piece of advice for me to digest, and I kept putting off creating a LinkedIn profile until my bootcamp's career service basically forced me to. For many of us, networking feels icky, digital self-promotion is a nauseating concept, and creating a LinkedIn profile feels akin to selling our soul to the devil. I, too, felt this way, and to a certain degree still do - I don't like living in a world which incentivises us shouting about our achievements from the top of our lungs and essentially marketing ourselves as products.

But LinkedIn also got me a job and connected me with many seriously impressive people. There's no two ways about it - if you're trying to break into tech via an unconventional route, you will benefit from having a LinkedIn account. Make sure your bio is well-written, concise and that you list any previous experience you might have, regardless of whether or not it is tech-related. The idea is that by the time you are ready for a job, you will already have a network of contacts and a history of consistently demonstrating your tech capabilities online, be it via deployed applications, posts or articles.

4. Write About Your Learning - Early 🖋️

This was another oft-repeated piece of advice I was initially sceptical about. What could I possibly contribute to the body of coding literature that hasn't already been said, by people a million times more qualified than me, a lowly degree-less peasant? I started writing articles about my learning relatively late, once I had already moved on from most backend topics. So from the outside, my online presence seems focused exclusively on frontend, and I had to convince my future full-stack role employer that I was equally, if not more, interested in backend.

If I could do it all again, I would definitely start writing way earlier. If you're put off by the fact that you don't know much yet and might make mistakes - don't be. No matter what you write about, chances are, someone out there will read your content and find it informative. More importantly, by writing about topics you're not expert on, you (hopefully) end up researching them more in-depth than you would otherwise.

Plus, if you make a mistake, people will let you know in the comments, and you'll have the opportunity to correct your mistake and learn. I cannot stress enough how helpful it is to write stuff out - I really wish I had started earlier, and my aim will be to continue writing, even as I transition into a full-time role, because I now know that it's an excellent way to solidify new knowledge.

5. Learn Version Control - Early(ish) 📁

Having a history of committing your code on Github is the easiest way to demonstrate your skills to recruiters. At some point, you will want to start uploading the exercises you complete to Github. Even though I started coding in April 2020, I didn't upload much to Github until November 2020, which is when my bootcamp started encouraging me to do so. What a waste, by then I had created a fair few full-stack applications that the world will never get to see! (They're terrible. The world lucked out.)

I should have started earlier, perhaps 2 months in. Learning Git can be confusing at first, so I would wait until I have a basic understanding of a programming language in order not to overwhelm myself. But a couple of months in, Git becomes a necessity. Once again, Youtube comes to the rescue.

6. Focus Your Energy Where It Matters ⏱️

If you're not just coding for the fun of it, but also aim to transition into the industry professionally, consider scaling back as many other commitments as you are able to. I'm aware this won't always be possible, for example, if you're a parent or relying on income from a full-time job (in which case you're an absolute trooper and my admiration for you doing all that AND re-skilling has no bounds). In my experience, there will come a time when you will start feeling compelled to make some tough decision about whether or not to give up other areas in your life to focus more on coding.

In my case, half-way through my (remote-first) bootcamp, I had to give up not one, but two part-time gigs that were keeping me afloat and rely on government assistance instead. It felt risky, and I also felt like I was letting people down by leaving my roles, but it has proved to be the right long-term move and I am proud of myself for having let go at the right time. It's a tough thing to do.

As with any skill, the more time and energy you spend on learning it, the better. It's a bit of a no-brainer, really. The difficult part is recognising, in real time, what truly matters and what can be filtered out. I hope it helps to know that if you're struggling to meet all your commitments alongside learning to code - you're not alone, many of us have been in a similar situation. There's no shame in letting go of jobs, hobbies or relationships that eat up our time and energy without giving much in return. In fact, it's a brave thing to do.

7. Taking Breaks is Key 💤

Having said this, increasing coding time doesn't always proportionally translate into more success - there is a limit, in my experience, to how much brain power one should devote to coding per day. This might vary on a case-by-case basis, but for me, this meant disengaging in the evenings and taking weekends off. We all operate optimally at different times of the day, so by all means follow your own circadian rhythm, but bear in mind that an overworked brain rarely produces good code.

As you can see, I take my breaks very seriously. I took Christmas off, and I barely ever code on weekends. This strategy will hopefully help me, in the long-run, prevent burnout and help me retain my child-like fascination for writing code.

What I was initially terrible at is knowing when to stop. There were days when I kept staring into my screen, frantically fixing fearsome bugs at night-time, after already having worked since the morning. Reliably, I'd fix a bug I was stuck on for many evening hours the previous day within the first 30 minutes in the morning. Equally reliably, next time, I'd tell myself that this time is different and this time I'll fix the bug in the evening, if I only spend 10 more minutes on it. Giving up and calling it a day was a difficult skill to learn - one that I am still perfecting.

8. Mindset Matters More Than You Might Think 🧠

You can learn anything, if you only believe it. This is not a vapid platitude, but our actual current scientific understanding of neuroplasticity. Each time you learn, your brain forms, strengthens or rearranges neural pathways. This means you have the power to actively and purposefully shape the physical outline of your brain - how cool is that. The belief that people can't change is not only archaic and wrong, it is also dangerous and leads individuals to accept malleable traits and skills as unchangeable constants.

There is a slight snag though - in order to learn best, it is beneficial to adopt the belief that you CAN, indeed, learn. Dismantle limiting beliefs such as "coding is similar to Maths and I'm just not a Maths person" or "I will never be expert at coding because I started too late in life", and you will have a better time learning.

Intelligence is not set at birth. Trust me, I wrote a dissertation in Psychology. Or don't, because let's face it, writing a dissertation in something years ago doesn't make you an expert. But do trust current academics. While there is an ongoing debate about the extent to which our genes predetermine our cognitive ability, the fact that any individual can greatly shape their intelligence is no longer disputed - not even a little. Having the belief that intelligence is not fixed but can instead be developed through our own efforts is also referred to as the growth-mindset. That's the mindset you want to apply to coding as well.

9. No, Programming is Not Easy, And That's Great 🏃‍♀️

Another beneficial expectation to keep in mind is that programming is hard. Don't expect it to be otherwise. It's really not easy to pick up coding from scratch, especially for someone who has never done anything like it before. It's a completely new way of thinking, and the ability to reason effectively about abstract concepts takes a while to develop.

Don't get discouraged by this fact - it's completely normal to struggle and to need to revisit concepts you thought you already mastered over and over again. With time, you will get better at asking the right questions and knowing exactly what it is you don't know, but don't ever expect yourself to know all the answers off the top of your head.

10. Let's Normalise Tears 💧

This final piece of advice is intended for me as much as it is intended for you. It's okay to feel things as you code, especially as you encounter challenging situations - of which there will be many. It's okay to feel joyous at successfully deploying an app, and it's equally okay to feel sad when CORS strikes again and things don't work.

Different people have different emotional spans. For cultural and, frankly, sexist reasons, the industry has typically attracted a certain type of person. You wouldn't normally associate this type of person with displaying a wide array of emotions. (An oversimplified generalisation, but it will do for the purposes of this article).

Nowadays, things are changing, and as a more diverse workforce enters the industry, I hope we gradually normalise feelings in a software engineering context. I, for one, feel things intensely on either end of the emotional spectrum, and I want to rid myself of the notion that displaying either positive or negative feelings is in some way shameful, or a sign of weakness. On the contrary, bringing feelings and empathy to a coding context is a bonus, because after all, the people using our software are just that - people, and being able to put ourselves in their shoes can only enhance a product.

Conclusion

I hope you will find the above advice useful. I recognise that we're all unique individuals, and as such our "best coding practices" might vary. What worked for me might not necessarily work for you. If, for example, you're the kind of person that doesn't mind working long hours and weekends, you might be able to get where I am now in half the time. But on average, I believe above advice to be general enough to apply to a large proportion of people reading this.

Thanks for reading, and happy coding! Or sad coding, for that matter. Your feelings are valid, whatever they might be.

Just know that you've got this! ✨💪

My Coding Journey - Becoming A Software Engineer in Under 1 Year

Sandra Spanik — Wed, 14 Apr 2021 16:15:20 +0000

I've written my first line of code exactly one year ago. Today, I'm preparing to start my new job as software engineer. Here's my story.

🌪️ The Interview to End All Interviews 🌪️

In February 2020, I ran out of an interview room with tears streaming down my face. I was interviewing for yet another administrative role at an educational institution I had precisely zero desire to actually do. The first part of the interview consisted of an Excel test, which I bombed - atomically. I remember already being at the verge of tears when the nice HR lady led me to the second room where I was to meet the interview panel, consoling me along the way and giving me well-meaning advice. "Don't worry - you can make up for this! Go meet the panel with your head held high!"

Heeding her advice, I held my head high as I promptly proceeded to knock over the glass of water the panel had prepared for me. Excellent start. The rest of the interview went by in a similar fashion, and by the end of it, it was clear to everyone and their mum that I didn't want the job, they didn't want to hire me, and that it was absurd we were all in the same room. When I got asked what topic's addition to their institution's curriculum graduates might benefit from, I went silent for a couple of seconds, then laughed and said, as a graduate of said institution, "Interview Skills". The joke landed.

An Exact, Unexaggerated Replica of My Mental State Post-Interview

After this tragic event I took the dramatic vow to never ever ever EVER interview for anything EVER again. I would die poor and hungry, but save myself the humiliation of continuously competing for and losing out on something I found deeply uninspiring.

🏡 Lockdown 🏡

Fast forward 2 months. It's now April 2020. Lockdown has robbed me of any distractions. I have ample time on my hands and I choose to invest it in learning new things. First, I do a Harvard MOOC on the chemistry of cooking. Many mouldy kombucha attempts and a now 12th-generation sour-dough starter called Bob later, I abandon my culinary aspirations and decide to replace pretending to be a Masterchef with watching Masterchef.

🖥️ Enter Coding 🧮

What could I learn next? How about something I've always found fascinating, incredibly cool but equally intimidating? There was no time pressure, for what seemed like the first time in years. I might as well get creative. Having a history of ascribing God-like qualities to and immediately falling in love with anyone capable of using a terminal, I knew just what I wanted to attempt to learn next: coding.

me, in love, after seeing virtually anyone use a terminal

😻 Colt Steele, The Absolute Legend 🐔

I was lucky to stumble upon Colt Steele's modern Python bootcamp. I purchased in on sale, and it remains the best £14 I've ever spent in my entire life. (I pity the fool that purchases a full-price Udemy course - there's a sale almost every month.) I have come to be a great fan of his teaching style and admire the rigour and depth he applies to explaining concepts. Before I knew it, I was dreaming about writing code.

I imagine that at this point, my story could have easily branched off in a different direction. I could have abandoned coding the second it got tricky, and thrown my Mac out along with the last remnants of my misguided fermentation attempts. But it felt like something had clicked - turns out, programming perfectly encapsulated everything I had always known I was quite good at and loved doing, namely:

creative problem-solving (nobody ever tells you how inherently creative coding actually it - but it is!)
logical/analytical thinking (a trait that wasn't always beneficial in my previous industry - mental health)
striving for efficiency (I am half-German, after all...)
learning new things (turns out, there's no shortage of things to learn in the realm of code)

💻 Pursuing Tech Professionally 💻

I got asked what precipitated my decision to pursue coding professionally during one of my interviews. I'm not sure I gave a good answer to this, because in reality, I didn't just wake up one morning and decide "right, tech is where it's at". My decision was forming over a number of months, as I explored Python, and later JavaScript and web development via cheap/free online courses. I was becoming more and more convinced that I didn't just thoroughly enjoy coding - I was also good at it, and learning at a fast enough pace that I could imagine myself, in the distant future, being quite adept at it.

This was a surprising finding. I grew up in 90s Slovakia, and encountered no computers in educational settings. Computer science seemed like a field reserved for a select few boys who spent their teenage years hacking away. By the time I was 18, I already considered myself too old to catch up and a career in tech, consequently, never even seemed to be within my realm of possibility.

I'm not saying that there are 0 Slovak women my age who were independent and brave enough to become software engineers, but on average, the cultural norm fed girls some limiting beliefs that took me almost a decade to dismantle.

🩹 The Ugly Bits 🩹

I prefaced this article with a promise to be fully transparent. These early months of learning to code from scratch were not exactly a walk through a rose garden. There were many days when I doubted my ability to learn. Not every topic immediately clicked with me - I cried over async JavaScript and for some reason, Axios (which I now love). I also cried over CSS, but who hasn't. It took me a while to adopt a beneficial mindset and stop seeing every bug or knowledge gap as a personal failure. I'm a billion times better at it now, but I'm still not perfect. This is a normal part of the learning process, I'm told.

Programming is an amazing way of getting comfortable with failing and accepting failure as a good thing. You will fail over and over again, and that's okay - it's the only way to learn. I find it amazing that I found a perfect metaphor for life inside a computer.

🎓 Finding the Right Bootcamp 🎓

Once I realised I wanted to transition to tech professionally, I decided to attend a bootcamp. Learning from a structured curriculum curated by expert teachers appealed to me, and the prospect of receiving a certificate to prove my skill felt like the right way to approach my job hunt. I attended Springboard's remote-first software engineering bootcamp, designed by Colt Steele The Absolute Legend and Rithm School, one of the world's top 10 bootcamps according to SwitchUp (note: Colt Steele doesn't actually refer to himself as an Absolute Legend and would likely sigh disappointedly at my doing so. He does have a chicken called Stevie Chicks, however, which proves my moniker correct.).

I was lucky to have half of my tuition waived. Although, I'm not sure "lucky" is an appropriate word choice here - my tuition was waived due to Springboard's scheme to help out 2 students per cohort who have suffered financially in the pandemic. By August 2020, most of my sources of income had dried up, and I was receiving government assistance.

I did continue working for a couple of mental health organisations as a contractor, which is part of the reason I chose a remote, self-paced bootcamp. It gave me the freedom to keep working to support myself at least somewhat.

🏋️‍♀️ Turns Out, Bootcamps Are Intense 🏋️‍♀️

My dedication towards splitting my time between working and studying evenly faded about three months into the bootcamp. I made the difficult decision to leave one of my contracting gigs behind. This felt risky - I already had a tiny income, so reducing it further seemed like a silly idea. But I wanted to put my energy and time where it mattered most - coding, and I didn't like the feeling of falling behind the suggested learning pace because I often had to prioritise work over learning.

The bootcamp was not easy, especially the first couple of months. It often felt lonely and frustrating. I didn't have a cohort to get to know or grow alongside of - all I had was a Slack channel which barely anyone used, and my best pal Google. Whilst I missed out on the social aspect of bootcamps due to the remote nature of mine, the course more than made up for this with a rigorous and extremely well-designed curriculum that focused on depth rather than breadth. I'm convinced that I owe my job-search success in large part to Springboard's flawless curriculum, and no, I'm not being paid to say this.

🔎 Job Search 🔍

At the 90% mark of my bootcamp, I started saying yes to recruiters approaching me on LinkedIn. Initially, I saw this as a good strategy to learn how to interview well, so that by the time I applied for my dream role, I would be ready. But my first ever interview process was with Trustpilot, and it quickly became apparent that I didn't just want to use this opportunity to "practice" - this was THE job, and I wanted it badly. I landed the role, less than a year after I wrote my first line of code. I'm hoping to share useful interview advice in an article that will come later in this series, so if you're keen to hear more, bookmark this.

✨ Luck ✨

As mentioned in the intro, I want to acknowledge the privilege I benefited from. First of all, I spent the year in a supportive and safe environment, and as someone who hasn't always had this, I've come to understand how crucial feeling safe is to personal development. It's nearly impossible to change your life when you have to spend energy on worrying about your own physical or emotional safety.

The world also kindly decided to go nuts and rob me of any distractions as I spent my days, weeks and months writing code. I am not in any shape or form glad that the pandemic happened, but I do need to acknowledge that one of its repercussions was me suddenly having all the time in the world to examine my life.

My partner is my number 1 fan and the world's best rubber-ducky. Whilst he's not in tech, he is fluent in Python, and his knowledge helped me immensely over the first couple of months. It also helped that, once I quit one of my admin jobs, I only had one part-time gig left and was pretty free to code on most day. Many others in my bootcamp were completing it alongside a full-time job or parental duties. My hat goes off to anyone who is a caretaker or juggling a full-time job whilst re-skilling. You're literally the most inspiring people in the Universe.

I also got lucky that a company with values that 100% overlap mine decided to hire a junior at exactly the time I began feeling ready for a job. What is more - the hiring manager, an inspiring person with a plethora of online public speaking videos, specifically told the recruiters that a computer science degree was not a pre-requisite for the role. Had this not been the case, I might have never heard about the position.

I will not go into a philosophical debate here, but I will say that I don't believe we have a lot of influence over the luck in our life, and I also don't believe we can "manifest" opportunities by the sheer power of our thoughts, as per The Secret. The Real Secret is, in my near-scientific and not at all subjective opinion, that hard work prepares us to benefit from those moments in our life when we experience random positive spikes in our fortune. So if you make smart choices and spend your energy wisely, you will be more likely to find yourself in a position where you can fully capitalise on random fortuitous opportunities, once they present themselves to you. And in time they likely will, because, well - statistics.

So, in conclusion... No, it's not too late to switch careers, and yes, you can do it too. Good ~~luck~~ hard work! ✨✨✨✨

I Got a Tech Job in Under a Year. Here's How.

Sandra Spanik — Tue, 13 Apr 2021 19:53:31 +0000

"Is this... an April fool's joke?"

...is what I asked the recruiter when he called me on the 1st of April to let me know I had gotten the job. It felt impossible, too good to be true - this was the first tech role I'd ever applied for, after all. Strictly speaking, even saying I applied for it is an exaggeration, because in truth, I was approached by a recruiter on LinkedIn. My portfolio page wasn't up yet (it still isn't), and my bootcamp was only 90% finished. On paper, I was less ready than many others out there. I couldn't believe my luck - I had actually secured a job offer from one of Europe's fastest growing tech companies. For someone with no computer science degree and a background in mental health and administration, this was life-changing stuff.

actual footage of my impostor syndrome kicking in the second I got the job

Despite what the admittedly clickbait-y title of this article suggests, it will not focus on me blowing my own trumpet and letting everyone know just how smart and uniquely awesome I am (although, of course I am... 😏). Instead, I will offer some well-meaning advice and talk openly about my often challenging but ultimately rewarding experience of transitioning careers from mental health to tech in under a year, warts and all. I will let you know what I did to get to where I am now, but importantly, I will also acknowledge the large role circumstances outwith my control played over the last year.

Don't get me wrong - I've worked incredibly hard for this - sweat, blood and literal tears went into the process. Of course I think I deserve the company's faith and I'm determined to continue growing and proving myself worth their trust. But I want to qualify my success with external factors that helped me get here.

I've previously caught myself feeling jealous of people who wrote similar articles without acknowledging how much luck or support they had along the way. Social media is by design a place where we share our highlight reels, and more often than not, we remain silent about the uglier parts of our lives, or the privilege we get to benefit from. My aim is to be fully transparent, and in doing so, prevent anyone reading this from feeling bad about themselves just because their job search or learning process might be taking longer than mine did.

So whether you are a newbie starting to learn how to code or a bootcamp-graduate already in the market for your first tech job, keep reading, this series of articles is for you. You've got this. I promise.

The focus of this series will be split across 3 topics, which I'll release over the coming days. If you're more interested in practical advice than my journey, fair enough, feel free to skip ahead to Part 2.

1. My Coding Journey - the Good, the Bad, the Ugly

2. What I Wish I Knew When I Started Coding

3. Interview Advice

Pure vs Impure Functions

Sandra Spanik — Thu, 18 Mar 2021 15:05:33 +0000

Software engineering is full of jargon. Occasionally, to grasp the true meaning of the seemingly simplest of words, one must waddle through many murky layers of complexity (fancy defining this, anyone?). Thankfully, other times, outwardly inaccessible words can be demystified pretty easily. In this article, we'll deal with the latter case, breaking down pure vs impure functions.

person thinking about the definition of this

1. Pure Functions 👼

To be considered pure, functions must fulfil the following criteria:

they must be predictable
they must have no side effects

➡️ Pure functions must be predictable.

Identical inputs will always return identical outputs, no matter how many times a pure function is called. In other words: we can run a pure function as many times as we like, and given the inputs remain constant, the function will always predictably produce the same output. Kind of like when you're a pizza-loving person with lactose intolerance. No, this time won't be different, so stop ogling that 16-incher your flatmate ordered.

➡️ Pure functions must have no side-effects.

A side-effect is any operation your function performs that is not related to computing the final output, including but not limited to:

Modifying a global variable
Modifying an argument
Making HTTP requests
DOM manipulation
Reading/writing files

A pure function must both be predictable and without side-effects. If either of these criteria is not met, we're dealing with an impure function.

An impure function is kind of the opposite of a pure one - it doesn't predictably produce the same result given the same inputs when called multiple times, and may cause side-effects. Let's have a look at some examples.

// PURE FUNCTION 👼
const pureAdd = (num1, num2) => {
  return num1 + num2;
};

//always returns same result given same inputs
pureAdd(5, 5);
//10
pureAdd(5, 5);
//10

//IMPURE FUNCTION 😈
let plsMutateMe = 0;
const impureAdd = (num) => {
  return (plsMutateMe += num);
};

//returns different result given same inputs
impureAdd(5);
//5
impureAdd(5);
//10
console.log(plsMutateMe)
//10 🥳 I'm now double digit, yay!

In the above example, the impure version of the function both changes a variable outside its scope, and results in different output, despite being called with identical input. This breaks both rules of pure functions and as such, it's pretty clear we're dealing with an impure function here.

But let's have a look at an example of an impure function that is not so easy to tell apart from its pure counterpart.

//IMPURE FUNCTION 😈
const impureAddToArray = (arr1, num) => {
  arr1.push(num);
  return arr1;
};

impureAddToArray([1, 2, 3], 4);
//[1,2,3,4]
impureAddToArray([1, 2, 3], 4);
//[1,2,3,4]

Given the same inputs, the function above will always return the same output. But it also has the side effect of modifying memory in-place by pushing a value into the original input array and is therefore still considered impure. Adding a value to an array via a pure function instead can be achieved using the spread operator, which makes a copy of the original array without mutating it.

//IMPURE FUNCTION 😈
const impureAddToArray = (arr1, num) => {
  //altering arr1 in-place by pushing 🏋️
  arr1.push(num);
  return arr1;
};

// PURE FUNCTION 👼
const pureAddToArray = (arr1, num) => {
  return [...arr1, num];
};

Let's look at how we'd add to an object instead.

// IMPURE FUNCTION 😈
const impureAddToObj = (obj, key, val) => {
  obj[key] = val;
  return obj;
};

Because we're modifying the object in-place, the above approach is considered impure. Below is its pure counterpart, utilising the spread operator again.

// PURE FUNCTION 👼
const  pureAddToObj = (obj, key, val) => {
  return { ...obj, [key]: val };
}

Why should I care?

If the differences in the above examples seem negligible, it's because in many contexts, they are. But in a large-scale application, teams might choose pure over impure functions for the following reasons:

Pure functions are easy to test, given how predictable they are
Pure functions and their consequences are easier to think about in the context of a large app, because they don't alter any state elsewhere in the program. Reasoning about impure functions and potential side-effects is a greater cognitive load.
Pure functions can be memoized. This means that their output, given certain inputs, can be cached when the function first runs so that it doesn't have to run again - this can optimise performance.
The team lead is a Slytherin obsessed with the purity status of both blood and functions (are we too old for HP references? I think not).

Pure functions are also the foundation of functional programming, which is a code-writing paradigm entire books have been written about. Moreover, some popular libraries require you to use pure functions by default, for example React and Redux.

Pure vs Impure JavaScript Methods

Certain JS functions from the standard library are inherently impure.

Math.random()
Date.now()
arr.splice()
arr.push()
arr.sort()

Conversely, the below JS methods are typically associated with pure functions.

arr.map()
arr.filter()
arr.reduce()
arr.each()
arr.every()
arr.concat()
arr.slice()
Math.floor()
str.toLowerCase()
the spread syntax ... is also commonly used to create copies

1. Comparison

So who comes out as a winner in this battle between good and evil? Actually, nobody. They simply have different use cases, for example, neither AJAX calls, nor standard DOM manipulation can be performed via pure functions. And impure functions aren't intrinsically bad, they just might potentially lead to some confusion in the form of spaghetti code in larger applications.

Sidenote: I resent the widely held sentiment that the word spaghetti should ever be associated with anything negative. Get in my tummy and out of coding lingo, beloved pasta. 🍝

I'll leave you with a quick tl;dr comparison table.

👼 Pure Functions 👼	😈 Impure Functions 😈
no side-effects	may have side-effects
returns same result if same args passed in no matter how many times it runs	may return different result if same args passed in on multiple runs
always returns something	may take effect without returning anything
is easily testable	might be harder to test due to side-effects
is super useful in certain contexts	is also super useful in certain contexts

Implementing Dark Mode in React via Context

Sandra Spanik — Wed, 03 Mar 2021 13:48:18 +0000

One would think the timeline we live in is dark enough, but for some reason, developers are obsessed with giving users the option to make their lives even darker. In this article, we will go over how to implement toggling between dark and light mode in React. We'll also have a closer look at React Context, the tool we'll be using to achieve this.

Let's start with a simple React app with 6 components: a Button, a Navbar, as well as a nested "family" consisting of Grandparent, Parent, Child and Baby. Our top-most App component includes Navbar and GrandParent, and GrandParent in turn contains Parent, which contains Child, which contains Baby.



function App() {
  return (
    <>
      <Navbar />
      <div className="App-div">
        <GrandParent />
      </div>
    </>
  );
}

Let's assume, for ease of variable naming, that it's perfectly logical for a child to have a baby, and for this baby to have a grandparent instead of a great-grandparent. Now that our disbelief is suspended, let's look at what this might look like in light mode below.

Sidenote: the monstrosity above acts as a nice segue into letting you know that clearly, the focus of this article will not be CSS, but the implementation of the React logic which enables us to easily switch between CSS classes across all components. If you're looking for aesthetically pleasing dark mode CSS, keep looking, and best of luck to you.

The aim is to eventually end up in a place where the user can toggle between the current light mode and dark mode by simply clicking on a toggle switch or icon in the Navbar.

Step 1: Add Toggle Switch / Icon

Toggle switches are actually heavily styled inputs of the type checkbox. Nobody implements toggle switches from scratch. Nobody. Not a single person. Unless they like CSS, which I hear can be the case for a select few 😯 So let's grab some code, for example from here, and add our switch to the navbar. You could also instead add buttons wrapped around sun/moon icons, for example from here. Our page now looks like this:

Beautiful!

Step 2: Share Data Between Components

To implement dark mode, we'll need to find a way to share data between components efficiently. Let's say that in our example, the GrandParent component wanted to share something with the Baby component. One way to do this would be to define a variable or piece of state at the GrandParent level and pass it down via the Parent and Child components all the way to the Baby component, like so:

The GrandParent defines the variable and passes it down to the Parent.



const GrandParent = () => {
  const grandmasFavSong = "Toxic by B. Spears";
  return (
    <div className="GrandParent-div">
      <Parent grandmasFavSong={grandmasFavSong} />
      <div>I AM THE GRANDPARENT 👵  and my fav song is {grandmasFavSong}</div>
      <Button />
    </div>
  );
};

The Parent destructures the grandmasFavSong prop and passes it down to Child. Arduous...



const Parent = ({ grandmasFavSong }) => {
  return (
    <div className="Parent-div">
      <Child grandmasFavSong={grandmasFavSong} />
      <div>I AM THE PARENT 👩</div>
      <Button />
    </div>
  );
};

The Child now also has to destructure the prop and pass it down to the Baby component. 🥱🥱🥱



const Child = ({ grandmasFavSong }) => {
  return (
    <div className="Child-div">
      <Baby grandmasFavSong={grandmasFavSong} />
      <div>I AM THE CHILD 🧒 </div>
      <Button />
    </div>
  );
};

Finally, the Baby component knows of Grandma's secret obsession.



const Baby = ({ grandmasFavSong }) => {
  return (
    <div className="Baby-div">
      <div>
        I AM THE BABY 🍼  why is grandma making me listen to {grandmasFavSong}??
      </div>
      <Button />
    </div>
  );
};

You might have noticed that this is not a very elegant way of achieving data sharing between components. Doing this is known as prop drilling. It's considered bad practice and should be avoided, much like its cousins oil drilling & tooth drilling. Best to just avoid drilling of any kind. Thankfully, React provides a neat alternative.

Enter React Context.

In life as well as in React, context is key. React Context provides a way to share data between components without having to pass it down as a prop through each level of the component hierarchy. Using said React Context is a better way to share grandma's unhealthy obsession with 2000s pop than what we've seen above. The workflow is as follows:

Create Context
Add the data intended to be shared to Context
Wrap a Context provider around the components that need access to it
Consume the Context provider wherever needed

Let's go through this step by step.

1. Create Context

We'll do this in a new file called MusicContext.js:



import React from "react";

export default React.createContext();

That's all? Yep, that's all.

2. Add the data intended to be shared to Context

Let's create a new file called MusicProvider.js. We'll define our data here, and use the children prop to make sure every component the MusicProvider is wrapped around has access to our values.



import React from "react";
import MusicContext from "./MusicContext";

const MusicProvider = ({ children }) => {
  const grandmasFavSong = "Toxic by B. Spears";
  return (
    <MusicContext.Provider value={grandmasFavSong}>
      {children}
    </MusicContext.Provider>
  );
};
export default MusicProvider;

3. Wrap the Context provider around relevant components

In this case, we don't need our Navbar to have access to the data, but we do want GrandParent and Baby to have access. And so, we'll wrap the provider around GrandParent, within which all the other Family components are nested.



import MusicProvider from "./Context/MusicProvider";

function App() {
  return (
    <>
      <Navbar />
      <div className="App-div">
        <MusicProvider>
          <GrandParent />
        </MusicProvider>
      </div>
    </>
  );
}

4. Consuming Context wherever needed

We want to display the data in the GrandParent and Baby components. We'll need to take the following steps in each of the files:

Import the useContext hook from React
Import MusicContext (not MusicProvider)
Extract the variable out of Context

Let's look at how to do this is the Baby component:



import React, { useContext } from "react";
import "./Family.css";
import Button from "./Button";
import MusicContext from "../Context/MusicContext";

const Baby = () => {
  // extracting variable from context ⬇️⬇️
  const grandmasFavSong = useContext(MusicContext);
  return (
    <div className="Baby-div">
      <div>
        I AM THE BABY 🍼  why is grandma making me listen to {grandmasFavSong}??
      </div>
      <Button />
    </div>
  );
};

export default Baby;

After doing the same for GrandParent, our app should look as it did before. Whilst it's not immediately obvious that this is a more efficient way of sharing data between components than prop drilling in our tiny app, trust me when I tell you that the utility of using Context scales with application size and number of components.

What about dark mode?

Now that we understand React Context, let's use it to implement dark mode. There's many ways to achieve this, but here we'll use the class dark and associate it with dark-mode styling in our CSS. The class dark will be rendered in relevant components conditionally using the ternary operator. Let's use our Button component as an example:



import React from "react";
import "./Button.css";

const Button = () => {
let darkMode = isDark ? "dark" : "";
  return (
    <button className={`Button-btn ${darkMode}`}>
      {isDark ? "Dark" : "Light "} button
    </button>
  );
};

export default Button;

Now, let's follow through the same steps as when we were handling music Context.

1. Create The Context in ThemeContext.js:



import React from "react";

export default React.createContext();

2. Add values to the Context provider

We'll define our state, isDark, in a file called ThemeProvider.js. We will also define a function that toggles isDark. Both will be passed to the provider's children as Context values. This time, since we have more than one value, we'll wrap them in an object.



import React, { useState } from "react";
import ThemeContext from "./ThemeContext";

const ThemeProvider = ({ children }) => {
  const [isDark, setIsDark] = useState(false);
  const toggleMode = () => {
    setIsDark((mode) => !mode);
  };

  return (
    <ThemeContext.Provider value={{ isDark, toggleMode }}>
      {children}
    </ThemeContext.Provider>
  );
};

export default ThemeProvider;

3. Wrap the Context provider around relevant components

This time, we'll want to wrap it around all components, including our Navbar.



import "./App.css";
import GrandParent from "./Family/GrandParent";
import "./Family/Family.css";
import Navbar from "./Navbar/Navbar";
import MusicProvider from "./Context/MusicProvider";
import ThemeProvider from "./Context/ThemeProvider";

function App() {
  return (
    <ThemeProvider>
      <Navbar />
      <div className="App-div">
        <MusicProvider>
          <GrandParent />
        </MusicProvider>
      </div>
    </ThemeProvider>
  );
}

export default App;

4. Consuming Context wherever needed

Let's again use our Button component as an illustration:



import React, { useContext } from "react";
import "./Button.css";
import ThemeContext from "../Context/ThemeContext";

const Button = () => {
  const { isDark } = useContext(ThemeContext);
  let darkMode = isDark ? "dark" : "";
  return (
    <button className={`Button-btn ${darkMode}`}>
      {isDark ? "Dark" : "Light "} button
    </button>
  );
};

export default Button;

After following a similar approach in each component that we want to be affected by the mode changing, the only thing left to do is to implement its toggling. We're already sharing the toggle function via Context, so let's grab it where we need it: in the ToggleSwitch component. We'll create an event that fires on click and triggers the mode toggling.



import React, { useContext } from "react";
import "./ToggleSwitch.css";
import ThemeContext from "../Context/ThemeContext";

const ToggleSwitch = () => {
  const { toggleMode, isDark } = useContext(ThemeContext);

  return (
    <div className="ToggleSwitch-div">
      <label className="switch">
        <input onClick={toggleMode} type="checkbox" />
        <span class="slider round"></span>
      </label>
    </div>
  );
};

export default ToggleSwitch;

Rejoice! 👏👏👏 We're done. Now our app looks like this, or indeed much much better, depending on how much effort we put in our CSS.

React Effect Hook Explained

Sandra Spanik — Mon, 15 Feb 2021 20:35:34 +0000

I've recently learned about React's inbuilt useEffect hook and let me tell you - it's neat! 💙 It's commonly used to retrieve data from external APIs and handle timers. This article will walk you through a step-by-step implementation of a timer component via the useEffect hook.

Let's say our timer component should update each second, like so:

If you're new to React, you might be tempted to define an interval at the top level of your component, as below:

import React, { useState } from "react";
import "./TimerDemo.css";

const TimerDemo = () => {
  const [seconds, setSeconds] = useState(0);

 setInterval(() => {
    setSeconds((s) => s + 1);
  }, 1000);

  return (
    <div className="TimerDemo">
      <h1>Timer Demo</h1>
      <div>⌛ {seconds} ⌛</div>
    </div>
  );
};

export default TimerDemo;

However, the above code will result in the following output.

What's going on here? Has React broken the Universe and altered the rules of spacetime? 👽 Not quite. What's happening here is that multiple intervals are being set over and over in quick succession.

When the component renders for the first time, the interval is set, which changes the state of seconds each second. Once the state changes, a re-render of the entire component is immediately triggered, and the code inside the component runs once more. Upon running, the code will result in another, identical, interval being set. But the old interval will also continue doing its thing and manipulating the state of seconds.

So now we have two intervals that are both behaving the same way: updating state each second and triggering the component to re-render. Each re-render will lead to more fresh intervals being set, which in turn will trigger state change. This cycle - a positive feedback loop - will repeat ad infinitum (or more likely ad browser-crashium). 🔁

The correct way to handle timers in React is by using the splendiferous useEffect hook. The top 3 things to know about this hook are:

it accepts a callback function as the 1st argument
it accepts an array as its optional 2nd argument
it returns null, but can optionally be customised to return a function, which is useful for "cleanup" purposes
it's hard to represent emojitively, because there isn't yet cross-browser support for the hook emoji, so here's an anchor instead ⚓ (okay, this one was a bonus)

We'll examine how each of these points relates to handling timers in React. (Except the emoji one. Which doesn't.)

1. `useEffect` Callback Function

The first argument the hook accepts is a callback function. This function is what React understands to be the "effect". In this case, the effect is our interval. Let's define it inside a useEffect hook.

const TimerDemo = () => {
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    setInterval(() => {
      setSeconds((s) => s + 1);
    }, 1000);
  });

  return (
    <div className="TimerDemo">
      <h1>Timer Demo</h1>
      <div>⌛ {seconds} ⌛</div>
    </div>
  );
};

This will display as the following:

Not at all what we want, our issue remains. This is where the second argument of the useEffect hook comes into play.

`useEffect` Dependency Array

The second argument is an optional array of state or prop values, which specify when the effect should run. We have 3 options here:

No array: if the array is left out, as in the previous code snippet, the effect will run after every render.
Empty array: the effect runs once after the initial render.
Array with state or prop values: the effect runs only when any of these values change.

In our case, if we passed in [seconds], we would tell React to re-run the effect each time the state of seconds changes. Which would, of course, be completely pointless - in fact, this is exactly what we're trying to avoid.

And avoid it we can; specifically, by passing in an empty dependency array, []. An empty array tells React to only run the effect once, after the component renders for the first time. Let's examine the code below:

const TimerDemo = () => {
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    setInterval(() => {
      setSeconds((s) => s + 1);
    }, 1000);
  }, []);

  return (
    <div className="TimerDemo">
      <h1>Timer Demo</h1>
      <div>⌛ {seconds} ⌛</div>
    </div>
  );
};

Voila! The timer works now.

useEffect Return Function

But what would happen to the interval if we removed the timer component from the DOM? Let's create a scenario where it is removed by wrapping it in another component, Clock, which toggles the timer component. Let's also include a toggle button that removes or adds the timer component to the DOM.

const Clock = () => {
  const [isHidden, setIsHidden] = useState(false);
  const toggle = () => setIsHidden((hidden) => !hidden);

  return (
    <div className="Clock">
      {!isHidden && <TimerDemo />}
      <button class="Clock-btn" onClick={toggle}>
        Toggle
      </button>
    </div>
  );
};

At first glance, removing the TimerDemo component from the DOM appears to work as intended. But upon opening the console, an angry sea of red appears. React is not happy. 😡

Why is this? Well, when the component is removed, despite disappearing visually, the interval associated with it simply keeps going. There's nothing telling it to stop executing. The interval will proceed to try and update the state of a currently unmounted component, greatly upsetting React in the process. Poor React! 🥺

So, how do we tell the interval to stop when the component is removed from the DOM? By specifying useEffect's return value. By default, it returns null, but we can modify this to return a callback function, which will act as "cleanup". Warning: the cleanup function can feel a bit abstract to read about, and the best way to befriend it is to use it and explore its functionality first-hand.

The cleanup is executed at the following times:

After the initial rendering, the hook only invokes the effect. The cleanup function doesn't run
On all following re-renderings, the cleanup from the previous effect execution is invoked first, after which the current effect runs
The cleanup also runs after the component is unmounted, i.e. removed from the DOM

Let's define our cleanup function. In order to stop an interval, we need to capture the interval ID and pass it into a clearInterval function (a vanilla JS concept). We'll return this function inside our useEffect and add some print statements to monitor the sequence of execution.

  useEffect(() => {
    console.log("I am the effect. PARTY! 🎺 👐 🎉");
    const timerId = setInterval(() => {
      setSeconds((s) => s + 1);
    }, 1000);

    return () => {
      console.log("Cleaning up... 🙄 🧹🧼");
      clearInterval(timerId);
    };
  }, []);

In this case, the effect runs when the component is mounted, but never again, due to our 2nd argument, the dependency array, being empty. Therefore, the cleanup function will only run when the component is unmounted, thereby clearing the interval and preventing the error message. The toggle button now works as intended, and React is so happy it can barely contain its excitement.

I hope you are too, after making it through this tutorial! 👏

So You Want to Learn React?

Sandra Spanik — Thu, 04 Feb 2021 18:25:53 +0000

I'm pretty sure that Facebook is right up there in the category of Top 5 Innovations with The Most Awful Unintended Consequences Ever. A rising threat to our democracies, it has caused the fragmentation of our collective reality and sent our mental health plummeting. HOWEVER, did you know that Facebook also developed React? 😍 All is forgiven!

So you want to learn React? Excellent choice, it's great fun! It does require some pre-existing knowledge though. Here's the bare minimum of JavaScript skills to brush up on before attempting to learn React.

1. Package managers
2. Ternary operator
3. Destructuring
4. Array methods - especially map & filter
5. Arrow functions
6. ES6 modules

I'll provide a brief example of each of above in this article, but please be aware that there's a lot more to explore about each of the topics listed than I will go into here.

1. Package managers

React requires some dependencies to run. For instance, you will be writing JSX, a mixture of HTML and JavaScript, which has to be transpiled into regular JavaScript. React uses Babel for this. You will also need to install react-dom to render top-level components. Presumably, you will also want to test your React application and install a testing library. For learning purposes or single-page applications, you might want to install Create React App, which loads up a fully pre-configured application.

The easiest way to manage your package ecosystem is by using a package manager such as npm or Yarn. Overall, you should really be comfortable with installing dependencies and running scripts with your package manager of choice.

2. The Ternary Operator

If you say 'ternary operator' 3x in a row quickly, you're basically saying "The Terminator". And much like The Terminator, the ternary operator is efficient, nice to look at and designed to save the world from impeding doom (in this case the doom of disorganised code).

Let's say that in order to be The Terminator, a person only needs to fulfil 2 conditions, namely having a German accent, and an abnormally high muscle mass. In ternary operator form, this could be expressed as:

let person; 
const fulfilsConditions =
  muscleMass === "abnormally large" && accent === "German";

fulfilsConditions
  ? (person = "The Terminator 💪")
  : (person = "Not The Terminator 😥");

You will see this pattern frequently used in React, where whether or not certain elements are rendered depends on conditions being met.

3. Destructuring

Destructuring assignment might be confusing when first encountered, but is immensely helpful and a concise way to write code. Alongside other cool superpowers, it is capable of the following:

const fruits = ["🍓", "🍍"];
const [strawberry, pineapple] = fruits;
console.log(pineapple);
// 🍍

You can do the same with objects.

moreFruits = { coconut: "🥥", banana: "🍌" };
const { coconut, banana } = moreFruits;
console.log(coconut)
// 🥥

In React, destructuring assignment is used all the time to access props or use state.

4. Array methods - especially `map` & `filter`

Everybody loves a bit of Array.map in their lives. Map takes an array, transforms its elements and returns these in a new array, all without mutating the original array. It transforms the elements by calling a provided function on each of them, as below:

const numsArr = [2, 4, 25];
const doubleNumsArr = numsArr.map((num) => num * 2);

console.log(doubleNumsArr);
// [4, 8, 50]

If you're a visual learner, you might find it helpful to consider the following non-code code, where we're transforming each egg in the array into a fried egg by applying fire to it:

const eggs = ["🥚", "🥚", "🥚"];
const friedEggs = eggs.map((egg) => egg + "🔥");

console.log(friedEggs);
// ["🍳", "🍳", "🍳"]

Array.filter is similar, in that it does not mutate the original array and creates a new one. But in this case, each element is tested against a provided function, and only those elements that fulfil the condition the function specifies are added to the returned array. See below:

const animals = ["🐈 ", "🐖", "🐖", "🐶"];
const onlyPigs = animals.filter((animal) => animal === "🐖");

console.log(onlyPigs);
// ["🐖", "🐖"]

Both Array.filter and Array.map are used extensively in React, especially when manipulating data from external APIs and rendering it as components. They're sometimes even chained together, i.e., filtering the data before transforming it into a renderable format. You'll definitely need to be comfortable with using these methods.

5. Arrow functions

On a similar note, you should also be comfortable with using ES6 arrow function syntax in general. Specifically, you should understand the difference between an implicit and explicit return, otherwise your bracket game will be off. The following should make sense to you:

function addSparkles(boringString) {
  return `${boringString} ✨`;
}

//above will evaluate to the same as ⬇️

const addSparkles = (boringString) => `${boringString} ✨`;

//which will evaluate to the same as ⬇️ 

const addSparkles = (boringString) => {
  return `${boringString} ✨`;
};

console.log(addSparkles("Please make me more visually appealing"));
// Please make me more visually appealing ✨

In a React context, arrow functions can prevent bugs relating to the use of "this" because they inherit "this" from their enclosing scope. And let's be honest, they look much nicer and save ample space. So, although you can achieve anything that an arrow function does by using older syntax, it is extremely beneficial to learn the ES6 way before delving into React.

6. ES6 Modules

Files that use React will typically contain at least import React, { useState } from "react"; at the top of the file and export default MyComponent; at the bottom. If you are like me and prefer the Python way of handling imports/exports, it will be useful to brush up on how this syntax works.

Is that it? 🧐

While this list is not exhaustive, it is a good benchmark for the skill-level required to fall in love with React. If you are familiar with all of above, congratulations, you are ready for React! But even if you are still shaky on some of these concepts, you might want to delve right in. After all, there's no better way to learn coding than by... well, coding.