Act like an owner

Dear new developer,

I’d like you to close your eyes and put yourself in a couple of situations.

First, think about a car you have owned. If you haven’t, think of something else that you own and take care of.

I have owned an automobile. I changed the oil regularly in my car; okay, that’s a fib, I paid someone to change it, though.

I took care of any warning lights that came on, even though almost every visit to the mechanic resulted in bills. I definitely avoided driving over potholes. I listened for out of the ordinary sounds and, if they persisted, visited that same mechanic.

My cars aren’t maintained in mint condition. My current car has some dents and scrapes. I drove a car with a crack in the windshield for about 7 years. But, fundamentally, I take care of cars I own. Cosmetic dings are ignored, but root problems are addressed.

Second scenario. Have you ever rented a car? If you’ve owned a car, how would you contrast the level of care for a rental? (If not a car, how about a home?)

I have rented cars. I’m no dummy, I don’t want to lose my deposit or have the rental car company charge me when I return the car. I take some care. But I certainly don’t care for a rental as carefully as I do a car I own.

Hitting the occasional pothole doesn’t bother me. I certainly wouldn’t pay to have the oil changed.

With a rental, my incentives are different; all I really have to do is get it back in much the same shape at the end of the rental period.

Enough with the car analogies. Let’s talk about work.

When you are an employee, you are trading your time for money. When you are an owner, you are building a long term business. (How long? Some times for years, sometimes for centuries.)

Having been both an employee and a owner, I can tell you that being an employee is much like renting a car. A few issues here and there, especially if they won’t cause problems for years, won’t bother you too much.

Being an owner, however, is more like owning a car. You want to, at a minimum, take care of the fundamentals to keep the engine running. Depending on how mature the company is, you also may spend a lot of time tuning and improving the business, just like a car owner might invest in better shocks or tires, or change the oil themselves.

So, what’s this letter really about? Take an ownership mindset. It will set you apart from all the employees that are just treating the company like a rental car.

Some things you can do:

  • Ask “how will this change affect the codebase in 2 years? In 5 years?” You don’t have to do this all aloud all the time, but even asking yourself this question before diving in can help you make the change in a way consonant with the overall codebase.
  • Document code, processes and decisions. Two very valuable areas to document are confusing things and project setup.
  • When you encounter a bug, if you don’t have time to fix it right away, file an issue for future reference.
  • Write tests.
  • Talk to team members and try to understand why things are they way they are.
  • Interact and learn about other parts of the business.

However, just because you have an owner mindset doesn’t mean you should do everything an owner does. If you are an employee, set boundaries. An owner of a business can, and sometimes must, work beyond normal hours. They will reap the rewards of this extra work.

When I was building the MVP for a startup I co-founded, I worked every single day for a month. (Others have done far more, of course.)

But if you aren’t really an owner, set boundaries, particularly around your time. Why? Because at the end of the day, employment is still a trade of time for money. The residual value and control of the company rest with the legal owners.

In short, during the work day act as if you are an owner of the company. This long term view will differentiate you from other employees who are just trying to return the rental car and not lose their deposit. Then, when quitting time comes around, focus on other parts of your life, because it isn’t your business.

Sincerely,

Dan

You’ll always be learning

Dear new developer,

One thing I love about software development is that you’ll always be learning. This is because of two things.

First, there’s better and different hardware. It is possible that this pace will subside sometime, but looking at the variety of new computing hardware, sensors and components that have been created over the last 60 or so years gives me confidence that we’re at the beginning of computing becoming a utility, just like electricity. This is one of my favorite essays on the topic. This new hardware gives rise to new capabilities. Just like GPS in the phone gave rise to Lyft and Uber, I think that small connected sensors everywhere will give rise to new companies and software development opportunities.

The other reason why you’ll always be learning is that software itself is evolving. This is a very young profession. I believe at some point it’ll be as established and systematic as, say, civil engineering, but I think that’ll be decades if not longer in the future. That means that practices and tools are continuing to evolve. They both take advantage of new hardware, of practices learnt from other disciplines, and of lessons as systems are built. I already gave you an example of the first, but an example of practices lifted from other areas of knowledge is chaos/resilience engineering. An example of the last lesson is containerization and immutable infrastructure.

If you choose to be a developer, your career will be filled with learning. Enjoy.

Sincerely,

Dan

Learn curl

