If you’ve set up an existing codebase on your local machine before, you may know the pain of transferring and setting up ENV variables. Sometimes we have an ENV template, but they often go stale if someone forgot to update it even once.

Or, perhaps you have an existing codebase you work with and a merge was made while you were gone and you missed the Slack messages about the new ENV.

Long-story-short, sometimes we are missing ENV vars.

Now, this wouldn’t be the biggest problem in the world if the app would just crash. Unfortunately, many developers (and I’ve noticed AI) love to give a fallback value.

Warning: Insidious Fallback

export function getApiUrl(): string {
  return process.env.API_URL || "http://localhost:3000"; // <-- insidious fallback
}

If this ended up on production, some very strange results would occur. But, would it be noticed right away?

The Solution

The correct solution would be to have something like this before every ENV variable:

let apiUrl: string;

try {
  const value = process.env.API_URL;
  if (!value) {
    throw new Error("Missing required environment variable: API_URL");
  }
  apiUrl = value;
} catch (err) {
  console.error(err);
  process.exit(1); // Or handle it in some other way
}

However,

The Better Solution

Create a requireEnv() function that provides fail-fast protection, is clean, and provides good feedback. Here is the one I use in my own codebases:

/**
 * Get a required environment variable or throw an error if it's not set
 * @param name - The name of the environment variable
 * @returns The environment variable value
 * @throws Error if the environment variable is not set
 */
export function requireEnv(name: string): string {
  const value = process.env[name];

  if (!value) {
    throw new Error(`Required environment variable '${name}' is not set`);
  }

  return value;
}

And it is used like this

import { requireEnv } from "./requireEnv";

export const config = {
  apiUrl: requireEnv("API_URL"),
  dbPassword: requireEnv("DB_PASSWORD"),
};

Let’s say that API_URL is not set, we get

Error: Required environment variable 'API_URL' is not set

Conclusion

Like the title says, when in doubt, crash—catch your missing env vars early!

So, you have a web or software engineering team that uses AI, huh?

How is that going for you?

Using AI is a good thing. We encourage the use of AI tools like ChatGPT, Grok, Claude, Gemini, and Cursor (which relies on them). However, using AI can also cause some issues. I want to address these issues with a "checklist." Engineers, if you are using AI to generate code, please consider the checklist before putting up your PR!

AI Checklist

1. Did I read the entire file before asking the AI to accomplish a task?

Reason: AI will accomplish a task according to the problem you present it. The AI does not have in mind principles like Do Not Repeat Yourself, creating re-usable functions in shared utility folders, or other architectural principles. Architecture is up to the developer!

2. Ask yourself lots of questions about the generated code.

Questions to ask:

• Is this DRY?

• Do we have a utility function somewhere else that should have been included in this solution?

• Is this how I would have solved this problem?

• Is this over-engineered?

• Does this solution fit with the patterns we have used elsewhere in the code base?

3. Consider readability and maintainability

AI does not have in mind readability or maintainability in the sense of how a human engineer might debug code. A lot of our time as engineers is spent reading and understanding an area of code we have not seen before, or have not seen in a long time. So, we need to write code the way we read code.

Not easy to understand, debug, or update code

// not too bad, especially if formatted differently. But, not great.

const result = users.filter(u => u.age > 18).map(u => `${u.firstName} ${u.lastName}`).sort((a, b) => a.localeCompare(b)).slice(0, 5);

Easy to understand, debug, and update

const getTopAdultUserNames = (users: User[]): string[] => {
  // Filter adults
  const adults = users.filter(user => user.age > 18);

  // Map to full names
  const fullNames = adults.map(user => `${user.firstName} ${user.lastName}`);

  // Sort alphabetically
  const sortedNames = fullNames.sort((a, b) => a.localeCompare(b));

  // Return top 5
  return sortedNames.slice(0, 5);
};

const result = getTopAdultUserNames(users);

4. Do I understand the code I am pushing up?

This is a must!

