DEV Community: Jonathan Sexton

How I Quit My Job and Started Freelancing Full Time

Jonathan Sexton — Tue, 05 Oct 2021 13:37:45 +0000

A lot of us have some variation of the dream where we quit our 9 to 5 grind and work for ourselves while we rake in the cash. As of 2020, 36% of the total US work force (59 million people) were freelancers and that percentage is growing faster relative to other forms of work.

But how do you get there?

The answer is: There are hundreds, if not thousands, of ways.

There isn't an exact formula unfortunately as the journey can be an uncertain one. I'm going to share the way I did it. It may work for you or you may need to adapt certain aspects to fit your particular situation.

Some of you may be looking to go straight from learning/graduating into freelancing and that's definitely a viable option, it's just not the route I took.

I had a full time job before starting to freelance, so my advice will be centered around that path.

Also, I'm assuming you understand the legalities of freelancing in the US (i.e. You've already taken care of the appropriate local, state, and federal paperwork, setting up a bank account, paying taxes, etc).

Brief History of Working Background

I have been working in the tech industry for going on three years now but before that I was in sales and customer service industry for roughly twelve years.

I won't go too deep into details but if you want a deeper dive into my history, I've written several relevant articles: Conquering Interview Code Challenges v1, Conquering Interview Code Challenges v2, and How I landed My First Job in the Tech Industry.

Shortly after getting hired as a full time developer, I started freelancing on the side to bring in extra income for bills and to squirrel away for a financial rainy day.

Now that you're up to speed, let's get into the good stuff: how did I go from freelancing as a side hustle to freelancing as a main job?

Sacrifices Must Be Made

Here's a look at my daily schedule while I was making my way into full time freelancing

Since I had a full time job, I needed to make time in my schedule before and after my 9 to 5 to accommodate my freelance work.

I started scheduling everything about my day from the time I woke up, to down time I spent with my family, to the time I went to bed, etc. This will required me to take a good look at where I could cut out time wasting activities.

Some of the things I sacrificed:

Spending time with friends on the weekend
Social events
Watching TV, playing video games or scrolling through social media in free time
Spending on vacation trips
Spending on adventures and experiences
Dining out regularly
Staying up late at night
Spending my lunch break watching funny videos

This list could go on and on but the point is I had to revamp my schedule to make time for what I wanted. I cut out things in my schedule that weren't productive or helpful.

One caveat, prioritize getting at least 7-8 hours of sleep, eating as healthy as possible, and family time. Some things are just too important to be cut out.

Have a Support System

There's no way I would have been able to go full time freelance without my wife - plain and simple. She has been my support system through all of this transition. I know it's been difficult for her as well but by being open and hones with each other we've made this a much smoother transition.

She was able to carry health insurance for our family during the first part of this transition.

If you live in the US, you know that everything related to finding fairly priced, reliable, and sufficient coverage without an employer subsidizing a portion of the cost is nigh impossible.

Without my wife bearing this burden, I would have no choice but to stay at my 9 to 5.

Freelancing income can be "peaks and valleys". One month you finish a project, get paid, and you're riding high. The next month you could have no work and you're in conserve mode again.

My wife helped stabilize our monthly income so that it's more predictable while I make this transition.

So what's the point of all this? Am I telling you to go out and get married so that person can help you move into full time freelancing? No, of course not. But having someone you can rely on while making this transition will make the process infinitely less stressful.

That person can be your friends, relatives, or even a mentor.

Save Money Relentlessly

This heading speaks for itself. No matter how you get paid at your current position, save whatever you can for as long as you can before making the transition. The more you save now, the better off you'll be when you decide to make the leap.

Everything you put back now will help you down the road during those "peaks and valleys" I mentioned earlier. This nest egg you create will offset costs you run into once you've quit your full time job.

One way my wife and I save money is to make meal plans (my wife does all the planning, I chip in with ideas) before we go grocery shopping for the week. Doing this allows us to see the ingredients we need for a week's worth of meals and keeps us focused while shopping.

If you're like me and have trouble making and sticking to a budget, these apps can help:

PocketGuard (free)
Mint Budget Tracker (free)
Honeydue (free)
You Need a Budget (YNAB) (paid after a 34 day trial)

Have at Least One Long Term Client

This is the 2nd most important aspect, behind relying on my wife, that allowed me to transition to freelance full time. Having at least one long term client/project is game changing. This stream of predictable income has helped alleviate an untold amount of stress.

How do you find a client like this? The major job boards are a great way to start. There is no shortage of clients and companies looking for a reliable, albeit temporary, extra set of hands so to speak.

Typically, these companies aren't looking for full time employees - they just need help on a contractual basis. This is the perfect arrangement!

I've also had this type of relationship turn into plenty more work from the same client. I already had a contract with the company for one project, they approached me and asked if I'd be interested in working on a second project as well. I now have two, long term (more than 6 months) projects that provide predictable income.

A word of caution though, don't let this be your only source of income. Always be looking for more work/clients/opportunities.

Only you can determine what the right choices are for your particular situation. I hope this guide helps with your move into freelancing. If you have any questions, I'm always willing to help. Leave a comment or shoot me a DM on social media.

When you've made the leap, I'd love if you'd share your store with me!

Since you've made it this far, why not sign up for my Newsletter? You can do that at the top right of my blog. I promise I’ll never spam your inbox and your information stays with me. I like to occasionally send out interesting resources I find, interesting tweets I see, articles about web development, a list of my newest posts, etc.

If you haven’t yet, you can also connect with me on social media! I love connecting with others and meeting new people so don’t afraid to say hi.

Lastly, I'm available for hire! You can contact me through social media or by using the form the form on my website to get in touch :)

Have an awesome day my friend and happy coding!

I Abandoned My Old Website Design After Going Full Time Freelance

Jonathan Sexton — Mon, 27 Sep 2021 12:43:06 +0000

Refreshes, redesigns, and rebuilds are always fun and exciting for me. I get the sense of giving new life to something that hasn't seen it for a while. However, it wasn't an easy task to re-imagine the purpose, layout, and design of something I love as much as my own website.

It holds a special place in my developer heart. I mean it was, quite literally, the very first website I put on the live web.

It was a fun, albeit long, process that really tested my ability to mesh colors, design, and purpose but I'm very happy with the finished design and build.

My Previous Website

My previous portfolio was built with the purpose of getting a developer job and was roughly 3 years old

The previous version of my website was built with the intention of landing my first developer job. As such, it had sections and content that's relevant to that purpose.

It reads like a resume which is exactly what I wanted at the time because when the site was built I was looking for my first developer job.

Now that my focus has changed (check my tweet about going full time freelance ) from getting a full time job to going freelance, it was time my website reflected that.

To prepare, I did quite a bit of research on accessibility, color theory, and layout design so I’d have a good foundation to start from on the visual aesthetic. I asked for some input from my daughter and that’s where the initial purple color came from.

I also shifted the layout to have multiple pages instead of the landing page style that my previous website implemented.

What Made This the Right Time

It’s been nearly 3 years since I changed industries by landing my first developer job. In that time I’ve learned a ton, grown as a person and as a developer, and met some amazing people.

My ultimate goal is (and was from the beginning) to move into freelancing full time. This redesign is just one of the many steps I’ve taken in that direction.

The freedom and flexibility that freelancing affords me and my family is what initially drew me to freelancing but the love for helping people/small businesses has truly become my calling.

Being in a place financially, emotionally, and mentally stable enough to make the transition into full time freelancing made this the most opportune time for this redesign.

The Results

The new landing page - complete with a color/style/layout refresh

This refresh took much longer than I anticipated or wanted (but isn't that always the case with our own projects?) but I'm very happy with the end result.

I wanted a new design that was bright and vibrant - I think I hit the mark on that one with the purple and orange/red combination.

I use a custom but simple form for the contact portion - after all I don't need much from a potential client at this stage.

Without going too much into the technical weeds, it's built on Gatsby which means I get greater control over what's being sent to the client and it's super fast:

I also took the time to make accessibility a focus from the ground up - focusing on color contrast, element flow, and semantic HTML. I want my website to be usable by anyone that visits it.

I'm extremely happy with the way this process turned out and I feel like the results speak for themselves :D

Planned Upgrades

Like any project, it's never finished so I do have some upgrades planned for the not-so-distant-future. Here are a few ideas:

I want to bring the blog posts into the Gatsby ecosystem via a headless CMS. I feel like this will have a much better user experience while bringing my website and blog design inline with one another.
I'm also eying a dedicated contact page. I haven't decided on the specifics of this implementation yet
Adding customizable banner/notification area at the top of pages for special events/promos/important messages
Easter eggs for developers/curious visitors

I'm sure this list will grow before everything above is complete, but it's good to have a starting point :D

This was originally posted on my blog.

Since you've made it this far, why not sign up for my Newsletter?

You can do that at the top right of the main blog page. I promise I’ll never spam your inbox and your information stays with me. I like to occasionally send out interesting resources I find, interesting tweets I see, articles about web development, a list of my newest posts, etc.

Lastly, I'm available for hire! You can use the form on my portfolio or send a message to hello at jonathan sexton dot me to get in touch :)

Have an awesome day my friend and happy coding!

Personal Updates

Jonathan Sexton — Fri, 21 May 2021 17:48:10 +0000

It's been quite some time since I did a less technical more personal post. This will be more of an informal post that mostly focuses on updates around me (kinda selfish huh?) and my personal life as opposed to tech.

I've tended to shy away from these types of posts because my negative self talk creeps in and tells me these aren't useful to anyone but me.

This time though, I've decided not to listen to those thoughts and publish this post anyway :) You'll have to let me know if I was right to do so haha

I've also sprinkled in some helpful tidbits here and there that have proven useful to me. Hopefully you'll get the same value out of them but as always I make no guarantees.

Alright, let's get started!

Life

Alright, let's start with a few life updates. If you follow me on social media (you can find all of my links on the home page of my blog) you've likely seen a few of these updates already.

My daughter was born - happy and healthy thankfully - thus making me the father of two wonderful children. My wife and I have slowly been learning how much we miss sleep.

We've started putting tile floors down in our home. If I can provide you with any advice on the home improvement front, it's to do it before or after you move - at least for larger projects like what we are currently doing.

The alternative is you end up living out of one bedroom for a few weeks and you learn just how much you can tolerate being in one room of your house for a while. Spoiler alert - it's likely not that long.

My wife and I were fortunate enough to get both rounds of the COVID 19 vaccine. We're hoping life can return to some sense of normalcy soon-ish. Stay safe and get the vaccine if you are eligible - that's my advice :)