Dear new developer,

If you interact with web APIs at your job, learning curl is a good investment. Curl is a flexible, powerful, command line utility which lets you make HTTP requests.

In my current job, I build a lot of API requests. Side note: I’m going to use the shorthand API for web based, JSON API; there are many other kinds of APIs, but curl is mostly useful for this type of API.

I’ve found familiarity with curl to be very helpful as I create, share and debug these API calls.

Why learn curl?

With curl, I can easily script up API interaction. In the next section, I’ll discuss the common parameters I use.

Curl works across multiple platforms. It’s a lowest common denominator tool and is present everywhere. It doesn’t require anyone to install anything. (Okay, maybe not true on vanilla windows, but as soon as you have any unix based system, you have curl.) Update 7/21: curl is present on vanilla windows 10. Open up a cmd window and run curl and you’ll see curl: try 'curl --help' for more information.

You can share scripts with team members, add them to issue comments for provide bug reproduction steps, and version control them if you want to improve them over time. I find them especially helpful for issue reports, as there’s no ambiguity with a script.

Curl pairs nicely with jq (which you should also learn); you can pipe the output of curl directly into jq to get understandable formatted JSON.

I find when I use a low level tool like curl, I’m forced to have a deeper understanding of the problem than I would if I used a higher level tool. It’s kind of like a text editor in that way.

I haven’t run into a situation yet where curl couldn’t interact with an API in a way I wanted, though sometimes multi step interactions like an OAuth authorization code grant can be a bit cumbersome. You can set headers, provide cookies, send a request using any HTTP method, and provide data either inline or via a file.

Basics of curl for APIs

Here are the main switches I use with curl for API interaction.

-X <method> lets me specify the HTTP method, so -X GET is a get request and -X POST is a post request. Sometimes the HTTP method is implied by other switches, but I prefer to be explicit.

-H <header> lets me specify HTTP headers. You can use this many times in one command. Often if I’m sending JSON in a post with an authorization header, it’ll look something like -H 'Content-type: application/json' -H 'Authorization: Bearer APIKEYHERE'

-d payload lets me specify a payload for a post or put request. This will often be JSON: -d '{"foo":"bar"}' It can be multi-line if needed. I use single quotes around the JSON to avoid having to escape double quotes. If I need to have a shell variable inline, so that I can extract some text which changes often, I do something like this: -d '{"foo":"'$BAR'"}'

-d @payload lets me put the payload in a file and have curl read from that file. I use this switch less often, because I’ll usually put everything in a shell script anyway.

-vvv lets me see the back and forth of the HTTP requests and response, and also status codes.

As previously mentioned, I also usually wrap everything in a shell script so it is repeatable. On occasion, I’ll even check the shell script in, so that others can use it. This is useful if it is a part of a run book or troubleshooting guide, for example.

Here’s a typical curl shell script, in all its glory:

API_KEY=...
USER_ID=...
curl -vvv -H "Authorization: $API_KEY" -H "Content-type: application/json" -XPOST 'https://api.example.com/user/'$USER_ID -d '{
  "user" : {
    "name": "Dan",
    "blogger": true,
    ...
  }
}'

There’s a lot more available with curl; the whole man page is worth a read. But I hope I’ve convinced you that you can use curl to interact with APIs in a way that is:

  • repeatable
  • shareable
  • versionable

Alternatives

There are many alternatives. I am a bit familiar with postman, which is a web based application that lets you organize and call APIs. There is also a command line runner for postman called newman. Insomnia is another option that some of my team members use. It’s another GUI client with a corresponding CLI client called inso.

While I haven’t dug deeply into these alternatives, at first glance it seems to me that they give you tooling power and richer collaboration. But nothings free; you lose ubiquity and simplicity.

curl is a powerful tool, available everywhere, for examining and interacting with APIs. Learn it well.

Sincerely,

Dan

Meetings are work

Dear new developer,

I remember when I started out, I thought meetings were a waste of time.

All those people in a room (now a Zoom), discussing an issue. Folks would go back and forth, and at the end of the meeting you’d hopefully have a decision. But often the output was just more research or discussion. You might have to go back to the client, the team, or vendor and ask more questions. This would be followed, you guessed it, another meeting to relay the results.

I just wanted to code! I wanted to be told what to do, or if that wasn’t an option, take my best reasonable guess, and program.