Before AI existed, code reviewers, team leads, and engineering managers only needed to deal with a stray copy-pasted answer from StackOverflow. Now, it is daily or hourly that code reviewers must look more closely at the solutions presented in pull requests to make sure there are no hallucinations, that it jives with the codebase, and that it follows the team's patterns, etc.

Conclusion

AI has sped things up for all of us, but it will slow our code reviews down if the engineers putting up code are not going back through the code and refactoring AI generated solutions to match human engineering practices.

Engineers—You have super powers now, but as Uncle Ben said,

With great power, comes great responsibility.

-Benjamin Franklin "Ben" Parker

What about you?

How have AI tools affected your life as a developer, code reviewer, or engineering manager?

You have an input that must make a real-time query to the database. This is often an autocomplete, but in my case it is checking to see if a subdomain is unique.

Input Component

I am using PrimeVue, so that is where the components are coming from.

            <div class="flex flex-col gap-2">
              <label for="subdomain">Organization Subdomain</label>
              <InputText
                id="subdomain"
                v-model="subdomain"
                placeholder="i.e. grace-church-bc"
                :class="{ 'p-invalid': errors.subdomain }"
                fluid
              />
              <Message v-if="errors.subdomain" severity="error" variant="simple" size="small">{{
                errors.subdomain
              }}</Message>
              <Message
                v-if="subdomainMessage.message && !subdomainLoading"
                :severity="subdomainMessage.severity"
                variant="simple"
                size="small"
              >
                {{ subdomainMessage.message }}
              </Message>
            </div>

Nice.

GraphQL File Structure

When I work with GraphQL, Apollo, and Vue Apollo , I find separation extremely important. GraphQL is flexible in its ability to fetch just what you need, but it requires a lot of boiler plate. I find the following setup very good for the frontend portion—

src
|_graphql
    |_operations
        |_index.ts // barrel file
        |_subdomain.ts // one of many operation files
    |_composables
        |_index.ts // barrel file
        |_useCheckSubdomainAvailability.ts // one of many composables
    |_types
        |_index.ts // generated by codegen
|_App.vue
...

Operations

import { gql } from "graphql-tag";

export const CHECK_SUBDOMAIN_AVAILABILITY = gql`
  query CheckSubdomainAvailability($subdomain: String!) {
    checkSubdomainAvailability(subdomain: $subdomain) {
      available
      subdomain
    }
  }
`;

This is a simple GraphQL client query that uses the graphql-tag library to parse the GQL syntax. It takes a string and then calls our resolver checkSubdomainAvailability with the string as its argument. We are asking that the resolver give back available and subdomain. We don’t really need subdomain, but I don’t feel like changing the existing code at the moment.

Composables

import { useQuery } from "@vue/apollo-composable";
import { CHECK_SUBDOMAIN_AVAILABILITY } from "../operations/subdomain";
import { computed, type Ref } from "vue";
import { CheckSubdomainAvailabilityQuery } from "../types";

export function useCheckSubdomainAvailability(
  subdomain: Ref<string | undefined, string | undefined>,
) {
  const { result, loading, error, refetch } = useQuery<CheckSubdomainAvailabilityQuery>(
    CHECK_SUBDOMAIN_AVAILABILITY,
    computed(() => ({ subdomain: subdomain.value ?? "" })),
    {
      fetchPolicy: "no-cache",
      debounce: 500,
    },
  );

  const isAvailable = computed(() => result.value?.checkSubdomainAvailability?.available);

  return {
    loading,
    error,
    isAvailable,
    refetch,
  };
}

This is where the magic really happens.

We then break out the usual variables from the useQuery composable. Notice we add the generated type using a TypeScript Generic, which allows us to have type safety wherever we use this composable throughout the application.

Next, notice that we are able to pass an options object to the useQuery composable. We pass fetchPolicy: "no-cache" just in case another user creates the same subdomain within the cache duration. This keeps the data fresh. Secondly, we pass debounce: 500. This means the composable will only make the query 500ms after the data changes and also cancel any previous requests it had started.

