DEV Community: Jon Raxa

.ENV Files

Jon Raxa — Mon, 19 Jan 2026 16:16:24 +0000

Source Code (skipped)
↓
Env Configuration (.env) <-- YOU ARE HERE
↓
Build Tool (Vite)
↓
Bundler Output (JS/CSS/assets)
↓
API Contracts (OAS)
↓
CDN / Hosting
↓
Browser Runtime
↓
Testing (Playwright)
↓
Observability (Datadog)

I was introduced to .env files during a personal project I was creating before getting hired. I then encountered it twice during conversations at work regarding testing feature flags. I couldn't contribute effectively because I'm fairly new to the concept of .env files. So here we are...

What are `.env` files?

What problem do they solve?

They separate code from configuration.

You do not want:

API keys
environment URLs
feature flags

hardcoded into bundles. These pose significant security risks if you were to leave them in your codebase.

How `.env` actually works

.env files are...

plain text
key/value pairs
read at build time, not runtime (in frontend). Meaning, it's built and put together before you start developing or seen in production.

Example:

VITE_API_URL=https://api.myapp.com

In frontend builds:

.env values are read by the build tool (Vite)
injected into the bundle as string constants
replaced at build time

console.log(import.meta.env.VITE_API_URL)

⬇ becomes ⬇

console.log("https://api.myapp.com")

⚠️ Important implication

Once built, values are public
You cannot “hide” secrets in frontend envs
.env controls which environment you’re building for, not runtime switching

Note

.env files define build-time configuration, not secure storage.

They control what kind of app you’re shipping, not secrets.

Summary

In its simplest terms, .env files give us a way to define and shape the environment we're working in. They run and are checked during the build process, so they don't change on the fly while we're working with the code.

The variables within the .env files are specific to the environment we're building. So for things like feature flags, we can determine if someone could see certain features doing something like, VITE_FEATURE_NEW_DASHBOARD=true, in a file called, .env.localhost. This means, "turn on this flag to show the new dashboard within the localhost environment."

I've found the best way for me to learn is to teach. My dumb brain cannot retain information without solidifying concepts through teaching. And what better way to do that than to post a public blog about what I've learn so others could tear it up. This post is part of my ongoing frontend dev series.

More Coding Challenge Mistakes

Jon Raxa — Mon, 13 Oct 2025 18:02:07 +0000

The most frustrating thing for me in an interview is seeing approaches to code I've never done. Should I have probably learned them in my own time?

Probably...

It's still a frustrating and defeating experience, and it set me back immensely in my final round interview.

Messing up with common state management tools in React and claiming to be some kind of React "expert" was embarrassing to say the least.

I didn't know there was going to be another code challenge since I had already had one during my second round. Also, I didn't take my beta blockers, so my mind kicked into fight or flight mode, having to calm myself down and take it step by step.

Of course, I see a problem I know I could solve, but since I was so frantic and thrown off guard by the fact that I even had a code challenge and with state management tools I rarely use, I couldn't think straight.

Here are the problems I ran into. Stuff I really should have known right away.

Context of problem

We have pre-written code that is supposed to allow users to add a 'to-do' item, delete, and edit. My task was to find the bugs and fix them.

Mistake #1: Identical IDs across state

This was crucial to get this right at the first go. Each time we add an item and either edit or select delete, if there are other items, they'll all commit to the action together.

Yet, I still needed a small hint that helped me figure out that the generated 'id' was shared across all the items. I spent a good amount of time trying to figure out the issue until he said, "You mentioned something about the ID earlier, what was that about?" Something along those lines.

const now = Date.now();
...
case "add": {
 return [
     ...state,
     {
     id: now
     ...
   },
 ];
}

As you can see from the code, the id is set with Date.nonw() which basically generates the same id across the items.

Duh...

Mistake #2: Filtering and returning state

I thought I had pretty gotten good at the filter method.

Keyword: THOUGHT