Meetings sure seemed like a waste of time.

Now, many years and meetings later, I realize that meetings are really work. They help align teams, ensure you are building the correct things, and share knowledge. These are key parts of delivering software and making sure that all the programming isn’t for the lost cause.

Yes, you can do many things asychronously. I enjoy flexible work hours and chat tools and pull requests and email lists. But whenever I see an email or other async conversation look like it is going to go off the rails, I jump in and suggest a meeting. It may be a pain, but it will let you cut through days of unclear emails. For example, I remember meeting with a vendor in India at 8pm at night, because that was the time that was least inconvenient for the both of us. We were able to resolve questions we’d been exchanging emails about for days with thirty minutes of conversation.

Meetings define and push the work forward every bit as much as programming.

Sincerely,

Dan

Avoid toxic environments

Dear new developer,

Avoid toxic workplaces. I wish I didn’t have to write this, but there are enough stories out there (here’s a few on HackerNews) that I feel I should.

How do you know? If you have to ask if an environment is toxic, it probably is.

There are levels of toxicity, of course. Fundamentally it is about a lack of trust between you and the organization, but can take many forms. Some blatant indicators:

  • yelling
  • belittling
  • disrespect
  • verbal abuse
  • throwing things
  • empty promises

Avoid these kind of environments. If you come across one while interviewing, give it a pass.

If you accidentally find yourself in one (after all, you could have misread signals in an interview or the situation at a once-happy company could degrade) leave ASAP.

You may not recognize you are in a toxic workplace, but your body might. Listen to yourself. Notice how you feel about going into work. Having a bad day here and there is not unusual, but regularly dreading work is an indicator; dig deeper and try to understand why.

Or try other ways to gain insight. Track your mood on a scale from one to ten for a month or two. Keep a journal if that’s your bent. Ask your friends for feedback on how you like the position and how your mood is.

Avoid toxic workplaces. You may learn some skills but it will come at an emotional cost.

Sincerely,

Dan

Set your boundaries

Chain link fence

Dear new developer,

A few years ago, I suggested you over-index at your first month or two on the job. I stand by that advice. Extra effort up front will earn you a reputation as a good employee. I also think that first impressions matter; plan to make a good first impression with your team and manager.

On the other hand, it is important to set your boundaries and learn how to say no.

How can both statements be true? The answer is that you must thoughtfully consider what you want.

Reasonable boundaries

Corey Quinn wrote a great tweetstorm about what to do when you start a job. The whole thing is worth a read, but I wanted to call out one piece of advice in particular, “begin with reasonable boundaries”:

What’s reasonable? Ah, there’s the rub. You want to balance being a team player, helping your company succeed and not being abused. Because there are companies out there that will abuse you. For the past couple of years, the job market for developers, especially once you are no longer “junior”, has been stellar, but that won’t last forever. And there are firms out there whose whole business model is to hire developers, place them in soul-sucking positions or places they can’t be successful, wring them dry, and start anew with another set of developers. Avoid these places.

Other jobs will be less obvious about this, and may not even be intentional. It could be an organizational flaw or a historical artifact that the company’s success depends on violating norms around work life balance for their employees. In any case, considering and setting your own boundaries will ensure that you are “working to live”, not “living to work”.

Think about time and effort you want to invest, both on the job and in side projects. I can’t offer you specific guidance other than to write down what you are thinking and revisit it periodically (every quarter or so). Map what your current job expects with what you are willing to give, too. If the expectations diverge, that’s a signal it is time to move on.

After you have determined your boundaries, set them. As Corey suggests, one way is to set an alarm and leave work at a regular time. There are many other ways:

  • Don’t check work emails outside of work hours.
  • Ask for more money if you are expected to wear a pager (if it wasn’t part of the job description).
  • Avoid tasks beyond your job description (unless you want to take them on).
  • Don’t install slack on your personal phone.
  • Turn off your notifications.

Don’t be flagrant about your boundaries, but be firm. “I’m sorry, I can’t do that” is a phrase you’ll want to use regularly. Some flexibility will help: find out what team norms are and work within them as best you can. For instance, if your whole team starts work at 10am, then align your hours: stop work at 6pm, not at 5pm. You’ll have an easier time maintaining boundaries if the team doesn’t view them as counter productive.

When in doubt, have a conversation with your manager at your one to one. It may be an awkward conversation, so a good way to start is to ask the manager about how they manage their boundaries.

