So many entry level developers nowadays are coming from non-traditional backgrounds (like me!), i.e. coding bootcamps, self-taught experiences, and that is amazing and wonderful. However, one thing that is often lacking in our preparation is a focus on testing; this is a shame because it is actually quite an important skill to know. You will see it as part of many job requirements and you will definitely encounter the question as to how you’ve tested your code during job interviews. …

Developers know that it’s important to test their code. There is a difference, though, between knowing a thing is important and actually doing that thing. Oftentimes developers prioritize extending their code rather than dedicating time to writing tests for the code that they’ve already completed.

So I wanted to take some time to explore testing in code. What is it, why does it need to be done? Are there different types of tests?

What is testing and why does it need to be done?

In the past, software testing was a very manual task. You would run your code in a test environment and then follow some pre-determined series of clicks…

One of the great things about being a developer is that we get to see projects using multiple lenses. We undoubtedly will end up preferring some language or framework or library…but we will have the opportunity to explore a number of different environments. And that keeps things interesting, right?

Absolutely! Except when it’s kind of stressful because you have some important project to complete and you have to scramble to learn something new by an impending deadline. …

When we learn to code, many of us tend to adopt practices that were taught to us without immediately understanding the details of the “why”. I mean, we get a general idea of what’s going on, of course, but a lot of times we’re focused on getting a handle on how to use some bit of code and making sure that bit of code interacts with other bits of code. We want to move on to learn something new in order to put together a deliverable, something that we can include in a portfolio, something that we can “show”.

One…

I grappled with a Leetcode problem a while ago where I was asked to rotate an image. The image was actually a 2D matrix, which is essentially an array of arrays. The image needed to be rotated 90 degrees clockwise and it had to be done IN PLACE…in other words, I could not create a new matrix as part of the solution.

A while back, I solved a Leetcode problem with an absolutely horrendous run time, only beating roughly 9% of Javascript submissions. It was the containsDuplicate problem and it’s a fairly simple one:

The goal of this exercise is to talk about a little known hook called useRef. This hook is similar to the ref system I spoke about in a previous article (link here), but there are some key differences to keep in mind.

To illustrate this hook we’re going to create a dropdown, where the overall goal will be to show a list of options. A user will click on the dropdown and a menu will open up with a list of colors that a user can select…whatever color is selected, some text will show up in that color. Easy enough.

I was recently asked a question about how to scale an app. When I work on my own personal React projects, I don’t really think about scaling…I mainly focus on playing around with code to understand all its nuances. That’s probably the case with a lot of new developers…if you’re just working on a small project, thinking about scaling can actually get in the way of the creative work. In fact, a number of solutions to scaling introduce complexity and abstraction, which in turn can make testing code harder, fixing bugs and introducing new features becomes more difficult and and…