The Impact

This is crucial as we would otherwise overload our server with requests on every keystroke.

But, with debounce, things work great.

I love that debounce is built into the Vue Apollo composable so we do not need to create a separate function and utilize a third party library like VueUse or Lodash to accomplish this task.

It has been over one year since I published my featured article, Becoming a Full-Time Developer: Introduction. I desired to write this series over a few weeks, but life got away from me. I have two kiddos under nine, a house we are renovating, a master's degree I am finishing, and a full-time job after all!

However, I am compelled to write about this subject because I want to help others enter into this amazing career. I love being a developer! There are many things I learned along the way and I believe I can help some of you get to where I am at today. In this installment, I'll talk about my resume.

There is probably a lot out there about resumes. I did not go and read about resumes. However, I knew I wanted to stand out and communicate who I am and not just what I have done. I will also say that I must be pretty good at writing resumes because a college professor from another state once left me a voicemail that he found my resume online and used it as an example in his class!

So, here is the real-true-to-life resume I have used. I've even included an error I found where I accidentally copy-and-pasted the same date for my bachelor's and upcoming master's degree. Oops!

Take a look and then I will discuss some things.

Real Life Resume

Examining my Resume

Let's take a look at each element of my resume from the top down.

Header

Similar to a website, I have a header that is intended to grab the attention of the screener. Remember, if your resume gets stopped at any point, you do not get an interview. If you do not get an interview, you cannot get that job. Our goal with the resume is to get an interview! There are three important aspects of my header.

1. The image: You need to pay some money and get a real headshot from a real photographer. My wife did this for me as a gift one year and I had no idea how often I would use my headshots. I use them on X, Slack, (sounds like Ex-Lax lol), email signatures, and more.

2. The tagline: A tagline helps instantly frame you. I know this version says "Developer + Great Guy," but for some positions I said "Developer + Designer" or "Developer + Leader" depending on the position I was applying for. I felt for the position I was applying for I did not want to pigeonhole myself into a particular role, but wanted to communicate that I am humorous and personable.

3. The quote: A quote shows others that you read and what drives you. I recently heard an interview with Taylor Desseyn where he said something like "When we interview people and ask 'what are you passionate about?' and the answer is 'nothing in particular,' that is a red flag. I just want to know you can be passionate about something. Because maybe you can also be passionate about what we are doing here."

Intro

Your intro is the next most important thing. Here is your elevator pitch. Screeners want to know who you are, what you can do, and why they should pick you. So, you can see I did these three things pretty clearly and used bold text sparingly to emphasize what is important to remember about me.

Experience

Moving on, we get to your experience. What we want to see here is the meta (company, position, and years there) and then a story that communicates what you did, stack highlights, and how you added value to that company. Some people call for the Star Method, but I do not think there is room for that. Consider how I made the companies I have served look great (which makes me look great) and the way I highlighted parts of my experience that are valuable to the companies I am applying for. By the way, I think the stories should start longer the more recent they are and get shorter. Further, you can just blanket some things that are not that relevant. I was in full-time church ministry for eleven years, but that is not the most crucial to know for the roles I am applying for.

Education

Education is not that important. That is, nobody cares about your GPA or where you went to school. Also, choose the most important things, but you do not need to fill up your paper with every badge you have ever earned on CodePen or FreeCodeCamp.org. What are the big blocks in your educational foundation? Now, I do not know if this is different if you have not attended college, so you may need more advice here.

What You Can Expect

This is essentially my conclusion. This is where I really want to hook people and help them realize they are missing out if they do not interview me. I thought about what I am good at and what I want to be doing, then put them in bold.

My Story

This is an "extra." If you have the room, you can share a back story that will help the interviewers get to know who you are. The screeners may not read this, but the people at the next round of interviews probably will. In this space, I can talk about my skills outside of tech and where I am at in life right now. Anything you can do to create a conversation during an interview will keep you "top of mind" when team leaders and CTOs are doing tens of interviews a day.