Crossing boundaries

As a software developer, there will be times when you’ll break your boundaries. At the end of almost every project I have worked on as a developer, there was “crunch time”, where I worked more hours than usual. Not 80 hour weeks, but more than 40. This is in part because estimation is hard. There are surprises at the end of every effort. Examples include:

  • New requirements that weren’t clear at the beginning
  • Tasks that the team should have done earlier but forgot about
  • External changes that require software to change as well
  • An accumulation of schedule slips from earlier in the project that pile up at the end

In some cases you can push back on these surprises by shifting dates or cutting functionality; in other cases you just need to grit your teeth and deal with it.

Break your boundaries rarely and intentionally. If it becomes a regular occurrence, consider other employment.

Sincerely,

Dan

Plant a tree

Dear new developer,

Here’s a great quote:

The best time to plant a tree is 20 years ago. The second best time is now.

Unknown

I spent a little bit of time trying to track down the original source, but my google skills failed me. But no matter the source of the quote, it is worthwhile advice.

What does this mean to you? It means that you should start a long play now. That is, an activity which will pay dividends in the future, but does not right now.

What is an example of a long play?

I think one successful long play for me is my blog. I have been blogging since 2003 and it has helped me in a number of ways. Both directly, in being a “proof of work” for employers, and indirectly, by helping raise my profile in the community. But the benefits didn’t accrue in the first 6 months or the first year. It was the continual effort of writing, at least once a month, which delivered the value.

Another example of the long play is this blog itself. I wrote for months before I had any appreciable traffic.

Other possible long plays:

I didn’t realize how many of these long plays I’d written about (or folks had guest posted about) on this blog until I put the above list together. The long play has obviously been a long running theme.

The common thread is that all of these activities accrete value over time. Slowly at first. Oh so slowly!

Here’s the thing, though. The long play can be scary to commit to. It doesn’t have immediate financial returns, just like planting a tree today won’t give you shade tomorrow. You only see the benefits years or decades from now. That makes it tough to invest time, at least for me.

How do you know what kind of long play makes sense for you? The only way I know to learn this is to try different things. Sure, you can read about them and try the activity in your mind. But there’s a world of difference between, say, thinking about contributing to an open source project and actually doing so. When you try a long play activity, you can see whether you enjoy it enough to keep doing it.

A few other fun facts about long plays:

  • Committing to a long play doesn’t mean you can’t stop. You can stop if you want. Knowing this makes it easier to start.
  • Starting small is wise. Don’t expect to, say, submit a PR to rails or another high profile open source project as your first contribution. Finding a typo or expanding the documentation is much more realistic.
  • Different long plays require different levels of effort.
  • Long plays can pay dividends in the short term, but that’s a side benefit, not the main one.
  • You probably don’t have energy to have a day job, enjoy a personal life, and do a bunch of long plays. I’d start with one or maybe two.
  • Pick something you enjoy. An analogy: when starting a two sided marketplace like AirBnB, you run into a chicken and egg problem. No supply means no demand, and vice versa. So you need to kickstart one side, and one way is to have your marketplace provide value for one type of party. This is called “single player mode”. In the same way, a long play is going to be hard, so pick something that gives you personal value and enjoyment. Even if no one else benefits, you still do.
  • The level of effort you put into a long play will change over time. I wrote a blog post every day for 100 days once. I now write one blog post on my professional blog every month because I less available effort and time.
  • You don’t have to know exactly how a long play will turn out. You won’t, in fact. It can change over time as you get a clearer vision of your goals.

However, there are two things you must do for a long play.

You must commit. No activity is fun all the time. Sure, it was a rush to publish a book based on this blog, but there was a ton of dreary activities leading up to that event. I’ll tell you what, I even started and stopped the proposal a few times and needed a kick from my SO to submit it.

You must start. Just start. Pick something from the above list (or another kind of activity which resonates with you) and block out time to do it.

Plant that tree today. I guarantee you won’t regret it.

Sincerely,

Dan

Be a mentor

This is a guest post from Akira Brand. Enjoy.

Dear New Developer,

Be a mentor.

Seriously. Find someone a little bit behind you in their journey and mentor them. All you need is an hour a week. Heck, even an hour a month. Work through exercises and projects with them. Tutor them in an Udemy class. Sign up to mentor hackathon participants. Find a code school you like and mentor their students.