Lastly, I'm going on almost 2 years at my first professional development job. It's hard to believe that nearly 730 days have passed since I was hired. If you haven't read about my journey, I invite you to read how How I Landed My First Development Job as it was a crazy ride.

Side note - Here's a sneak peak for you as well: I'm rebuilding my personal website (as well as this blog) in anticipation of eventually going full time freelance!

I'm hoping to have it ready for launch by the end of June 2021

If you have a project/idea you'd like to talk about or are searching for a developer, use the form below to get in touch with me. I'd love to talk about how I can bring your project to life :)

Random Advice

It should be noted that I learn as I go - I learn by doing. Some of the lessons I've learned along the way have come to me the hard way and some have been easier to handle

You get what you pay for - this isn't true in every situation (I've had many great wines that were under $10 for example) but in this situation I should have known better.

This pertains to the reference above where I said my wife and I are getting tile floors put in our house. We decided to go with a cheaper option for an installer. Long story short, we've spent many thousands of dollars, 5 weeks of our time, and our floors still aren't finished.

I can directly relate this lesson to learning to code or building a project. Don't take short cuts.

Spend extra time to do things right up front and you will be rewarded. Cut corners by not testing your code or by not adhering to best practices and I promise you will pay for it later down the road (see technical debt).

Sometimes the hard lessons are the most important ones because they give you the opportunity to learn and grow.

You can manage your time or it can manage you - there will only ever be 24 hours in a day for everyone.

I have a thriving freelance business, a wife, two children, bills, a busy schedule, etc but I also want time to work on side projects and write articles. So I maximize my free time as we only get so much. Here are some things that help me and might help you:

Batch similar tasks (this will not be the only article I write today)
If something can be done in less than 5 minutes, do it now, don't put it off because it could become a much larger issue in the future
Set your future self up for success - for example if you have a hard time getting up at a certain time, set your alarm and put your phone or alarm clock out of reach so you have to get up to turn it off
Meal prep on the weekends and freeze those meals so you can have lunches/dinners ready on the weekdays when you have less free time (make use of that batching I mentioned above)
Keep a time journal - write down everything you do, how long you spend on it, and in a week or a month look at where you can make changes in your schedule to cut out time wasting tasks
Make a daily priority list with no more than 5 tasks- rank these tasks from 1-5 and focus on them ruthlessly
Discipline will always beat out motivation - I am wholly unmotivated to write this post but I made a plan to increase my output of blog posts. Discipline > motivation
Schedule everything - even downtime. My calendar looks like a garbled mess of events but I schedule everything in my day right down to the minute. Thus far it has helped me tremendously.

These are just a few of the tips I have that have helped me be more productive. They may work for you or you may find little value in them. Find what works for you through trial and error.

Allow yourself to take breaks for as long as you want or need - Breaks are just as important, if not more important, than working. Enjoy all that your life has to offer. Spend time with your family, go outside and walk around, play video games, veg out on the couch all day and watch TV - do all the things you want to do for your mental/physical health.

And here is the most important part: don't feel bad or guilty for not working. As much as we try to squeeze every ounce of free time out of our schedules for working and focusing we also have to have down time. If for nothing else than to avoid burnout. So go ahead, enjoy time with friends and family (socially distanced or virtually), go for an extended walk, or just enjoy not working. We deserve it!

This is something I struggle with but I'm getting better at it one day at a time.

That's a Wrap

If you've made it this far - thank you. I appreciate you sticking around for the personal stuff. These types of posts are few and far between from me so if you're looking for technical content I have you covered there as well.

I have posts covering large ideas like software development life cycles, negotiating freelance rates, and (if you're interested) more technical based content like TypeScript.

If those don't satiate your technical article needs check out my freeCodeCamp articles which cover a wide range of topics like SQL queries and JavaScript.

While you’re here don’t forget to sign up for my Newsletter – you can do that at the top right of the main blog page. I promise I’ll never spam your inbox and your information will not be shared with anyone/site. I like to occasionally send out interesting resources I find, articles about web development, and a list of my newest posts.

If you haven’t yet, you can also connect with me on social media! All of my links are on my main website or found on my profile here. I love connecting with others and meeting new people so don’t afraid to say hi 🙂

Have an awesome day friend and happy coding!

Get a Basic Understanding of the Life Cycles of Software Development

Jonathan Sexton — Tue, 25 Feb 2020 02:43:09 +0000

When I decided to teach myself how to code almost four years ago I had never heard of, let alone thought about, the software development life cycle. As a brand new developer I was focused on learning the technologies that would help me land that coveted first developer job, not the nuances of how those teams operated.

When I did learn of them, I thought they would be useless to me because I considered myself a web developer not a software developer.

I've since learned that this couldn't be further from the truth and these principles/practices play a large role in my day-to-day activities (whether I realize it or not).

I'm fortunate enough to see how the code I write, the features I build, and the bugs I inadvertently introduce (more than I care to admit) affect the end user and their experience. That experience has helped shape how I think about the process of building products and solving problems for my users.

I've had some time to think about the differences (and similarities) each of these approaches offer. At their core, each is focused on delivering high quality software as efficiently and as cost effectively as possible.

Professionally, I've only used one or two of these methodologies (I don't believe I've been in the industry long enough to experience them all and I have yet to have someone explicitly tell me that the team adheres to a specific methodology) but I still find value in at least a basic understanding of all of them.

I hope to give you just that after you've finished this article. This is not an in-depth examination of each life cycle but more of a broad strokes type of approach.

So, here are the software development life cycles in no particular order:

Let's dig in to the differences and similarities of each method.

Lean

The Lean methodology relies heavily on and is comprised of seven principles. In no specific order they are:

Eliminate Waste
Amplify Learning
Decide As Late As Possible
Deliver As Fast As Possible
Empower The Team
Build Integrity
See/Optimize The Whole

Each principle has a specific purpose with benefits that compliment each other.

Eliminating waste (extra features, incomplete work, managerial engagements, etc) creates more value for the customer which, in turn, enhances satisfaction.

Amplifying learning allows teams to reinvest in their ability to deliver products to customers.

Deciding as late as possible refers to all major decisions, giving teams an option based or a set based approach. This allows teams to gather facts rather than opinions to help influence decisions when made.

Delivering as fast as possible is self explanatory - build the product as quickly as possible to deliver it to customers for evaluation/iteration.

In a typical scenario, the managers dole out assignments/work to the developers. In the Lean methodology developers "teach" managers how to listen to the "people in the trenches" thus influencing the decisions/choices of management.

This helps teams feel more empowered to speak up about ides and solutions.

Making integrity a rule instead of an exception means that the customer is confident in the system being built. The customer knows the system is being built to withstand the appropriate amount of growth and "stretching" if need be.

I like to think of the integrity part along the same lines as sitting in a chair. When you sit in the chair you believe it was constructed with the best material that will hold you up every time you sit in it for the life of the chair. The customer needs to that same confidence in the product being built.

Lastly, seeing and optimizing the whole refers to the entirety of the system being built. By optimizing for the whole we look at software not as a sum of many components, but as one large entity that is optimized for efficiency.

This means that during development, the product is broken into manageable pieces and that inadvertent bugs are not only discovered but resolved swiftly.

Agile

This is the "fail fast" approach to building software.

It places emphasis on small, incremental releases with on-going release cycles. With each iteration teams strive to identify and address small issues before they become big problems.

This also means that the teams must engage stakeholders (people/organizations that the code can ultimately affect such as managers, technical leads, CTOs, and customers) to get their feedback.

If you're a freelance, your stakeholder(s) would be your customers - ultimately you need to ensure their satisfaction with the work before moving on.

Agile is technically an offshoot of the Lean methodology with some notable differences - mainly it prioritizes customer satisfaction from the outset and allows teams to respond quickly to customer feedback.

Although it is beyond the purview of this article, there is another more complex framework within Agile that is called SCRUM. This methodology is used for large, extremely complex projects and has even been used outside of software development.

Waterfall

The waterfall methodology is, by most accounts, the oldest one in the list. It was never meant to be a model for software development and got its start in the construction and manufacturing worlds.

This approach is simple in its structure - finish all parts of a phase before moving on to the next phase with more momentum building towards the project finish as stages are completed. Each stage's beginning (except for the first) and completion is contingent on the previous stage's completion/transfer of information.

Under the waterfall approach each stage has its own rigid project plan that finishes off with testing for previously completed work. It should be noted that this approach is not recommended for larger/longer lasting projects because of the aforementioned rigidity.

Think about the genesis of this methodology and you'll understand it more. It came from the construction/manufacturing world where it is common to complete one phase at a time. During the building of a house you wouldn't start putting in the plumbing before the frame has been put up.

That's not the way software development works generally. As we all know it sometimes becomes necessary to revisit a phase that was previously thought to be finished.

Iterative

This is known as the "repetitive approach" or the "make it better the next go around" approach because of the different opportunities it provides to improve the product with each cycle iteration.

I'm biased (as we all are :D) but this happens to be my favorite life cycle for development. I believe it works best for my current situation both in my freelance and career path because it allows me to constantly "move forward while making things better"

With the iterative approach, teams implement a solution, test that solution, evaluate its effectiveness/throughput, and then pinpoint further areas for improvement. This happens for each cycle (iteration) of the development process.

With each version released comes another iteration until the final product is completed and ready for rollout to users.

One of the great features of the iterative approach is you and your team get a working version of software early on in the development process. This can be especially useful to show to stakeholders to gauge their response/feedback.

One of the big drawbacks to this approach is it can consume a large amount of resources very quickly. Imagine all of the people, hours, bug fixes and wages that go into each iteration of the development cycle and you'll get a good picture of the resource usage.

Within this approach is a subset of principles developed by Rational Software Corporation (bought by IBM) called the Rational Unified Process (R.U.P.) which consists of 4 phases:

Inception
Elaboration
Construction
Transition (product release)

This set of principles is meant to be flexible and tailored to the needs of each team using it.

Spiral

The spiral methodology is likely the most flexible out of the six. It's a methodology built on risks - identifying and negating them. Risk (identification & aversion) drives every decision in this model. It is broken into four sub-phases:

Planning (objectives)
Risk Analysis (identify possible roadblocks)
Develop & Test (current & next version)
Evaluation (review of current phase & plan for next phase)

Each iteration of each phase begins with planning for the next phase. This way potential risks are identified before they are encountered. This also allows for a plan of action when said risks arise.

During phases teams also work to mitigate these risks and their impact on future iterations of the spiral development.

As the development process continues, each of these four sub-phases is repeated in spiral fashion. This allows for multiple rounds of refinement for each sub-phase until completion.

Dev Ops

If you do a quick search, you will find no shortage of information on this development life cycle method. It is the new kid on the block that brings software development and information-technology operations teams into the same fold.

These teams work in conjunction to provide small, but impactful, updates to products that come at a frequent pace. In turn, this creates a continuous feedback and improvement loop that drives development.

This particular methodology is known for automating the manual parts of development as well (think deployment).

The overall goal of this methodology is, like most others, the shorten the development life cycle and provide quality products.

One of the drawbacks to this methodology is the significant mindset and culture changes within an organization. Teams that may have been accustomed to working on many things find their tasks narrowed to only one or two.

For example, a general purpose developer may find he or she is now being tasked with only the testing portion or the end-user experience portion.

Bringing It All Home

Photo by Clever Visuals on Unsplash

I hope you can now see the importance and the benefits of each of these methodologies. Each of these possess their own strengths and weaknesses.

They are, at their most basic level, a set of guidelines and principles that seek to deliver high quality, efficient work to stakeholders.

When I first started learning to code I didn't have a mentor. By sharing what I've learned I hope to those who are learning to code when/where they can.

I want to share as much information and experience as I possibly can with other developers. If you are teaching yourself to code or if you're a seasoned developer I hope this article helps, even if in a small way.

Check out my blog where I frequently post articles about web development.

While you're there why not sign up for my newsletter? You can do that at the top right of the main blog page. I like to send out interesting articles (mine and others), resources, and tools for developers every now and then.

If you have questions about this article or just in general my DMs are open -- come say hi on Twitter or any of my other social media accounts which you can find below the newsletter sign up on the main page or on my profile here :)