Contact

Obvious...

Expertise

I break my expertise into two categories: Daily and Less Often. I do this because I want people to know I am not just loading up my resume with buzzwords. This differentiation allows me to be honest and highlight my strengths. Also, you will find that these lists get long quickly. What kind of companies and positions are you applying for? If you are getting a SaaS job, nobody cares about your WordPress experience. Show us you have the skills that we need.

Other Skills

I love this area. I am sure everyone has skills that are not directly relevant to the position at hand but may be useful in cross-team meetings, or at least as another hook to create conversations with interviewers. Almost every interview I have ever had has brought up Zelda with me.

Quick Facts

This is another opportunity to share who you are and create conversation hooks.

References

I do not know why, but I felt like having a good, symmetrical two professional and two personal references was just right. Find people that can vouch for you and I would guess the "higher up the ladder" they are, the better. Honestly, I have never had an interviewer talk to me about my references before. Maybe they are not even called very often!

Links

I struggle with the links. Can I be real with you? I have weak links (am I the weakest link?). My CodePen is filled with half-baked things from throughout the years, my GitHub is a mess of project ideas, my portfolio has not been updated in years, my blog has two or three posts on it, and nothing is interesting on my Twitter feed.

But, you know what? The links look good. Am I right? Who doesn't love the feeling of contact information at the bottom of a website, and who doesn't love a bunch of links at the bottom of a resume? So, I say, keep the links, be they weak or strong.

Additional Thoughts

• Do not include things in your resume that you do not want to do. I read in the book 48 Days to the Work You Love that people are tempted to bulk up their resume with impressive things but that do not give them life. If you keep advertising yourself for things you do not want to do, then you will keep getting put in positions to do those things.

• Change your resume to match the job you are applying for. Your lead statement can focus on things like design if you are applying for a hybrid Frontend-UI/UX position or on your versatility if applying for a full-stack role.

• If a cover letter is asked for, I have taken the resume template and just included a custom paragraph that brought in elements from my resume. Most cover letters can be the same, but make sure to uniquely name the company you are applying for. However, do NOT forget to change it for each company!

• What did I use to create my resume? I tried a few different programs but finally settled on Keynote. I think Keynote or PowerPoint are excellent programs because they allow you to put elements off the side of the document to swap in and out, but when you have the document the way you want it you can easily export it to various formats.

• I recommend making folders for the companies you are applying for and then exporting your resume as a PDF with a filename like brian-scramlin-resume.pdf. The folders create namespaces for your resume so you can keep them from being something like brian-scramlin-resume-google.pdf. To me, that kind of filename shows you may be writing custom resumes depending on the company you are applying for. I understand that I told you to do that, but you do not need to be so obvious about it!

• Jenna Pederson has eleven more great tips in her blog post here: https://jennapederson.hashnode.dev/11-tips-for-writing-a-resume-to-land-that-job.

How About You?

What tips and tricks have you learned regarding developer resumes? Are there any resources you would recommend to others?

Hi. I'm Brian and I recently became a developer for ArborXR!

An old friend of mine shared she is looking to get into development herself, which caused me to want to impart all I've learned over the past couple of years.

Maybe it can help you, too.

Have you wondered any of the following...

• Do I need a degree to be a developer?

• When am I considered a "real" developer?

• Am I a "fake" if I use xyz framework?

• Why does every job description want a "senior" developer? What is a senior developer, anyway?

• Is there a "best" language or framework to learn?

• How much money will I make?

• Is working remotely "real"?

• What do all these buzzwords and acronyms mean—PR, MR, DevOps, e2e, Kubernetes, etc?

• Do I need to master Git, unit tests, shell commands, and SQL?

If so, you're not alone.

These are questions I had and had to learn the answers through pure experience. However, you, young padawan, will glean from what I have to share. I will answer these questions and many, many more through this series.

In this introductory post, I'll share my story of becoming a Developer (and not being afraid to believe it).

My Story

Prologue