You may not think you know a lot right now, but you’ll solidify what you do know in profound ways through mentoring. You’ll find every gap in your own learning that you didn’t know was there, and what’s more, be able to fill it. You’ll start to deeply understand the context behind certain problems, as well as the grander architectural and design systems that underlie all good software.

You’ll learn why things you didn’t care for or regard as important before actually are (for me it was pseudocoding), how to problem solve in a team, and build empathy for not only the end users, but for your mentee, and, for yourself.

Be a mentor. Find someone who needs a teacher and be that life changing person for them. It’ll be one of the most fulfilling segments of your career.

Good luck, and remember to breathe!

Akira

Akira is a full stack developer currently working on building a JavaScript bootcamp with Emeritus. They love to digitally nomad and are currently in Boulder, CO.

Turn off those notifications

Dear new developer,

Shut off your notifications.

There are so many interruptions in your workday that it can be hard to find the time to dive into deep work. Disabling alerts from communication programs can help you stay in the zone and avoid having distractions pushed to you.

Here is a list of the software for which I’ve turned off alerts:

  • slack on my computer
  • slack on my phone (if I even install it there)
  • email on my computer
  • email on my phone
  • any other applications on my phone (except SMS)
  • discord

I know people who have disabled new text message alerts. I think that is a bit extreme, but do what works for you.

Shutting off these notifications lets you check messages in these systems on your time, not whenever someone sends you a message. Even though it feels good to respond quickly, doing so impacts your ability to ship working code (or whatever else you are trying to deliver).

Here’s a playbook for freeing up your attention.

First, think about how much time you should block out for focused work. If you are just starting, aim for thirty minutes of uninterrupted time. If you are working on a hard problem, a block of a couple hours a day will be better.

Then, discuss with your team at work. Find out what their expectations for responding to messages are, for any mechanisms used such as email or slack. This is a great conversation to have with your manager at a one to one. The expected response time will vary based on the content of the message, but try to get a broad understanding. Is it ok to respond an email or slack message within a business day? At the end of the day? In a couple of days?

One thing to be aware of is that as a new developer, you may get blocked. You need to make sure your heads down time doesn’t mean you keep banging your head against a wall if you don’t see a path forward. There’s a distinction between needing to reach out to someone for help and being interrupted by others. The former is expected, the latter is what you are trying to avoid. Make sure you discuss that distinction and have clarity around it.

Another thing to know is that decisions may get made without your input, especially if you wait a couple of days to reply. This is a tradeoff. As a new developer, however, you may be more interested in the decision as opposed to weighing in on it.

Next, make the changes to your applications. Turn off notifications for communication software such as email or slack. I find it helpful to block out time on my calendar to remind folks. You may need to close messaging clients entirely.

Also, don’t forget to provide an escalation path. If someone really needs your feedback on something, how can they get ahold of you? I always add my cell phone number to my profile and tell people that if they really need me, text me. Plan for this. It won’t happen often (at my current job, no one has ever texted me) but if you are truly needed, you want to be available.

Finally, set a schedule to check in, as informed by your needs and the team’s expectations. Think about whether you will check in daily, a few times a day, or every hour. Whatever you and your team have agreed to, do that.

Beware the tendency to check in on email, slack, etc, mindlessly.

You are avoiding the push of distraction; don’t fall into the trap of pulling distractions to you. This is a bad habit of mine. If I’m waiting for a page to render in a jekyll site or a local server to restart, I’ll sometimes idly flip over to slack or email (or worse, an online community like Reddit). Doing so defeats the entire purpose of limiting notifications.

A colleague once told me that there are three types of tasks: big, medium and small. You can think of your day as a container that you are filling with rocks, gravel and sand, respectively corresponding to the big, medium and small tasks.

If you fill your day with small tasks, such as checking your email, you won’t have time to work on the big rocks, just as if you put sand in the container first, you won’t have room for the rocks.

If, on the other hand, you allocate specific time to the bigger tasks, the smaller tasks can fit around the edges.

Turning off your notifications and controlling when you are responding to messages from others is a good way to focus on your big goals.

Sincerely,

Dan

My experience with burnout

This is a guest post from Landy Simpson. Enjoy.

Dear new developer,