Have an awesome day and happy coding, friend!

How to Install and Begin Using TypeScript

Jonathan Sexton — Tue, 14 Jan 2020 01:50:48 +0000

TypeScript is one of the current hot topics in web development and for good reasons.

It allows us to type cast when declaring variables which means we explicitly set the type of data we expect back, throws errors if the returned data is not the type we expected to get back or if a function call has too few or too many arguments, and that's just a sampling of everything it offers.

If you'd like an overview of the data types you will find it helpful to read my previous article. Reading that article isn't required but it will give you a great understanding of the data types and syntax for TypeScript.

Before we start, it's important to note that TypeScript can be used in conjunction with a framework/library (TypeScript is the default in Angular projects and I have an article in the works about getting started with it) but it can also be used independent of a framework/library.

Also, this article assumes you have a basic understanding of JavaScript programming.

So, now we're ready to get started with TypeScript and start making use of it's awesome features.

Let's dig in!

Installing TypeScript

There are two main ways to install TypeScript. The first is through Visual Studio (not to be confused with Visual Studio Code) which is an IDE. The 2015, 2017, and I believe 2019 versions come with TypeScript installed already.

This is not the route I'll be covering today since I mainly use Visual Studio Code for all of my needs.

The second way, and the way we'll focus on, is through NPM (Node Package Manager).

If you don't already have NPM and/or Node installed (you get NPM when you install Node), now is a great time to do so as it's a requirement for the next steps and by association a requirement to use TypeScript.

The Node download page - it's a good idea to use the LTS version as it's the most stable

Once you have Node and NPM installed, open your terminal in VS Code and run the following command:

npm install -g typescript

Once it's finished installing, you'll see that 1 package has been added and you'll see a message stating the version of TypeScript that was installed.

This is everything you need to start compiling TypeScript to JavaScript.

Now you're ready to start writing TypeScript!

Starting A TypeScript Project

Let's create a TypeScript project so we can take advantage of all those great features that come along with using TypeScript.