Let me begin by sharing a snippet of my experience before I ever saw HTML for the first time. I am doing this so you know I am a real, regular human being. I am not a genius. I did not have a huge "head start" on programming.

I began using computers when I was around three-years-old on a Tandy. My step-dad loved computers and electronics and I was hooked from the beginning. I never learned anything about programming, but enjoyed taking computers apart, messing with Windows settings, and defragmenting my hard drive regularly.

By the time I was in high school and college, I got into video / photo editing, motion graphics, and 3D modeling. If I ever considered doing something in the tech field, it was in the creative-design arena.

My focus in college was not computer or math-related at all. I earned a degree in Christian Ministries. I attended Indiana Wesleyan University from 2005 - 2009 and my goal was simply to help people.

I was able to travel to many places and be part of many amazing ministries from about 2002 to 2011. I worked with Native Alaskans in remote villages, reconciliation between people groups affected by The Troubles in Northern Ireland, and Christians in impoverished areas of Costa Rica, to name a few.

After graduating from IWU in 2009, I became a part-time Youth Pastor and Substitute Teacher. So, how did I get from there to here?

Foundations: HTML and WordPress

Well, the church I worked for had a terrible website. I couldn't take it. So, I searched around for different ways of fixing the issue. At first, I tried this new service called Wix, a flash-based website builder. However, I kept coming up with limitations on how to get our sermons online in a way that could be searched and sorted.

This led me to WordPress. I realized I needed a server to install WordPress on and ended up signing up for a cheap server. It took some reading ( we barely had YouTube at this time ), but eventually, I figured out how to install WordPress, buy a theme on ThemeForest.net, and point our domain to this installation! Yay!

Then, something amazing happened. I saw HTML and CSS for the first time.

I had set up an extra desktop computer in my office to mentor students in video and graphic work. One student, Ryan, came in one day and said "Hey Pastor Brian, I started a class at school today on web design. Check this out."

He opened up Notepad on our Windows Vista machine and wrote some HTML

<h1>Hello World</h1>

and then some CSS

body { background-color: red; }

Mind. Blown.

Looking back, I've always been a mix of creative thinking + linear/logical thinking. I think that's what attracted me to After Effects and Blender—The ability to create beautiful things by using organized input. But, for some reason HTML and CSS were different. I didn't need to drag and drop anything. There was meaning to the syntax, as well as styling. There was nesting and relationships. It instantly filled my heart with joy.

This led me to dig into articles and online learning environments. I just checked and, amazingly, it all started almost ten years ago:

• CodeAcademy: Joined Oct 3, 2012

• GitHub: Joined 2013

At this time I was making simple websites, learning CSS, and a tiny bit of JavaScript / JQuery.

But then, questions and ideas began flooding my mind.

Full-Stack: Ruby on Rails

After getting a good understanding of how basic web pages work, as well as some familiarity with how the web itself works ( requests, servers, responses, databases, etc ), I wondered "What can I do with this?

I felt as if I was an artist at heart, but no talent. At this point in my life, however, I realized I could earn and learn the skills I needed to create whatever my heart desired.

What about a simple app to replace giant group texts asking "Who's in for morning basketball?"

What about a website that connects church benevolence information so we can see how to help people better, and be aware of who is"playing the system"?

I've always wanted something like a "prayer team" where I could post something I'm going through and others could pray for it, then I could update the request as "answered" or keep others updated.

I had to find a way to connect all the pieces together.

That's when I found the book Beginning Rails 4 by Adam Gamble.

This book helped me understand and experience full-stack web development by putting all the pieces together and then offering a framework that combined them seamlessly.

Rails had it all—Frontend, backend, routing, databases, and tons of third-party libraries ( gems ).

Soon, I decided to put some money where my mouth was and spent $149 at onemonth.com where I completed my certificate on Mar 03, 2015—A day after my 28th birthday, and two months after my first child was born.

I built a Pinterest clone. A full CRUD app! I even pushed things to GitHub and deployed to Heroku. It was an amazing experience, and the tight one-month deadline kept me focused. I was out of tutorial hell and into developer heaven.