This year has put everyone’s mental and physical health to the test, including yours truly. There’s the ongoing pandemic, the Black Lives Matter (BLM) movement, the 2020 American elections, the End Sars movement; the list goes on. This year, I’ve dealt with an assortment of health issues, which became incredibly hard to deal with once quarantine reduced the number of available health services. Between trying to manage my mental health, physical health and working from within these four walls formerly known as my bedroom — I’m exhausted.

No, in fact, I am BURNT OUT, and I know I’m not the only one feeling this way.

In the last two months, I noticed it became increasingly difficult to get out of bed. I thought my burnout was terrible in the summer — I had no idea what autumn would bring. On the weekends, I’ve found that I can sleep for over 12 hours and only eat a single meal. I haven’t been fully motivated to write, brainstorm content, or work on personal projects. I’m feeling frustrated because I’m not productive. I’m upset I spend most of my free time sleeping, and I’m a bit worried that my burnout affects the quality of my work at my job. But as I work through these conflicting feelings, I’m starting to realize that I shouldn’t fight them, instead, I should accept them and find ways to maneuver the storm called burnout.

During this time of year, where seasonal depression is upon us, it’s easy to spiral into self-loathing and self-pity. And despite feeling burnout, it’s also easy to force yourself into a rigid routine in the hopes of digging your way out of your slump. In coming to terms with my ongoing burnout, I’ve learned if you treat moments like this with compassion, patience, and a bit of transparency, you can overcome burnout. I started opening up discussions with my mom, my best friends, and even one of my co-workers to see what I can do to improve my situation.

It’s incredibly important to open up discussions with our family and friends about mental health because it’s also essential to recognize signs, like burnout, of declining mental health. Together, we can find ways to help each other take preventative steps, like seeking counseling, incorporating healthy physical activities, and practicing self-care and self-compassion.

I can only provide some essential tips to understand yourself better and take the first step in caring for yourself during burnout. However, if you’re dealing with any form of mental illness, please speak to a professional.

Don’t force yourself to get back into a routine.

Notice you’re going through something and treat yourself like you’d treat a friend going through a tough time. Don’t force your body or mind to adapt to a whole new routine overnight. You’ll burn out faster, and you’ll end up spiraling out of control just as quickly as you adapted the routine. Be patient with your mind and body. Incorporate one piece of your routine a week at a time. Allow yourself to adjust to the changes and don’t be too hard on yourself if you mess up once in a while. You’re only human.

Figure out why you’re feeling drained.

Put context to the feeling so you can understand the draining areas of your life. Ask yourself some questions to help reveal potential causes of your burnout. For example, do you feel reluctant to get up for work or school? Are you dissatisfied or overwhelmed with the progression of a particular goal in your life? When was the last time you spoke to a friend or family member, and do you feel alone as a result? Wherever those draining areas are, it’s important to identify them to know what you need to work on to make yourself feel better. There might not be an immediate or obvious solution, however, knowing the cause of your burnout can at least help you stay sensitive to that problem.

Reinforce your values.

It’s hard to get out of bed or feel like anything you do is worth it at the moment, but don’t lose sight of your dreams. Remind yourself of your goals to help reinforce your values. You aren’t just a couch potato or a lazy little bean. And if you are, that’s fine, but remind yourself you’re a person full of dreams and aspirations. You’re just going through a tough time right now, and that’s okay! You will get back to those dreams soon enough as long as you keep making them a priority.

Even when you adopt a routine, it’s okay to take a break or have a bad day where you can’t get out of bed. Don’t punish yourself for feeling burnt out. You’re doing so much, which is fantastic. But always remember to take care of yourself first, which leads me to my last point.

Take care of your body and mind.

These burnout periods are your body and mind’s way of saying it’s time to take a break. Follow your instincts and indulge a little. Sleep in a little longer, eat your favorite meals, talk a bit longer on the phone, binge a show, take a long bath, exercise. Do something to relieve your body and mind of all the stress that it’s going through.

Taking care of yourself can also be seeking therapy or talking to your boss about time off. Even a small getaway road trip to expose your body and mind to a new environment is a way of taking care of yourself.

We’re living in a difficult time right now, and we must be patient and mindful of our feelings. Look out for your friends and family during this time, and most importantly, stay safe.

— Landy

This was originally published here.

Landy Simpson is an Experienced Software Engineer who is skilled in front-end development. She blogs at https://simplyy.medium.com/