In your editor of choice (I'm using VS Code) let's create an HTML file to be the visual side of our code. Here's what my basic HTML file looks like:

Basic HTML boilerplate with some placeholder text

Honestly, we're just using this HTML so we can have something to look at on the page. What we're really concerned with is using the console.

You'll notice I have app.js linked in the head of our index.html file.

You're probably saying to yourself I thought this was an article about TypeScript?

Well hold your horses, it is. I just want to highlight some of the differences between JavaScript and TypeScript (You'll learn where this file comes from down below).

Below you'll see a simple variable declaration and a console log statement:

A simple variable declaration and console log statement

As a side note, if you want to disable some ES-Lint rules you can place the rules at the top in comments like I've done above. Or if you want to completely disable ES-Lint for that file only you can place /* eslint-disable */ at the top of the file.

And here is the browser console:

Our userName variable inside FireFox

Let's pretend that I'm building an application and for the userName I expect to always get a string back. Along the way, I may make a mistake or my data may get mutated from another source.

Now, userName is a number :(

Now userName is a number!

And here is the browser console showing the changes to userName that we likely didn't want to happen if this were a production application:

The FireFox console showing the results of the variable mutation

What if the returned userName was then passed into another function or used as a piece of a larger data puzzle?

This would not only be a mess to figure out where the mutation occurred (especially if we had a larger application) , but also would create an untold amount of bugs in our code.

Now, let's try that same experiment in TypeScript. To do that, we'll need to create a new file with the .ts extension to denote a TypeScript file.

I'll name mine app.ts to stay consistent with naming conventions and put the same code from our JavaScript file into our new TypeScript file.

The same code from our JavaScript copied over into the TypeScript file

You'll notice that I'm using type casting when declaring my variable now and I'm explicitly telling TypeScript that this variable should point to a string value only.

You'll also notice that I have an error line under userName when I'm reassigning it's value.

Compiling TypeScript With the CLI

To see what this looks like in our console we have to compile it to JavaScript and we do that by running tsc app.ts in our VS Code console (you can also run the same command in any terminal as long as you're in the correct directory).

When we run this command it will compile our TypeScript into JavaScript and generate another file with the same name only with a .js extension.

This is where that app.js file came from that I mentioned earlier in the article.

To compile multiple files at once, just provide those names in your command, one after the other: tsc app.ts header.component.ts

It's possible to compile multiple TypeScript files into a single JavaScript file by adding the --out flag:

tsc *.ts --out index.js

There’s also a watch command which will recompile all of the TypeScript automatically anytime a change is detected, keeping you from having to manually run the compile command over and over:

tsc *.ts --out app.js --watch

Here's the output from that tsc app.ts command above:

The error in my console

This error tells us that there's a problem with the reassignment of userName. Because we explicitly set our variable to be a string (even if I hadn't set the variable to a string the error would still occur because TypeScript infers data types) we cannot reassign it to a number.

This is a great feature because it forces us to be explicit with our variable declarations and saves us from making mistakes that could prove annoying and time consuming. If you expect a particular type of data you should get that data, otherwise you should get an error.

Using Explicitly Declarative Arrays and Objects

Let's say I'm building a project and instead of manually setting the navigation links, I want to store that info in an array of objects.

I'll expect a specific format for the information that's stored so it's consistent across all of the links.

Here's how I can set a "complex" array in TypeScript:

An array with a specific format

On the left side we declare the name of the variable navLinks, followed by a colon. At the curly braces is where we start declaring the format of the information we expect in this array.

We're telling TypeScript that we expect this array to contain an object or objects with these property names and types. We expect a name which is a string, a link which is a string, and an alt which is also a string.

As with other data types if we deviate from the format we established for this variable, we run into errors.

Here we tried to add a new entry that was blank and we got the following error:

Type '{}' is missing the following properties from type '{ name: string; link: string; alt: string; }' : name, link, alt ts(2739)

We get similar errors if we try to add another entry with the wrong type of information:

{ name: 'Jonathan', link: 15, alt: false } ❌

{ name: ['Jon','Marley'], link: `https://link123.net`, alt: null } ❌

this.navLinks[0].img = '../../assets/img' ❌

this.navLinks[0].name = 'Barnaby'✔️

You get the idea though. Once we establish the format, TypeScript will hold us to that format and inform us if/when we deviate from it with an error.

Also, here's a few ways to define an array:

const arr1: Array<any> = ['Dave', 35, true]; // will allow us to have any number of elements with any type

const people: [string,string,string] = ['John', 'Sammy', 'Stephanie']; // will throw an error if more than 3 string or any non string elements appear in the array

const people: Array<string> = ['Jimmy', 'Theresa', 'Stanley']; //will allow us to have any number of only string elements in our array

Objects work much the same way as arrays do in TypeScript. They can be explicitly defined with set types or you can let TypeScript do all the inferring. Here's a basic example of an object:

const person: {name:string, address: string, age: number} = {name: 'Willy', address: '123 Sunshine Ln', age: 35}

Again, on the left side we're declaring person as the variable name with the first set of curly braces defining the format we want our data to be in.

It is important to note that in objects, the order we define our properties in does not have to match the order of the format:

The properties do not have to match the order in which they were defined

Functions, Parameters & Arguments

Some of the greatest benefits you'll see in TypeScript come when using functions.

Have you ever built a function to do a specific task only to find out it's not working as you intended?

While using TypeScript it won't be because you didn't get/send the correct type of data or use the correct number of parameters/arguments.

Here's a great example:

A TypeScript function that should return a number

In our function we expect to receive 3 arguments when calculator executes. However, if we receive the wrong number of arguments (too few or too many) TypeScript will give us a nice error:

The error we get when calling a function with the incorrect amount/type of arguments

Likewise, if we receive the wrong type of data when executing this function TypeScript will generate an error and the function will not run.

calculator('12', '11', 'add) ; ❌

Now you may be saying to yourself 'So what? That's all well and good but it doesn't seem like that's a huge deal but imagine you're application is dozens and dozens of files with many layers of abstractions.

A great example of this would be an Angular application with services, data models, multilevel components, and all the dependencies that go along with that. It becomes increasingly difficult to pinpoint where an error is coming from when your application gets to be large.

That's All

Hopefully you can see the benefits of TypeScript now. There are plenty more than I have outlined here and I encourage you to read the documentation if you want to find more.

This article was originally posted on my blog. Swing by and check it out :)

While you’re there don’t forget to sign up for my Newsletter – you can do that at the top right of the main blog page. I promise I’ll never spam your inbox and your information will not be shared with anyone/site. I like to occasionally send out interesting resources I find, articles about web development, and a list of my newest posts.

If you haven’t yet, you can also connect with me on social media! All of my links are also at the top of that page or in in my profile here on DEV. I love connecting with others and meeting new people so don’t afraid to say hi 🙂

Have an awesome day friend and happy coding!

Learning TypeScript Data Types - From Zero to Hero

Jonathan Sexton — Mon, 28 Oct 2019 09:47:47 +0000

It's all the rage these days in the world of web development - TypeScript. I'd wager by now you have heard about it, even in passing. But, if you haven't or if you're just curious then you've come to the right place my friend!

I'm currently learning TypeScript in conjunction with Angular (an article on this is in the works, so stay tuned!) because it's what our web application is built in at work. I decided to write up something easy and simple to follow so you can get up and running with TypeScript data types.

I'll break this article up into two posts for simplicity - the first will be a brief overview of what TypeScript is, the data types, and some supporting examples. The second article will be focused on getting TypeScript installed and running locally on your machine.

What Is It?

Before we start, here's a super condensed description of TypeScript in my own words. It's a superset of JavaScript - which essentially means it's a form of JavaScript that gives you certain benefits along with all of the greatness included in 'vanilla' JavaScript. It's an open source language written and maintained by Microsoft.

TypeScript transpiles to JavaScript and will run in any environment that native JavaScript runs. You may use TypeScript for both front end and back end applications.

It's written just like JavaScript, with a few exceptions that we'll go over soon. Here's an example of some TypeScript:

TypeScript in all it's glory

Try not to focus on all of the colons and extra stuff you see above, we'll dig into that below. Instead, focus on the things that stand out - we're just declaring variables with values, these are strings, arrays, and objects just like in JavaScript.

Another great thing that I've learned about TypeScript is you can mix JavaScript in with the code and have no issues doing so. Check the screenshot below (this is inside an Angular app):

TypeScript and JavaScript used together in the same file

Data Types

Let's get started with the fun stuff - data types! (There are a few data types we won't cover - never, null, undefined. This is simply because there isn't much to them. I want you to know they exist and if you'd like to dig in more on those types, here is a link to the official TypeScript documentation for your reference.)

TypeScript will infer the type of data assigned to a variable without you explicitly setting the type but for simplicity and good measure I like to declare the data type when declaring my variables.

We assign data types by simply placing a colon after the variable name but before the equal sign:

const {variable name}: {variable type} = {variable value}

This is the convention that the majority of TypeScript data types are declared with the exception of functions and objects.

Some data types come with a bit more complexity than that, but you get the general idea. Below are some brief explanations of data types and examples of how to declare them.

Boolean

Booleans in TypeScript work the same way as they do in JavaScript. Variables of data type boolean are declared like so:

const myBool: boolean = false;

String

Strings in TypeScript work the same way as they do in JavaScript. Variables of data type string are declared like so:

let myString: string = 'bacon'

Number

Numbers in TypeScript work the same way as they do in JavaScript. Variables of data type number are declared like so:

const myNum: number = 1207;

Array

Arrays in TypeScript are, like other data types, just like arrays in JavaScript. Variables of data type array are declared two separate ways :

const myArr: number[] = [12, 90, 71];

The above way is how you'd declare an array if all of the elements inside that array are numbers.

const myArr: Array<number> = [12, 90, 71];

This way of declaring an array uses the generic array type set to number. Functionally, there is no difference in how these ways produce the end result of declaring a variable with array type.

If the data types inside the array are unknown or a mixture of data types, the array can be declared using the <any> type (this is a type all on it's own that is discussed below):

const myArr: Array<any> = [12, 'thirteen', false];

This way will allow you to mix data types in the array.

Tuples

Tuples are a data type unique to TypeScript. Think of them as arrays with a fixed number of elements. This data type is best used when you know exactly how many variables you should have. It is possible to reassign the value of the indices but not the amount of elements in the tuple.

Variables of data type tuple are declared just like an array:

let mine: [number, string];

If we'd like to change the values of elements, we can do that as long as they match the types we provided when declaring our variable:

mine[0] = 14 ✔️

mine[0] = 'Steve' ❌

Since we defined mine as a tuple, the order of the values matter as well and cannot be changed Also, assigning an index outside of the original defined number will produce an error:

mine[0] = ['Dave', 71] ❌

mine = [121, 'Dave', 'Steve']; ❌

mine = [121, 'bacon']; ✔️

Function

Functions can be as explicit as you want them to be. What I mean by that is we can apply types to the parameters and returned values. Below are two examples:

We explicitly define the type of value we expect this function to return

This function will throw an error if any value is returned that is not a number or points to a number. It may return a variable only if that variable points to a number.

We can define the types of parameters we expect as well

Above, we're type checking on the parameters being passed into our function. This is a great way to avoid mistakes because if the number of parameters is off or if their data type doesn't match what we're expecting TypeScript will let us know with an error.

If I want a function that should not return a value, I can set the type as void (a data type that means the absence of any data. While it can be used when declaring variables it typically isn't because then we'd have to set the variable to null or undefined, I've only used when functions should have no return value) and if the function returns anything TypeScript will throw an error:

A function with the type set to void

By setting the type to void I'm being explicit about my returns and establishing that while this function may still run, it should not return a value. If it does return a value, I'll get an error.

Enum

Enums are a welcomed (in my humble opinion) addition to the data types. Think of them as a more user friendly approach to giving names to numeric values. Here is an example of an enum:

enum Foods {'bacon', 'tomato', 'lettuce'};

console.log(Foods[0]) // yields 'bacon'
console.log(Foods.bacon) // yields 0 
console.log(Foods['lettuce']) // yields 2

It's also possible to assign the numbering index format with enums as well. Many languages including C# have enums and I'm happy to see them come to JavaScript.

You can be as creative as you want with the names. You can even change the numeric representation of the indices. If you want your first index to start at 18 instead of 0, it's as simple as:

enum Foods {'bacon'= 18, 'tomato', 'lettuce'};

console.log(Foods['bacon']); // 18

Let's say we had the value 18 but were unsure of what it mapped to in our Foods enum, we can check that as well:

console.log(Foods[18]); // 'bacon'

One piece of noteworthy information is now that we've set the first index to start at 18, the next index will be 19, and so on following the numbering convention you establish.

Object

Objects in TypeScript are defined in similar ways as objects in JavaScript are defined. We can be as implicit or explicit with our definition as we like or as the situation dictates:

let data: = {name: 'Jonathan', age: 30, hobbies: ['running','swimming','coding']}; ✔️

let data: {name: string, age: number, hobbies: string[]} = {name: 'Jonathan', age: 30, hobbies: ['running','swimming','coding']}; ✔️

When creating objects, the property names are immutable, but the order in which they appear does not matter, even if we define them in a specific order.

Also, we can have simple objects like those above, or we can define complex objects that take advantage of multiple data types like the one below (this object is for demonstration purposes only):

Here we explicitly set data types where possible in this complex object

Type Alias/Interface

With the example of a complex object above, you might be thinking this is awesome but what happens the next time I need to create a complex object? I need to type all of this out manually again?

Fear not, the type alias and interface types are here to help! A type alias is a data type that allows us to save other data types inside of it and then reference a variable instead of rewriting code over and over.

As a side note, type aliases and interfaces work in very similar ways. Both allow us to scaffold an object/blueprint for how our data should be structured. However, there are subtle differences that we won't cover here. Instead, here is a post that explains those differences in an extremely efficient fashion if you'd like to dig deeper.

There are details between the two that we should be aware of - when using the type alias, we use an equals sign (=) to declare values, the interface does not require an equal sign.

The interface type works very similarly to the type alias but requires no equals sign (=).

Alias data types do require an equals sign (=).

Now that we have our alias declared, it's time to make use of that alias. When we want to "build" our new variable from this alias, we simply set it as the data type:

Scaffolding objects using the interface / type data types is extremely useful :)

It's important to note that the interface is specific to TypeScript. It is used only at compile time to do type checking and to catch any errors that may have slipped past our watchful eye. The data from our interface will end up in our final code, but the interface itself is compiled out.

Classes

Classes are, in part, the veritable "bread and butter" of TypeScript (at least in my humble opinion). Staying with this idea of scaffolding new objects, classes allow us to build data in a much easier way than just manually typing them out each time the need arises.

Classes can be thought of as blueprints for how our data should be defined and what actions, if any, it should be capable of through methods.

Below is an example of a class in TypeScript (which is made possible by the introduction of classes in ES6):

A TypeScript class, ready for instantiation :)

Now, you might be asking yourself what are the differences between a class, a type alias, and an interface? Great question! The main difference between is that classes can be instantiated (we can create new instances of them) but an interface cannot.

There are, of course, other differences but that's not contained in the scope of this article. If you'd like to dig deeper, here is a great article I read to help me understand those differences. You'll find use cases for all of them, as I have, when using TypeScript.

Union

This is, far and away, my favorite data type of TypeScript! The union type allows us declare a variable and then set it to an "either or" value. What I mean by that is let's say we're expecting data to be passed into a function but we aren't sure if it's a string or a number - this is the perfect (and intended) purpose of the union type.

We use the single pipe character (on Windows it's Shift + the key right above Enter) when defining the type. Here's what it would look like when defining a variable with union data type:

const numOfDoors: string | string[ ];

This tells TypeScript that numOfDoors is a variable that can hold either a string or an array of strings.

Here is an example of that function I mentioned earlier using union type:

Any

Any is the type we set whenever we're unsure of the types of data we'll be getting. Maybe we're getting something from a third party or some dynamic data and we aren't 100% sure if we're getting a string, a number, or maybe an array of information. This is the perfect use case for type any.

Data type any is a way to opt out of type checking

I will caution against using type any unless you absolutely must because when used we're opting out of one of the core features of TypeScript - type checking.

However, this data type has it's use cases just like all of the data types mentioned.

That's A Wrap!

I told you this wouldn't take too long :D

I hope you enjoyed this article about TypeScript and are exited about the how it can prove useful to your code base. In the next article, we'll dig into the practical side of TypeScript. We'll go over installing it, compiling, and using it in your project (not just Angular projects either)!

This was originally posted to my blog :)

While you’re here don't forget to sign up for my Newsletter – you can do that at the top right of the page when clicking the link above. I promise I’ll never spam your inbox and your information will not be shared with anyone/site. I like to occasionally send out interesting resources I find, articles about web development, and a list of my newest posts.

If you haven't yet, you can also connect with me on social media! All of my links are also at the top right of the aforementioned page. I love connecting with others and meeting new people so don't afraid to say hi :)

Have an awesome day friend and happy coding!

Conquering Job Interview Code Challenges v2.0

Jonathan Sexton — Sat, 17 Aug 2019 04:17:30 +0000

As many of you know, I landed my first developer job at the end of June and I thought it would be great to use the challenge I was given as the subject of today's article.

It is important to note that I used React to build my project, but this could have been completed with any front end framework or 'vanilla JavaScript'.

Below is a list of topics we'll go over:

Accessing the Quip Automation API
Creating spreadsheets/documents with the Quip API
Installing and using the Axios library (this is optional and you can make API requests without it but I like the syntax)
Using qs package to stringify requests (this is not a requirement but I wanted to try something new and if it didn't work I always had the fallback of knowing Axios will stringify my requests by default)
Making POST and GET requests

For context, here is a snippet of the requirements as I received them:

"Create a front-end web app that interacts with the Quip API in the following ways:

Create a spreadsheet (bonus points to import data into the newly created spreadsheet).
- By import data, I mean upload an Excel spreadsheet, or copy and paste data into Quip spreadsheet.
Export a Quip spreadsheet to .xlsx
Download (backup) a folder/multiple documents.

Create the UI for the page in whatever way you see fit (buttons, dialog boxes, etc)."

I was a little worried when I read the requirements as I wasn't exactly sure where to begin. So, I dug into the API docs and started soaking up information. Thankfully, no time limit was given to me but I wanted to be done with this as soon as possible to see where I stood in the interview process.

To start, I designed a prototype of the finished product in Figma so I'd have a road map to go off of. This is not a required step, but it does make your project building experience run much smoother.

Alright, let's dig in!

Getting Started

I built my Nav, Footer, and Content components so I'd have a solid foundation for my app.

Each of these components return some basic JSX and there isn't much to them (If you'd like to see the code for each you can check out the project's GitHub repo).

I decided the majority of the requests would be split between the App.js and CenterContent.js files.

For reference, here is my project structure:

My project structure

You'll see me reference POST and GET requests throughout this post. If you aren't familiar with those now is a good time to do some research on those. I'll be honest in that I wasn't 100% on them when starting this project and had to go through some resources myself.

In a nutshell, a POST request is when we ask the server to accept some incoming data (that we are sending) - in our case that data comes in the form of creating a new spreadsheet file.

A GET request is when we ask the server to send us data from a specified resource on the server.

I used the Insomnia REST Client to help debug issues with my requests. I'm working on a beginner's guide for it so stay tuned for that!

Using the Quip API

If you're like me, you've never heard of the Quip API and had no idea what it does. At it's core, Quip is an automation tool that allows you to integrate with tools like SalesForce to make your sales team more collaborative.

For our purposes, we will be using it to create Excel spreadsheets on my Quip account (if you want to replicate this project you'll need to create a Quip account - it is free to do so).

You'll also need to create a personal developer token in order to make requests. You can do that here (requires an account). Once you have your token, keep it in a safe spot because we'll be making use of it soon.

To start, I installed Axios into my project by running npm install axios and then I import it into the files where I need to make my requests with import axios from "axios";

My import statements for required packages

Authentication

Before making any kind of requests to the server, I needed to authenticate with my credentials. I decided to put this in the App.js file inside a componentDidMount lifecycle method so it would load every time the page loads:

My authentication function

So I built my function, I called my function and for a moment thought all is well, until I ran into this dreaded error:

"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $websiteName"

Noooooooo!!! The dreaded CORS monster rears it's mighty head! (CORS is actually a useful intermediary between me and the server but can be annoying to deal with if you've never seen this error before). *Side note - if you've never seen this error before don't worry! I still don't fully understand it but I know enough to debug it. If you get stuck, check out the link above for some helpful info or look below for a quick work around.*

An easy way to get around this is to use a proxy like the CORS Anywhere free resource. Essentially, place this link https://cors-anywhere.herokuapp.com/ in front of your end point URL and it'll resolve the problem, for now.

This handy tool will allow you to make your requests while developing on localhost. If I were you, I would do some research before using this approach in production. Full disclaimer, I don't know enough about this little trick to tell you if it's safe to use in production or not.

So, after some tweaking of the authentication function I got the desired result to log to the console. Time to move on to making requests!

Making Requests

Now that my authentication is working, we're ready to make some requests. I knew I was going to make a POST request whenever I wanted to create a new document and that I also wanted to tie that action to the click of a button. So, below is my POST function:

My POST function

You'll notice this is where our qs package I mentioned at the beginning of this article comes into play. I'm not an expert but from what I gleaned after reading the docs on it, this package turns my request into a string to be sent to the server. If you prefer not to use this package that's no problem as Axios will do this by default. I know that qs offers more than just stringifying data but I'm unfamiliar with the full range of its capabilities.

Now, I want this function to fire when clicking a button. Thus, a basic button came to life!

A simple React button with an on click method

My POST function has been built, my button has been built, and the method tied to it. It's time to cross my fingers and see what my function spat out into the console:

The result of my server request - it works!

At this point I'm over the moon! I'm beyond excited that I've gotten this API call to not only work but to return something as well. Now the real test...does this show up as a new spreadsheet on my Quip account?

I have the console statement and the confirmation from my Quip account showing that I have successfully created a new spreadsheet - this is awesome! I'm ecstatic and I literally jumped out of my chair and yelled "YEEEEEEESSSSSS!!!" once I got both of these.

That feeling of getting something to work after struggling with it is like nothing else I've experienced in my professional life. I tell myself that I have to keep riding this wave of enthusiasm and elation so I push on to the next item on the list.

Import Data Into the Newly Created Spreadsheet

I had some great ideas for this section of the "assignment" but at this point it has been almost two weeks since I started this project and I'm anxious that the interviewer will have forgotten about it (i.e. me) or is getting impatient with me.

So, I scrap those grand plans and opt for something of a more simple nature so I can get this project turned in ASAP.

I built a small function to at least attach to the upload button so that I would have some type of functionality for it. At it's core, this function waits until a file has been uploaded, sets the state to the first element in the event target array, then creates headers based off of that information, with the eventual goal being it posts to my Quip account with that information.

However, you can tell by the comment at the top of this function block that I was unable to get it to work properly. However, I did not have time (at least I thought I didn't) to dig deep into this problem and get it fixed.

My import function that never quite worked properly :)

At this point, I've been working on this project after work and at night for over two weeks. I decide that it's time to turn it in without the other parts working (import, export, and downloading data).

The Final Touches

I know my project is unfinished and I'm beating myself up pretty hard about it. But, as an added bonus I decide that I'm going to design something in Figma as an added touch to help my chances of getting a call back.

Here is the finished product modeled off of their current colors/font/theme:

And That's A Wrap

With my project not finished but at a stopping point, I'm feeling not so good about my progress and my timing but I package everything up and throw it on GitHub. I throw in the above image and schedule an e-mail to go out the next morning at 9AM to the interviewer.

I waited nearly 2 days with baited breath hoping to get some type of call back - something. It finally came as I was driving into work. The interviewer had gotten my project and wanted me to come in for another meeting with his lead developer.

I was terrified and excited all at the same time because I was thinking they wanted to bring me in to make fun of my code or to ask me what the hell I was thinking when I built this monstrosity. But that wasn't the case at all. I ended up getting a job offer from this project!

If you'd like the whole story about that, it can be found in my previous blog post about landing my first developer job.

I hope you've found some value out of this post. If you have let me know on Twitter or any of the other platforms I post on :D

Also, I cross post most of my articles on great platforms like freeCodeCamp and Medium so you can find my work there as well!

While you’re here why not sign up for my Newsletter – you can do that at the top right of the page on my blog. I promise I’ll never spam your inbox and your information will not be shared with anyone/site. I like to occasionally send out interesting resources I find, articles about web development, and a list of my newest posts.

Have an awesome day filled with love, joy, and coding!

Landing My First Development Job – What a Crazy Journey!

Jonathan Sexton — Mon, 08 Jul 2019 09:24:52 +0000

You read the title right! I was offered a development position with a company and after some negotiating I accepted their very generous offer!

I am beyond blown away, excited, happy, and (if I'm being 100% honest) terrified - in a good way though! I'm still in disbelief that this is really happening but ecstatic to start working on production code!

I've had a lot of people ask me to distill my journey into an article to share and help others. So, buckle in because here we go!

Getting Started

I've always been interested in computers, tech, etc. Like many people my age, I got to 'cut my teeth' with development by creating a GeoCities site and later by personalizing my MySpace page with some basic CSS.

I didn't know it at the time but this was development, a crude version of it but still development nonetheless. At that time, I didn't know that people would pay for this kind of work or I might have stuck with it. So, I went to college and got a degree in nothing tech related - psychology. Not a useless degree, but one I ultimately never put into professional use.

Finding My Calling

Fast forward to the summer time in 2016 where I found myself with an abundance of free time on my hands outside of work. I had always wanted to teach myself to code/program and decided now was the time - no more delay. With the amount of free and accessible resources online to teach myself how to code it was the perfect time to jump in.

I started by searching for resources and came across CodeCademy where I took handwritten notes by copying the entire question, answer, and result into a notebook. I literally wrote down everything thinking that I would need it. I came back to these notes from time to time to review them. It's also interesting to look back on them and compare what I considered difficult then to what I consider difficult now :)

A friend introduced me to freeCodeCamp because he knew I was self teaching and told me this platform was built for people like me. I had planned to check it out, maybe do one or two lessons and then go to bed. I finished the entire section on HTML that night! I was hooked.

The more I learned the more questions I had. I felt this urge, this pull to find answers to those questions. So I continued on working through the lessons and projects. I finished 2 projects before the curriculum was overhauled and revamped on freeCodeCamp.

I was finding any excuse to learn and work on projects. While I was standing in any line waiting for something I would pull out my phone and instead of looking at social media, I began to read web development articles or watch a development related video.

I feel like this was a major shift in the way I viewed downtime as compared to previously where 'mindless consumption' (If you enjoy social media or funny animal videos I'm not calling you mindless, I'm simply saying that type of consumption typically doesn't require you to be engaged. It's the type of consumption that you can do on auto pilot and frankly I still do it from time to time) ruled my time.

During that time I had bounced around the various different sources and was like a kid in a candy store. At one point I had a folder that had roughly 300 links to material I had planned to work through. I now know that finding a resource and sticking with it is far better than hoping from one resource to another.

I was doing all of this at night when my wife and daughter were asleep. I was staying up until 12:30 AM sometimes as late as 2:00 AM and then having to get up at 6:00AM to do my normal day job. At first, when the topics weren't as mentally taxing this was not an issue. But as I started moving into JavaScript, learning the basics of networking, servers, accessibility, etc I noticed that the later it got, the more difficult it became to keep my brain engaged.

Needless to say, this routine only lasted a few months before having to change it.

I didn't want to stop working on projects/learning but I needed to alter my schedule in order to benefit my well being. That's when I decided to go to the other end of the work day spectrum.

I started getting up at 4:00 AM, instead of staying up late, to learn and work on projects before going to the gym then starting my day. I must say, this was a pivotal moment in my journey because I started to retain more of the information I was learning and that ultimately helped me move forward with more projects/material.

Also, this is the time when I started to buy up every resource I could find (Udemy courses and books mostly) dealing with any aspect of web development. I can tell you that this isn't a wise (or financially sound) choice to make. If you find a resource you like and that you're learning from then stick with that resource until it's exhausted. The last thing you want to be doing is jumping to the new resource each time you find one like I did.

Grow With Google & Udacity Scholarship

In January 2018 I applied for and was awarded a scholarship to Udacity's Front-End Nanodegree program. This was not only an awesome opportunity to help propel me towards my goal but a humbling experience as well.

I came into this program with a basic knowledge of HTML, CSS, and a small portion of JavaScript in the vanilla flavor. In this course I was introduced to jQuery, functional programming, object-oriented programming (OOP), test driven development (TDD), accessibility, servers, API's, basic networking, React, AJAX, and so many more facets of web development that I hadn't previously been exposed to.

I'll be honest, it wasn't always easy or fun and there were times I seriously considered dropping out. I felt like I would never learn these concepts and that I was in over my head.

I'm happy that I didn't quit because no one ever accomplished their goals by quitting - first and only cliche statement I promise :D

I had the chance to build many awesome projects like the Card Matching Game, Arcade Game Replica, Restaurant Review App, and the Neighborhood Map App. More than the projects though, I got to meet many great people and valuable experience collaborating with other developers in the course.

Without this course, I can truly and honestly say that I would not be where I am today. I gained many valuable experiences and lessons in this 9 month course.

Job Hunting...dun dun duuuuunnn!

Photo by Sven Mieke on Unsplash

At this point I had been working diligently (sometimes slacking off as well) for about two years. I did not feel as though I was job ready but a friend who became my mentor told me that I'll never feel ready. He said that I should apply and if I get interviews then let them tell me I'm not ready if that's the case but to not exclude myself from an opportunity.

So, with a metric ton of fear, anxiety, and doubt I decided to start applying for jobs.

At first, I was only applying for jobs where I met the majority of the qualifications. I can tell you now that this is not the way to do it, however, at the time I was terrified that someone would actually call me about an interview. (Later down the road I was applying for anything that interested me. Senior developer - sure, I applied for that. Front-end ninja with React skills - yep, threw in an application for that as well. API developer with SQL experience - oh yeah! I applied for that one as well. I did this because you never know what will come of your application. Maybe you don't get hired for that senior role but maybe they like you and your personality so much that they ask you to interview for their junior role.)

That's exactly what happened after I'd been applying for about 3 months. I got a call for my first interview! I was so happy and scared at the same time. Now the pressure was really on.

I read articles, brushed up on my interviewing skills, read books, asked my wife to quiz me on topics, and tried to run through different scenarios that I thought would come up in the interview. I also prepared questions for interviewer because I wanted to know what it was like to work at this company.

Ultimately, I did what I wasn't supposed to do; I convinced myself that this was the perfect job and I wanted it. I wanted it more than anything I could ever remember wanting. I built it up as something that I had to have.

The day of the interview came and to say I was nervous is an understatement. I was sweating bullets. I answered all of the questions and when it was my turn I asked the questions I had prepared. After it was over I left feeling like the interview went well.

Ultimately, I didn't get the position and I was crushed. I felt like everything went like it should have but for some reason the stars just didn't align. Little did I know that this would be a common pattern among my interviews.

I decided not to let these disappointments define or destroy my confidence. I started working harder, learning more, using that disappointment I felt to fuel my passion. I would do whatever it took to ensure that one of these interviews would end with a full time offer.

Here are some metrics about my job search:

Applications submitted across all platforms: 271
Any form of contact from company after application: 28
Phone Interviews: 7
In person interviews: 8
Job offers: 3 (one was contract with the (small) possibility for full time, one a part time freelance gig, and the eventual offer that I took for a full time position
Companies that ignored me after expressing interest: Too many to count

If you are applying for jobs, in any field, don't let the numbers discourage you! Yes it is disheartening, yes it can be daunting, yes it stinks to fill out an application and never hear anything back, but don't quit! You can do this! I'm proof!

My Advice on Your Job Search

This is by no means an exhaustive list of tips/tricks but below are some pieces of advice I've picked up along my journey to getting a job in development:

Develop thick skin - it's a must! Companies will disappoint you
Apply for anything you're interested in
Apply even if you don't meet all of the requirements (this is what I did and also how I landed my first developer job)
Spend time perfecting your resume
Just because one companies turn you down doesn't mean you're a failure
Show companies you can do the work by building projects outside of tutorials
Ask for help if you need it (this was a hard one for me to learn)
Apply for jobs on all of the major platforms but don't forget that platforms like GitHub jobs also exist
Ensure you take care of yourself - get enough sleep, exercise, eat healthy (it's important for overall health!)
Don't be afraid to take breaks
Don't compare yourself, your job search, your situation, or your skills to others
If it takes you 3 months or 3 years (like me) remember, this is not a race
Work hard, learn well, and never give up!

As always, I wish you nothing but the best in all you do. If you need advice or help I'd be glad to do what I can. Connect with me on Twitter or LinkedIn.

You can also see more of my writing on my blog where I post frequent articles related to web development. I also cross post the majority of my work on Medium if you'd like to give me a follow!

I'm always willing to help and I love meeting new people so don't be afraid to say hello!

Have an amazing day and happy coding!

Conquering Job Interview Code Challenges v1.0

Jonathan Sexton — Mon, 27 May 2019 17:22:42 +0000

Photo by Lê Tân on Unsplash

As many of you know, I have been applying for a job in web development for a few weeks and I thought it would be a good idea to share some of the coding challenges I've encountered. (Side note, if you know of or have any available web developer positions I would greatly appreciate if you'd share them with me either here in the comments or on Twitter :D )

Not only that but I'll share the ways I went about solving these challenges. Granted, there are many ways to solve these challenges but these are the ways I went about it. If you have different ways that's awesome and I'd love for you to share them with me!

I will not share any identifiable information about the companies or specifics on the interview process of said company to preserve process integrity.

Alright, let's get to it then.

The Challenge

This is a challenge I was given recently that I felt good about solving:

Task: Return a basic styled list of posts from an endpoint in reverse chronological order

To protect the company and their information, I will not share the URL from which I returned the information but instead will have a generic link from JSONPlaceholder (a great, free, open source API for developers when you need to get some generic outside data) in the code below.

Here's the HTML I started with so we have something to display our results in:

Basic HTML boilerplate

The <ul> tag has an id so we can style it later in the process.

Fetching Data From the Endpoint

Alright, let's dig into the JavaScript portion of this challenge. First, I like to set my output and display variables:

Our variables used when displaying the returned code

I use let for the output variable and set it to null because we will change it's value later in the code. The list variable is declared with const because it's value will not be changing.

Fetching data from the endpoint

In the above example, we're declaring an arrow function named getData wrapped in a try...catch block (This is a cleaner/easier to use/read syntax that uses Promises under the hood - you'll also see the catch portion below). Because we're getting data asynchronously we also need to make use of async/await to fetch data. This is the method I'm most comfortable with but I know there are many other ways to get data from an endpoint so feel free to share yours :D

Once we've declared our data variable, the next thing is to set a variable to turn the returned data to a JSON object so we can get it in a usable form. We do that with the .json() method. We're awaiting the data as well because if we were to omit the await keyword, JavaScript would try to turn the data variable into JSON but the data would not be there yet because it's coming from an asynchronous API.

Our glorious data!

As the very last line in the section, we console.log our data that we get back from the API endpoint just to make sure we're getting everything we wanted. We have an array full of objects. You'll also notice that the key published_at holds our dates and they are not in any type of order. Their format is also not a simple four digit number representing the year which would make it easy to filter them into reverse chronological order. We'll need to take care of that.

Manipulating Our Data

Making a copy of our data variable

Here we declare the variable dataCopy which points to the dataJSON variable mutated into an array via the spread operator(...). Essentially, we are copying our returned JSON data so we aren't manipulating the original (bad practice) while making it into an array so that we can iterate over it.

After, we sort the array. Sort is an extremely useful array method that will put our array indices into the order of our choosing based on the function we pass into sort.

Typically, we might want to sort the data based on value (largest to smallest) so we subtract the parameter a from parameter b. But because we need to display our results in reverse chronological order I decided to produce a new date (accomplished with the new operator and the JavaScript built in method Date that creates a new platform independent formatted instance of a date. Now, because a and b represent our objects sitting inside our array indices, we can access the key/value pairs held within said objects. So, we subtract b.published_at from a.published_at and this should give us our dates in reverse chronological order.

Displaying the Fruits of Our Labor

Remember that output variable we set to null at the very top of our program? Well now is it's time to shine!

That output variable is earning it's keep now!

So, there's a few things going on here. First, we're setting our output variable to a new value by mapping over our dataCopy variable using the map method. This method returns a new array with the results of calling the provided function once for each index. The item parameter represents our objects inside of our array that was returned from the endpoint and thus has access to all of their properties such as title and published_at.

We return two list elements with a <span> inside each one (for styling purposes), as well as a string for the Title and Date Published headings. Inside of those, we have our variables that use template literals to set the title and the date for each post.

Then, we set our list variable's innerHTML equal to that of our output variable.

Finally, we have the closing bracket and error handling of our try...catch block as well as our function call:

This code will handle any errors and display them in the console

Final Code

Here is what our full code body looks like now:

The entirety of our code base

And here is our basic CSS styling:

Did I say basic styling? I meant basic :D

And here is the result of our work with it's very basic styling:

Isn't it beautiful?

As you can see, we accomplished what we set out to do and in fact the list is in reverse chronological order. Yay!

I hope you've enjoyed this walk through of my thought process and of how I solved this challenge. Granted, there are many ways of completing this so feel free to share yours with me! I'm excited to keep this series going and will post another after I've gone through another challenge!

This post was originally posted on my blog. While you're there why not sign up for my monthly Newsletter – I promise I’ll never spam your inbox and your information will not be shared with anyone/site. I like to occasionally send out interesting resources I find, articles about web development, and a list of my newest posts.

Also, I cross post most of my articles on Medium so you can find my work there as well!

Have an awesome day filled with love, joy, and coding!

Improve Your Workflow With These Tips For VS Code

Jonathan Sexton — Thu, 23 May 2019 21:25:37 +0000

Photo by Denny Müller on Unsplash

When I started the self-taught path of learning to code, one of the first things I needed to do was decide which text editor I was going to use.

Without getting into too much detail, after some exhaustive testing I went with Microsoft's VS Code. (Side note - This isn't a post about my opinions on which text editor is 'the best', so if that's what you're looking for you've come to the wrong place. Frankly, the best one is the one that you like and the one that suits your needs the most.).

After a few years of using this text editor I've compiled a list of some tips that have really helped me streamline my workflow. These range from cosmetic to small useful tips but also game changers that will take a little extra work.

Let's dig right in - with one small caveat: I work on a Windows machine so all following pertains to that operating system. My apologies to the Mac users out there as I don't know that platform.

Alright, now let's dig in!

Learn and Use Keyboard Shortcuts

This is by far one of the most effective time saving tips I give to anyone with almost all software. The keyboard shortcuts are put in place to help 'power users' get the most out of their experience with a piece of software. You'll find shortcuts in games, web applications, desktop application, etc and it's worth your time to learn and use them.

It is one of the more difficult pieces of advice ti implement as it requires you to rewire your muscle memory. If you've been using an application for a while you know what it feels like without having to think about it. Learning to use keyboard shortcuts requires you to think about actions before performing them.

I'll be honest, it will feel a little foreign for the first week or so but once you get the hang of it you'll be flying through actions at a much faster pace.

Some of the actions I use the most in VS Code are:

Creating an HTML element with a class/id --> div.container + tab = <div class = 'container></div> or div#container + tab = <div id = 'container'></div>
Ctrl + Shift + E --> Show the File Explorer
Ctrl + Shift + G --> Show Source Control (check out how to integrate Git into VS Code below)
Ctrl + B --> Show/toggle sidebar
Ctrl + ` (tilde) --> Show integrated terminal
Ctrl + PageDown --> Move page down
Ctrl + PageUp --> Move page up
Ctrl + F --> Search current document
Ctrl + P --> Go to document
Ctrl + , (comma) --> Preferences

These are just a few of the shortcuts I use on a daily basis. For a full list, check out the official PDF version of keyboard shortcuts from Microsoft.

Integrate Source Control

I've heard different arguments for both sides on this, but for me integrating source control into VS Code was one of the easiest and most effective changes I've made to my workflow. Before integration, I was switching between windows about every 3-5 minutes with lost time in between.

Now, that doesn't seem like a big deal (especially if you have multiple monitors and can leave the command line and VS Code up at the same time) but having it inside of VS Code has proven to be invaluable.

No longer do I need to Alt + Tab to my command line to type a commit message and then commit. It's as simple as hitting Ctrl + Shift + G, typing my message, and hitting Ctrl + Enter and then I'm back to coding.

Check out the official documentation on integrating source control into VS Code to get started. There's also a handy video on using source control (Git specifically) once you've completed the integration.

To make a long story short - integrating Git into my VS Code made my life easier and my workflow even better!

Use the Integrated Terminal

Speaking of integration, aside from version control we can also bring our terminal into VS Code. It has built in support for Git Bash but there are also extensions that allow you to use PowerShell also.

Not only is it nice to have the terminal inside the same space where your code is, it allows you to have multiple terminal tabs as well. I frequently have two or three terminal tabs open especially if I'm running a bunch of Gulp tasks that need to stay active but also I need to drop in some Git commands. Side note - if you find yourself using multiple terminals consistently you can actually set up keybindings that allow you to switch between the tabs with keyboard shortcuts.

Of course if you'd prefer to work with the external terminal that can easily be accomplished with the keyboard shortcut Ctrl+Shift+C (this is just another example where learning/using those keyboard shortcuts comes into play :D). Using this command opens your command line to the same directory that your integrated terminal was at.

The last juicy bit that drew me into using the integrated terminal is the fact that you can split your terminal section into as many tabs as your screen size will allow.

Below you can see I've split my terminal into 5 tabs and then an error pops up when I have no more room.

Splitting the integrated terminal into multiple tabs, each with it's own instance

Make Use of Extensions

VS Code has a vibrant and lively extension community around it. If you can think of a feature you'd like, chances are there's an extension for it or it's coming in a future build.

Extensions add extra functionality as well as some customization options that don't come with VS Code 'out of the box'. This functionality ranges from code snippets or making your life as a developer easier with tools like linting.

Many of these extensions make me more productive by adding features like giving me HTML boilerplate simply by typing html+tab or by allowing me to highlight my comments with different flags/colors to draw attention to them.

One of my favorite, and most used, extensions is Prettier. It allows me to format my code in an easy-to-read format by fixing my indention or adding semi colons at the end of my JavaScript. (It's important to note that I'm taking a 'syntax side' here and saying this is what I prefer. If you prefer another way that's wonderful and it's not wrong - but for me this is the style that works the best.)

Also, if you'd like to lose a few hours of your time just check out the themes that are available for VS Code. There are themes for the editor as well as file icon themes. If you're like me then you'll install as many as you can and constantly switch between them :D

I hope you've enjoyed this romp through the various aspects of increasing your productivity with VS Code. If you have your own tips/tricks that I didn't cover I'd love if you shared them with me.

This article was originally posted on my blog. While you’re there why not sign up for my Newsletter? I promise I’ll never spam your inbox and your information will not be shared with anyone/site. I like to occasionally send out interesting resources I find, articles about web development, and a list of my newest posts.

I also post articles on Medium so you can find my work there as well!

Have an awesome day filled with love, joy, and coding!

Key Takeaways From My First Technical Interview

Jonathan Sexton — Thu, 04 Apr 2019 01:02:39 +0000

Image courtesy of Kelly Sikkema on Unsplash

Some History

I have been teaching myself front-end web development for a little more than two years now. It has been a wild and crazy ride but also a fun and challenging one. I, like many other self-taught coders, have had my ups and downs with this journey but ultimately it has been a rewarding one thus far.

I started with resources like:

The list could go on and on but you get the point. After completing my Nanodegree through Udacity and a Responsive Web Design certificate from freeCodeCamp I have found a new confidence that I hadn’t felt before.

I want to continue that journey and decided it would be a logical step to start applying for jobs in this field. So that’s what I did and little did I know that people would be interested in me and my skills.

The Interview

I applied for a front-end web developer position through the Stack Overflow jobs section and thought if nothing else it’ll be great practice.

Honestly, I didn’t expect to get a call and after I applied I nearly forgot about it. Lo and behold a few days later I got an email asking me to take a HackerRank test.

I was floored at the thought of someone wanting to interview me for a position in a field I don’t hold a degree in. It was a huge validation of my skills and, if I’m being honest, was a giant ego boost.

I was extremely nervous and I had heard previously that even the smallest task can stump you even if you have completed it a thousand times before. I thought it was exaggeration at best but it turned out to be true.

I was asked to complete a simple function that took in an array, copied the contents, and returned the new array….my brain blanked -- it was as if I had never coded in my life. I eventually got the correct answer but it was a grueling process.

For reference, here is the code I ended up writing for the challenge:

let array1 = [1,2,3,4,5];

function duplicate(arr) {
    let arr2 = [...arr];
    return arr.concat(arr2);
}

duplicate(array1);

Here are some takeaways and feelings from my first interview for a tech position. Obviously, have your resume in order before applying to jobs...that's honestly step one but beyond this post. Maybe in the future I'll write a post with some suggestions about how to prepare your resume.

Hopefully these will help you when your interview comes around :D

Takeaways

Be punctual!

I’ve always been of the mindset that if you arrive early then you’re on time and if you’re on time then you’re late. If you’re interview is at 1 P.M. then you should arrive no later than 12:45 P.M. This mindset has worked well for me through the years and I know it will help you.

At best it’s rude and at worst it signals to your interviewer that you don’t respect their time with the added assumption that if you were to be hired you’ll be late on deadlines.

Never be late for an interview!

I arrived 20 minutes early for my interview today and had a few precious moments to gather myself in the car before heading in. I was thankful that I had time to “center” myself and calm my stress levels a bit.

Prepare prepare prepare

This is a broad strokes piece of advice in that it can mean anything from searching through LinkedIn for information on the company to reaching out to current employees for an informational interview.

At the very least read through the company’s website to gather some basic knowledge.

You should know some facts about the company you are applying to. It signals to the interviewer that you care about the company and the position you’re applying for.

I had very little time to prepare for this interview (the turnaround was 2 days between applying and interviewing) but I still read through their entire website, a few articles from a local magazine that featured the company, and read through employee profiles on LinkedIn.

Also, there are literally hundreds if not thousands of websites that will help you prepare for a technical interview with practice questions. I read through a few and felt much better about some of my knowledge.

Of course, you may know some info and just forget it or draw a blank in the interview - it happens. It happened to me today. I was honest and open about it and felt like the interviewer could relate because he dropped a few hints to guide me to the right path after my stumbles.

Going into my interview today I would have liked to have some more information about the company but I felt confident enough in what I knew to answer some topical questions if I were to be asked. I don’t think I’ll ever feel fully prepared but something is better than nothing.

Ask Questions

The importance of asking questions during the interview was stressed to me over and over again by several colleagues who have coding experiences/positions. I was reminded, more times than I care to count, that asking the interviewer questions could make or break my chances of getting an offer.

It’s not only helpful in the sense of getting an idea of what the job is like but it signals to the interviewer that you’re interested in the position.

Here are a few questions I asked during my interview:

Why do you like to work here?
What’s a typical day of work look like here?
What stack do you currently work in?
What operating system do you use for work machines?
How flexible are the hours?
What’s something you would change about working here?
What’s the growth/promotion path look like here?

This isn’t the entire list but I think you get the point. Show interest in the job you are applying for and gather some helpful/useful information at the same time. Again, if possible avoid talking about salary. Unless otherwise stated, you should view this as an informational interview.

Practice Writing Code by Hand

I know it sounds like an odd piece of advice but this was the part of the interview that really “threw me for a loop”.

I’ve written tens of thousands of lines of code in my text editor. I’ve learned some snazzy keyboard shortcuts and feel like I’ve gotten far more productive with my setup than I used to be.

None of this prepared me for handwriting code on a whiteboard.

It was a very strange feeling thinking about closing my brackets and writing a semicolon. My editor typically handles these actions for me.

I found myself thinking more about writing the correct syntax and closing my brackets than thinking about the solution I was being asked to implement.

Grab yourself a small whiteboard from any general store or a big box store along with some dry erase markers. Practice writing out your code along with some sample questions from any of the interview prep websites I referred to earlier.

I feel like this is one part of the interview I would go back and change if I could. I will definitely be practicing physically writing my code before my next interview and I hope you do as well!

Have Confidence

This one is extremely tough for me and I am certain that other developers can relate. I did not start out in the technology sector when I entered the workforce.

I've always had an interest in technology but it never steered my professional career (unfortunately) until now. Add to that being a self taught developer and there you have a potent platform for doubt and fear to creep in.

Knowing what I have built and accomplished is one thing but letting those actions influence my confidence is another. This is something I work on daily.

If you learn anything from my posts, learn to have confidence in yourself. We can do this. We can teach ourselves to code, build awesome projects, and get hired with a company and get paid for our skills.

Anytime you walk into an interview be confident. I know that nerves and emotions run rampant during the interview process when your brain blanks (like mine did) but fight through it and crush that interview. Keep that confidence no matter the challenge. But also remember that life is about balance -- stay confident not cocky.

Don’t Get Discouraged

This is also something that every developer no matter the language you code in, the discipline you follow, or how long you've been at it can relate to.

Some days I get out of bed before my alarm goes off, grab a coffee, and knock out projects all day. There was a day in November where I was getting so much work done that I didn't want the day to end.

There are also days where getting out of the bed feels like an insurmountable task in itself.

But through it all I have always kept my love for coding. I've managed to stay motivated enough to get some great things accomplished. It hasn't been easy and there are times where I'll work for an hour and then relax the rest of the day.

There are times where my PlayStation4 gets much more of my attention than it should but that's how I decompress and have some down time so that when I come back to what I'm working on I'm ready to completely annihilate it.

Find your motivation - whether that's a new job, providing for your family, earning more money or just loving your craft. Find your motivation and hold on to it tightly!

I hope this article has been helpful for you and provided some tips for you when you're next interview rolls around.

Drop a comment or shout at me on Twitter — I’m always happy to connect with friendly faces and fellow developers! All of my social medias are to the right of this article, just under the "Recent Posts" section.

I also cross post some articles on Medium so make sure to follow me there as well!

This post was originally posted on my blog. I'd love for you to come poke around there and see some of my other works.

While you're there don't forget to sign up for my newsletter at the top right corner of the page. I send out monthly e-mails with great articles curated from across the web along with some of my own articles. I promise not to waste your time or spam your inbox and you can unsubscribe anytime.

As always, have a fantastic day full of coding, love, family, and happiness!

Adding Dark Mode to My Website

Jonathan Sexton — Sat, 16 Mar 2019 23:24:18 +0000

Last year I made it a point to redesign my website from scratch. I wanted something simple and minimalist looking that clearly stated what this was - a portfolio website.

After I rebuilt my website from the ground up it seemed like everywhere I turned there was another article about adding a dark mode to your website.

At first I didn't think it would make that big of a difference because, while I am partial to darker colors, I felt like my website was a good balance between bright, fun colors and darker fonts.

My website before adding the light / dark mode toggle option

I read some of the articles I mentioned earlier and the more I thought about it the more I decided to go for it.

I took some inspiration from Flavio Copes who wrote a terrific article on this very subject. Unlike what Flavio decided to do with his site, I didn't add the user's choice to local storage.

This is due, in part, to the differences between our sites. I have a static site and there are no redirects/separate pages aside from the blog which is on a different platform so users generally won't be refreshing the page. It is a cool option and one that I may add in later on.

Dark mode enabled on my website

Dark mode enabled - 2

The Code

The code to achieve this was fairly simple. I took the same approach as Flavio did and added the style changes through CSS. I had to take a few more steps because I have an image on my landing page.

The class I applied to the website to make it dark mode

I had to use the !important flag on some of the rules because they were not being applied properly. This was the easiest approach to implement and I know it's not advised to use this flag so I'll be looking for an alternative in the near future.

Here is the JavaScript I used to get my toggle switch working correctly:

The JavaScript for adding functionality to my toggle swtich

I start by selecting my div with an id of light-dark-mode-container and adding an event listener to it.

Next, I set my variables of everything, which selects all content on the page, and projectTiles because this class belongs to a particular set of overlays I do not want to have a background of a solid color.

Next, since I'm using querySelectorAll which returns a static NodeList, I loop over all of the elements within both NodeLists and either toggle the class dark or completely remove it from the elements returned by the variable projectTiles.

What I'm left with is a container at the top of my website with a toggle switch that allows the user to toggle between light and dark mode.

I hope you enjoyed this post and maybe you learned something too! If you decide to implement this on your own website or your next project please share it with me (leave me a comment or shout at me on Twitter). I'm always happy to see the work that others create.

This post was originally posted on my blog where I write articles related to front end web development. I also cross post my articles on Medium, so you can find my work on that platform as well!

While you're there why not sign up for my Newsletter? I promise I'll never spam your inbox and your information will not be shared with anyone else.

Have an awesome day filled with love, joy, and coding!