Okay, maybe not "developer heaven"... I still didn't know what PR meant at this time ( no I am not joking! ). But, I could begin to take what I learned and apply it to my own ideas.

Maybe... I could even make money.

Real Life: Frameworks, Clients, and Processes

At this point I was working as an Assistant Pastor at a larger church and had many responsibilities, not to mention a new baby. However, my wife and I had a concrete goal of paying off all our debt following the Financial Peace University plan. One of the things we knew we needed to do was get some extra income.

So, while my wife started selling stuff on eBay for people, I started Nerd Specs Creative—A general, digital-handyman company.

Okay, I don't know if it was a "company" since it was just me, but I did go to the bank and get a "Doing Business As" ( DBA ) account. So, I did have a real business debit card ( and had to pay taxes on my freelance work ).

My first client was a friend who started her own CPA firm. I created the site using Weebly because they had a sweet white-label interface. And, yes, I realize I just went from Rails to Weebly Well, pick yourself up off the floor and realize that

1. She didn't need a custom, full-stack web application

2. Clients need to be able to edit their content ( and I don't have time to build that! )

So, I got everything set, and she really loved it. However, she ended up going with a CPA-focused web service which offered her weekly newsletters to send to her clients automatically. My heart sank. But, then she said she would like to buy the design and give it to the web service and have them implement it on their CMS.

She asked "how much do I owe you?" I had no idea what to say. I loved doing the work. I was just learning. I felt like I didn't do anything to really help her. So, I replied, "Oh, nothing. Don't worry about it. We didn't even get it launched."

Then, she said, "Brian, don't ever charge for anything other than what your service is worth to your client." She explained when she began she was not charging as much as others, but her quality was better. When she raised her prices over time, one of her biggest clients said "Now you're finally charging what you're worth."

Charge what your service is worth to your client.

Wow. That's some great advice.

And, to make it stick, she wrote me a check for $300!

I couldn't believe it. I just made money doing digital work—Something I really enjoyed. I realized at this point, I just got paid to learn!

From there, I did a few more Weebly sites, but quickly came to the end of that CMS' capabilities for customization. I went back to my WordPress roots and found I could charge clients the price of the ThemeForest.net theme and then customize it, and now charge a hosting fee. Email was included for free, because I didn't really know what it was worth to people.

When I started, I was spending about $20/month in hosting fees on SiteGround.com and charging $20/month per website and email. At first, I charged a flat rate of $300 for a website, but eventually switched to a $20/hour rate.

Looking back, I was charging nothing But, again, my goal was to get paid to learn, instead of paying to learn.

My goal was to get paid to learn, instead of paying to learn.

So, I continued to do this.

I wrote a Rails app that could manage church buildings and facilities ( it was called Truseease, a play on church trustees ).

I implemented an entire Magento site for Impact Gel. This was killing me due to the time they wanted from me and the low $20/hour pay.

I wrote DrydenWire with the ProcessWire CMS/F after a co-worker tried to create a large-scale news website with Wix. It was a very frustrating situation where she paid me a little to do it, while she got paid a lot more to do nothing. As this company grew, more was demanded of me, and as the sole developer, with a full-time ministry ( which is way more involved than a job ), a new kid, and a marriage, I was stretched to the limit. Once I got half of a Cordova app written in pure, vanilla JavaScript, and I was spending hours studying how to integrate push notifications, I about lost it.

I was failing at everything, all at once. I had nothing left to give. My wife told me to quit, but I had to battle my people-pleasing issues. Finally, though, thankfully, God gave me the strength to face my inner-turmoil and step out of the situation.

Before I did, I made sure another ProcessWire developer was able to take over. There was a little bad blood, but my family was more stable. At this point, I felt I needed to choose between Ministry and Development. So, I chose Ministry.

I was able to become the Lead Pastor of New Journey Community Church in Wabash, Indiana. We had another baby, grew that church, and I began a Masters in Theological Studies at Portland Seminary.

Of course, I still loved to code. So, I developed our church's website, said "no" to many clients, and tried to launch a couple of smaller things, but didn't have the time to finish ( i.e. http://wabashhelp.com/ )

So, how does this lead to me being a full-time developer?

My First Dev Role

Well, once again I took on too much. The church was growing, we had another kid, we had our own home, I was working on my Master's degree, and then my youngest had a significant injury. This final event really took a toll. We were driving 9-10 hours a week to take her to therapy, performing tons of therapy at home, undergoing surgeries, and trying to care for our first daughter.

With the pressures of ministry, combined with the other complexities, I felt I was beginning to slip internally. I didn't want to fail as a Husband, Father, Pastor, or Follower of Christ. So, I made a difficult decision—to step down from the Lead Pastor of our church. The Board offered me a sabbatical, but I felt I had to completely step down for a time of healing and reflection.

At this time, I had no idea what I was going to do. The tape played in my head,

"I love programming and web development, but what do I know? I don't have a degree in this stuff. I don't have many complete projects. Who is going to hire me?"

Now, interviews and hiring is a whole post in itself. It would be much longer than what I will share with you now. But, the quick of it is that I worked really hard on my portfolio website, re-worked my resume to focus on transferable skills from ministry to the tech space, and applied to local areas.

Web developer work is sparse in North-Central Indiana, where I was living. However, I came across a company only thirty minutes away who said they were looking for a Frontend Developer. Boy, did I not think I had a chance.

Well, apparently I did.

The feedback I received from that interview was

• You are obviously a good learner

• You fit our culture really well

• Your references and experience show you have great soft-skills, which are difficult to come by

I did not need some of the crazy things you see on job postings:

• "10+ years of C++ / Java / etc experience"

• "Kubernetes expertise"

• "Be a Git Ninja"

• "Produced your own Linux distro"

But, in May 2020, I got my first full-time developer job.

It was a great experience being here, but I'd like to have an entire post dedicated to "What I learned at my first real developer job", so I'll just let you know it went really well. I loved it. I learned a ton. I wrote Vue ( which I had never written any modern MVVM frameworks )

And, then after COVID I went full remote, which led me to explore other opportunities.

My Current Dev Role

As of June 06, 2022 ( four days ago! ) I started at ArborXR as a Frontend Developer II. It was a promotion from where I was and I am writing more Vue and TypeScript—Thankfully all Vue 3!

I look forward to sharing more in-depth lessons I learned through each of these phases in my Developer journey.

So, subscribe and stay tuned!

I have blogged in the past, but I have struggled with finding the right balance between

• Site Speed
• Appearance
• Ease of Writing
• Reach
• Portability

All divided by how much time I have to spend developing the thing.

Let's use a point system.

• 😍 = 2
• 😐 = 1
• 😖 0

My Experience

WordPress

• Site Speed: 😖
• Appearance: 😍
• Ease of Writing: 😍
• Reach: 😐
• Portability: 😐

Score: 6

Overview

The general issue with WordPress is to increase speed and customization, you must increase the complexity of development and decrease out-of-the-box niceties.

Site Speed 😖

Unless rolling your own theme, you are at the mercy of the theme-developer. You'll often find things like:

• Loading the entire Bootstrap library, instead of parsing through the SCSS and JS needed for the site.
• Not lazy loading images.
• Auto-loading jQuery and other full JS libraries for one or two minor features.

Further, everything is bundled, which used to be important for speed optimization. However, the modern web no longer favors large blocking bundles, but small, delayed, prioritized ones.

Appearance 😍

WordPress themes often look quite good. There is not much to say here.

Ease of Writing 😍

I absolutely love the WordPress Gutenberg editor. It allows markdown or rich text and supports columns, as well as third-party blocks. It is an excellent block editor and I wish it were based on an open-standard so I could use it in my client sites.

Reach 😐

There are many options for shareability on WordPress, as well as good SEO plugins. I would definitely rate it high. However, traffic is completely dependent on organic or paid reach. There is no community-feed reach, as with Dev.to or Hashnode.

Portability 😐

I'm probably being a little unfair here. Exporting to WordPress XML isn't technically your only option. However, third-party plugins are required for JSON. I would rather have everything pure markdown and in a repository.

Custom Site

• Site Speed: 😍
• Appearance: 😍
• Ease of Writing: 😐
• Reach: 😖
• Portability: 😐

Score: 6

Overview

Keep in mind, the way I consider these factors is not "doability" but how they jive with the time I actually want to spend working on the tool itself. I have other projects to focus on, and I want to be creating content, not constantly working on blog engine.

Imagine this scenerio: You are a full-time mechanic who enjoys driving Uber on nights and weekends. Do you want to spend your after-hours working on the car, or driving people?

Site Speed 😍

Site speed should be no issue for an experienced developer. Whether it's a static HTML site, a Next.js, Nuxt.js, or ProcessWire site, it will be as fast as you make it. I'm sure if you're reading this, you are cacheing, lazy-loading, optimizing images, loading only the resources you need, etc.

Appearance 😍

It looks as good as you make it :) However, I will say I've met many developers who are great with algorithms, but are terrible at design. In this sense, I could knock down appearance to a 😐. For me, I enjoy design as much as development.

Ease of Writing 😐

I have used many rich text editors from TinyMCE to Quill.js to CKEditor and none of them compare with something like Gutenberg. An open source block editor is something we are in serious need of that is based on outputting CSS Grid through inline styles or some sort of dynamic class system without bloat.

Reach 😖

Can I just say, I hate dealing with API tokens and authorization? The amount of time I have spent writing server scripts to check the renewal date for long tokens is barely worth the effort when I could use some sort of plugin. While anything and everything is possible with a custom blog, I felt like wiring up sharing was annoying. Plus, I'm just a blog lost in the wind without a platform like Dev.to or Hashnode.

Portability 😐

This is generally what you make it. On my last PHP-based blog I had a function I could call to retrieve all the blog posts quite easily, but there was finesse involved in getting them into JSON. Again, work is involved. Depending on the backend you used it could be easy or hard.

Static Site Generator

I do not have experience using a static site generator. Could someone let me know how they were rate their experience according to site speed, appearance, ease of writing, reach, and portability? I would guess it is similar to a custom site, except portability is way easier due to a repository of markdown files.

Score: Unknown

Blogging Platform

• Site Speed: 😍
• Appearance: 😐
• Ease of Writing: 😐
• Reach: 😍
• Portability: 😍

Score: 8 Winner!

Overview

A blogging platform is an all-in-one SaaS which provides you an editor, contend delivery, and an audience. Some examples are Medium, Dev.to, and Hashnode.

Site Speed 😍

Speed should be great as the platforms are all CDN-based.

Appearance 😐

Appearance is so-so, since there is limited customization. However, it's also hard to make it look terrible.

Ease of Writing 😐

Ease-of-writing is alright. The positives are

• Markdown
• Easy embedding
• Code insertion

However, lack of columns, separate preview tabs, and lack of third-party modules doesn't wow me.

Reach 😍

Reach is excellent due to the built-in audience, share buttons, and SEO.

Portability 😍

Portability, at least on Hashnode is excellent. All I need to do is click "export" and I get everything in a nice JSON file.

Conclusion

I have chosen to publish on Hashnode. I was able to sign up, throw in my https://blog.nerdspecs.com address as the host name, and launch in about 5 minutes. No joke.

As I said earlier, many developers fall into the trap of "working on their car" and never get to the "Uber" part. If you want to write, then get writing. And if you want to write now, consider a blogging platform like Hashnode.

Help others who read this!

What criteria would you add?

What platform or technology stacks would you add as blogging options?

Do you agree or disagree with my experience?

And, I really would like to hear from someone on their experience with static site generators—Which one do you use? What do you like about it? How does it stack up in according to the criteria I suggested?