I was so focused on quadruple-checking my filter logic, I didn't return the state properly. When things weren't going my way, I thought right then and there that I was screwed. I spent a good 15 minutes on this.

Wasted...

BEFORE

 case "delete": {
      return state.filter((item) => {
        if (item.id !== action.payload) {
          return item;
        }
      });
    }

AFTER

 case "delete": {
      const newState = state.filter((item) => {
        if (item.id !== action.payload) {
          return item;
        }
      });
      return [...newState];
    }

This is redundant to do. "Filter" already gives us a new array that meets the requirements.

WHAT I SHOULD HAVE DONE...

case "delete": {
  return state.filter(item => item.id !== action.payload);
}

*sigh...

Mistake #3: Adding keys to lists

  <div
      key={id}

Basic React. Any list items should use a unique key for rendering purposes.

*sigh, again.

Mistake #4: Unfamiliar with `setState` in `useReducer`

My last implementation item was to ensure that the items persisted after refreshing the page. So, of course, we should use localstorage caching.

Most of the code was actually already written. My main problem was that state wasn't being set in the reducer.

  useEffect(() => {
    const raw = localStorage.getItem("data");
    dispatch({ type: "setState", payload: raw ? JSON.parse(raw) : [] }); // this wasn't running
  }, []);

Easy fix...

    case "setState":
      return action.payload;

Conclusion

I went over the code soon after I was done with the interview. I knew what, where, how, and why I went wrong. I think what enrages me is that these mistakes weren't things that I felt defined me as an engineer.

Even though I didn't write my code correctly, all at once, on the spot, it doesn't take away from the fact that I knew the whys behind the code and how to correct it. When there was an issue, I knew where and how to look.

I wish interviewers would just talk to my references, get to know my work ethic, see my passion and love for problem-solving, and how much I love doing it alongside others.

I'm tired of sweaty palms, cracking voices, and mini panic attacks during interviews. I'm tired of every interview needing to be my saving grace, since the longer I go without work, the hard it is to take care of me and my family.

I'm tired.

Laid Off

Jon Raxa — Mon, 09 Jun 2025 20:49:31 +0000

I worked so hard.

Blood, sweat, and tears.

Nothing was enough. The market has changed. The market has decided to kick me out.

I'm overexaggerating, but this was an industry I fought since college to get into.

I love software engineering.

The joy of solving problems, digging into solutions with other people, and figuring out creative approaches to an algorithm during a brisk walk. These are what got me up in the morning to work, even though it never felt like work.

I'm starting to believe now that I merely got lucky in finding a software engineering job. I was hired during the COVID market, which was a great time for developers.

I was getting callbacks, left and right, turning down opportunities, negotiating significant salary bumps.

Now here I am, sitting here discouraged from reading Reddit and LinkedIn about all the tech layoffs. Shortly after being let go, I read a message from a previous colleague on their alumni Slack channel about how he hasn't found a job in almost a year and could soon lose his house.

I'm not a very positive person, as you may tell. My previous posts have always been positive and lighthearted, encouraging people to never give up. I need to take my own advice.

It's harder now that I have a little girl to take care of.

I have enjoyed watching my daughter throughout the day, loved it in fact. But at the same time, I can't help but stress what the future holds for me in this career.

The best thing right now, keep going.

Job, Career, or Calling?

Jon Raxa — Thu, 21 May 2020 16:53:54 +0000

Three bricklayers are asked: "What are you doing?"

The first one says, "I am laying bricks."

The second says, "I am building a church."
![brick layerer](https://dev-to-uploads.s3.amazonaws.com/i/o98dkysce26ymkwkot67.png)
And the third says, "I am building the house of God."

The first bricklayer has a job.

The second has a career.

The third has a calling.
"Grit: The Power of Passion and Perseverance" by Angela Duckworth (pg. 159).

Most years, I start out thinking that I'm going to kill it. Whatever "it" referred to. I spent months trying to figure out what kind of new goals and resolutions I'd like to have in my life.

As the third month rolls around, hopelessness sets in—still, nothing. No defined action I wanted to pursue, no purpose I tried to revolve my life around, no reason behind the rhyme as they say.

One year, I tried to revolve my year around a single word: "courage." For the most part, this helped me quite a bit, but there were other years I couldn't even think of a single word the entire year.

There were years I would wake up and look out my window, excited for the day to end so I could go back to sleep again. What kind of life is that?

"Massive Action is the Cure-All" - Tony Robbins

In 2018, before the clock struck midnight on December 31st, I had already taken action against the horrible habits that I developed throughout the year. I merely made a decision and had enough. I found money lying in various investment accounts and savings, put it towards my debt, cutting it down to nearly half. What a way to start my year, eh?

I read an entire book in one day, making it a goal to read fifty books that year from my collection of unread books. Best of all, I realized the importance of a morning routine, but I also took action and committed to it (morning routines indeed change your life, get one!).

Why is massive action the cure-all? Because taking small, itty-bitty steps to your goals isn't going to set that crazy incredible momentum that'll you need to change yourself.

To move a bolder, you need to push full-force with all you got and get moving!

Your Habits WILL Define You

A few years ago, I slept around 12:00 AM to 1:30 AM each night while looking at my phone watching Snapchat news and Youtube highlights on the Joe Rogan podcast. I set no alarm and woke up whenever with no plan for the morning. When I wanted to read, I kept my phone nearby with the volume up for those "just in case" moments.

I became lazy, irritable, and on the brink of depression, again. My horrible Youtube binge-watching led me to learn about what your poop is telling you.

In your mind, think of swimming against a rushing river's current. That's the situation we put ourselves in when we're in this constant cycle of bad habits while our hearts have this strong urge to fight against it. It's tough, yet we end up going nowhere.

Setting the directions in your "good" habits earlier on, mixed in with an intention and genuine purpose in your life, will help establish a much better foundation for happiness and motivation in your life.

Walking up at 6:00 AM every morning for the past week to work out, meditate, and read has set an incredible trajectory for my entire day. I feel motivated, happier, and even had an incredible small talk with my dental hygienist.

Find Your Calling

Have I defined my calling clearly? In a way, yes. But I'll keep that to myself for the time being.

Going back to the story on these three builders, I found myself to be the first worker. I was laying down bricks. The day set up to be merely tasks. The bigger picture was never apparent to me, and I just went day by day hoping to find it.

I know that these hard times make all of this a bit unsettling. Although, sometimes, these obstacles are moments of opportunity and ponder.

Define your "why" and change your habits with massive action. You'll be surprised how far you'll go.

Why I Want To Leave My Work

Jon Raxa — Thu, 07 May 2020 15:26:52 +0000

What's your work industry? Retail? Marketing? Real Estate?

Believe it or not, the importance of tech in your company will vary based on where you work.

Tech isn't innovative and vital all around across the board.

My first job out of college was at a marketing agency. It was a decent job, but most of their websites were old with outdated code. My primary duty was to update these websites with promo codes, that was it. There were no new technologies, no optimizing layouts, no database enhancements, nothing.

Marketers aren't going to look at tech directly. They want numbers, data, and how to get to that bottom line; it only makes sense. Tech only plays a role if it gets them what exactly they want.

Or take another example, Apple. Surprise, it's primary focus is in their marketing. How do you sell and keep selling? I know of people who worked there, and they tell me that their engineers fall second to their design department. Sure, tech plays an essential role, but it's their focus and dedication to design that sells.

These aren't bad things, but it goes to show that it's not always about tech innovation everywhere you go.

Each company has its priorities, but tech is always going to be needed. Unfortunately, you're not always going to be as valued as you'd like.

Now let's bring it back to perhaps the worst place to do tech work, eCommerce/retail. As someone who works in this industry, I find that not only do I get poorly paid, I'm also not as valued.

I have skills and knowledge that would most definitely be useful, if not grown much more exponentially if I wasn't at a company that puts their retail stores first before technology.

My reality is that the company I work for caters to a generation that wants to go out and shop for clothes rather than purchase them online. At the very least, this is what's keeping me at the job, and I'm grateful.

However, for these reasons is why I precisely want to leave my company. I majored in computer science in college because I had a passion for innovating, building, and improving things. But, if a company hinders you from doing these things, isn't it fair to move on from it?

Ask these questions to yourself when looking or at your current job:

Are you satisfied?
What are your long-term career goals?
Are you looking to take more ownership?
If so, how about a startup?
How about this...Are you looking forward to Mondays?

When you're first starting, don't be picky.

If you're well into your career, start looking for a change if your work does not align with your passions. You're going to be working for most of your life, the least you can do is invest your time into a company that you feel takes you seriously and develops you in ways you'd like.

Interview Learning + DOM Manipulation

Jon Raxa — Tue, 05 May 2020 17:02:27 +0000

In the world of web development, pure Javascript remains king. If you came into web development only using jQuery, stop it. Now.

Better yet, any framework or library for that matter. PURE JavaScript is KING!

Learning + PRACTICING the necessary foundations of JavaScript is critical in your frontend development career, especially if you want to pursue a career in this field.

I've gone through several dozens of interviews, each one having failed because I couldn't complete the code (and sucked at problem-solving, granted I didn't know how even to approach some of these problems).

But, a skill that most wouldn't outright tell you is this:

interviewing is test-taking

Do you remember your finals in college? Or a pop quiz that came out of nowhere that was worth 50% of your grade? Think of all that put together and add in the professor/instructor watching you do it all under 15 minutes.

I was horrible with test-taking. But that's the unfortunate reality.

Another option is to approach interviewing as if you're coding alongside a friend/co-worker. Doing this will lessen the interview anxieties that will hopefully lead to your success.

Learn and develop the skills as to what precisely the interviewer might be looking after.

For instance, if you're interviewing for a frontend position, learn all things, everything frontend. Learn how the web works, what "HTTP" requests are, how APIs work, DOM manipulation, etc.

And for the love of God, take your time with each of the questions given to you. You're not some kind of hacker trying to break a security wall before the F.B.I. breaks in your door. You're changing a box on a webpage.

Below, you'll find a complete (possible) solution to the problems I had to solve.

You don't need to read them.

In summary, I was unprepared to solve each of these seemingly simple Frontend JavaScript and HTML/CSS problems. I also had major test-taking anxiety that froze me up several times throughout each of the interviews.

Center this shit

This one job interview that I'm glad I didn't pass. The position was full remote and eventually laid off over half their staff a few months after I had interviewed.

Everything went well up until the last portion of the coding test where I had to work with JavaScript and implement basic DOM manipulation.

In shot, make sure you know how to do basic Vanilla JS DOM manipulation. I'm talking things like "documment.getElementById" or "document.getQuerySelector".

Let's Move These Damn Boxes

Goal: Move the first box to the right without moving the other two boxes.

The most difficult part about this question was, how do we get a single div tag to overlap and move over the other div nodes? It's easy to determine that now, just use translate-transform.

The answer could have been all done in CSS. Unfortunately, I didn't have the knowledge of translate - transform property. This was something I didn't bother to completely understand since I wanted to move on from it to learn other seemingly, more inportant CSS concepts.

I really, really wanted this job. I love the company that I was interviewing for.

Moral of the story, learn and understand EVERYTHING to be a master of your craft. This is a non-negotiable. In this case, know everything there is to know about your CSS. I work with CSS every day for my job, yet this concept was a bit unknown to me because I never took the time to stop and learn what exactly I was doing to make specific styles work - CSS isn't magic.

Stupid Stoplight

This was my first technical interview. For someone who has never been in one, I was overwhelmed with nervousness and excitement. Based on the job description, this is easy peasy!

For the most part, things seemed to be going well. I made decent styles and had a seemingly good grasp on the React coding concept.

Then came the ending

Your Dog Days Are Over

I hadn't interviewed for a few months prior ot this coding interview. Based on the job description, this seemed like yet another interview I could pass with flying colors.

Once again, overthinking mixed with sheer nervousness and interview anxiety got the best of me. I ended up never finishing the exercise despite how easy it was with all the past interview experience I had.

This was the closest I was to getting past the second round. His feedback was that he wanted to see a higher "score" on my coding test. At the very least, I guess I know that these interviewers are grading me with some kind of point system.

For The Love of God, Make This Responsive!

It's been 15 minutes, you haven't coded anything...It's not looking good.

These weren't his exact words, but it wasn't far from them. Hearing this wasn't as painful as it seemed. In fact, I was relieved that he was upfront with me about not wanting to move forward with me.

The main problem with this interview was that I was utterly nervous. When a seemingly simple question is thrown my way, I get nervous, especially since I haven't interviewed in a while. This was the first interview I had since revamping my interivew application.

Change The Freakin' Grid!

This was my last interview. Long story short I didn't pass. I couldn't think straight with the time I had left and everything that I thought I knew was thrown out the door. The interviewer made suggestions for me that I didn't understand and it left me feeling lost towards the end of the interview. Moral of the story once again, PREPARE your ass off and LISTEN to whatever cues are coming from your interviewer.

Workplace Entitlement is a No No

Jon Raxa — Mon, 04 May 2020 16:23:08 +0000

Work presentations are mentally painful, especially if you've never done one.

I had the privilege of giving my first presentation a few months ago, right after our COVID-19 lockdown began.

Thus, my entire presentation had to be online. You'd think this was a win, but try giving a passionate speech with no one to validate your jokes and points was like talking to statues at a park.

Despite the many speeches I've done in my Toastmasters club, I was a nervous wreck.

For the most part, everything went well. I was enthusiastic, my slides were on point, and I was enjoying myself—all up until the very end.

At the end of my speech, I had a rather unenthusiastic reception from everyone (or so it seemed). No one gave a care in the world of what I created - a tool that automated 30% of my workload, working its way to 100% as a miniature CMS. Instead, they were more awestruck with the overall delivery of the presentation and the pictures in the slides.

Don't get me wrong, that's still good people listened, but the entire point of the presentation was to show that I'm a

"badass coder that they are underutilizing."

And this kind of thinking is where I've gone wrong.

After getting a little irritated and frustrated, I realized that this mindset to my approach at work is not healthy.

Sure, I couldn't control how others perceive what I did or what I created, but I can control my mindset over the love of the project I worked hard on.

Ultimately, I had to go back to my big WHY.

Why did I enjoy coding in the first place? Was it to gain approval from others? Was it to make people respect me?

No, it was because I LOVED creating things and solving problems for myself and other people.

Gaining approval and respect quickly phase out, especially in the workplace, leaving you wanting more. In contrast, continuously solving problems, building, and honing in your skills for the love of the craft is a never-ending satisfaction.

After my presentation, I still received a lot of praise from people. I'm grateful to have had an opportunity to make a presentation.

Presenting was something I wanted to do for a while to step out of my comfort zone and grow just a little bit more in my career. It was something I did for myself, and to make it about how good I wanted to look only defeated the purpose of why I created the tool in the first place.

Don't ever feel entitled to anything in your workplace. Don't ever expect things to turn out in your favor.

Always be grateful for what you have and where you are. Many folks would die to be in your position.

And if you didn't expect something to turn out the way you wanted to, then keep trekking on. Don't allow anyone or anything to discourage you from doing your best.

Consistently showing up and working hard with humility and gratitude will not only allow you to enjoy your work even more, but you'll feel much more at peace with where you are at work, which thus carries on to the rest of your life.