It's been since I started working at Amazon. Before I left my previous company, I was overflowing with ideas for software projects. Some were non-starters; others, worthy of work. For example, I converted my old 2011 MacBook Pro into a PostgreSQL and web server to run an app on my home network. Then, as soon as I started at Amazon, I stopped. The server and code repo have remained untouched.

It all depends on my capacity. To answer the question with another question: How much am I pushed to the limits of my software engineering capacities--problem solving, learning new things, thinking hard, coding, writing technical docs, etc.--at work? If I'm maxed out, I don't have the energy or desire to do much more. If not, then I feel the itch. The itch to keep learning or implementing what I have learned.

Is this a good thing? I think so. I'm challenged at work. I'm learning and expanding my technical prowess at a rapid rate. At the same time, I lament not having the space to work on my ideas. It's fun seeing what I can think up and then trying to do it. I'm not too worried though, for everything there is a season.

The purpose of writing this post is twofold: to connect the dots and make sense of this journey for myself and to inspire and encourage anyone else who might be on a similar journey.

A Predisposition to Programming

I have always been a problem solver, a tinkerer, and an explorer.

As I think back, I can recall numerous precursors to my future love of programming. I have always loved mathematics. In elementary school, I joined a team of Mathletes. We trained after school in preparation for the annual competition, which included various challenge rounds. We'd spend a whole day doing math and then be ranked based on our team score.

In 2005 when I was 12 years old, I participated in the Sally Ride TOYChallenge, which involved inventing a toy and developing a prototype. My team's toy, called The Underwater X-treme, took us to the finals at Hasbro's headquarters in Boston where we pitched our toy before a board of judges. We ended up winning first prize which included a trip to NASA's Space Camp in Alabama.

I was an avid Lego-er. Aside from being a fan of following the instructions to build something cool, I loved making my own creations. I would build elaborate kingdoms, cities, vehicles and then bring my creations to life my creations through stop motion movies.

In high school, math and physics were my favorite subjects. While I procrastinated most homework, I would do math before I played video games, watched TV, or hung out with friends. I just enjoyed doing it.

I think these examples demonstrate the piece of what makes me, me: I am a passionate problem solver and a perpetual learner. When faced with a problem, I am excited and my brain starts running, speeding down every path trying to find a solution. I find it hard to rest with an unresolved challenge laid before me. My brain will even keep working while I sleep. It has happened on numerous occasions where I will fall asleep with a lingering problem and wake up with a solution. Or I'll simply dig in, research, and implement until I have arrived at the optimal solution. And then, I get that buzz, that feeling of accomplishment, that feeling of bringing something new to life and I keep coming back for more.

In university, I debated between engineering and biblical studies. I ended up choosing the later, which meant I stopped attending to my excitement for and skills in mathematics and all things tech. Fortunately as it turns out, this was temporary.

First Exposure

These passions were reawakened in grad school thanks to another love of mine--video games. My housemate and I shared a mutual love of gaming and spent long hours where we probably should have been studying exploring and creating in virtual worlds.

We were console gamers until we wanted mod Skyrim. Since we were broke graduate students in 2016, we turned to an old pc tower of mine from 2004. We upgraded that baby to it's highest capacity and were able to run Skyrim on the lowest settings possible. This didn't satisfy us for long, so we both built our own gaming PCs from scratch.

After spending many long hours gaming together, we thought it would be fun to create our own video game. We'd consumed a lot of good content, now it's time to create. I committed to learning programming so that we could get to work building our video game. Looking back, I have no idea what we were thinking. We were both full time graduate students and I had a part time job as a Youth Pastor. The task required more time than we were able to give.

Nonetheless I started an online course through Harvard called CS50: Introduction to Computer Science. The first half of the course is comprised of learning computer science basics through programming in C. This laid an excellent foundation of understanding memory allocation, pointers, data structures, and algorithms that still carries me today.

While this class didn't bring to fruition the world my housemate and I dreamed up, it did bring to surface my love for mathematics and problem solving. When I programmed, I actualized my capacities. I was good it and the concepts just made sense. I continued programming as a hobby because after all I was paying a lot of money for my graduate degree program. I stayed on my current path yet refused to let my love of mathematics be ignored.

Full Send

Many strands of my thinking and experience culminated in my decision to career pivot. Rather than list all of them here, I want to describe the moment I decided to full send.

I sat at the dinner table with my soon-to -be wife on a lazy summer night. We sipped our wine and dreamed about our future. As we did, the potential career pivot for me entered into the conversation. We'd spoken about it many times before; this time was different.

Our dreams about the future included children, a home for hospitality, a back house for grandparents, and my wife writing and raising our kids. These were important to us and that night they added a new weight into our discussion.

With these dreams on our hearts and minds, we decided I would career pivot into software engineering. I was overjoyed and excited--my passion for problem solving and love of mathematics would be given life.

Committing to a career pivot is one thing, making it happen another. With no technical background on paper, I didn't know where to turn. I finished the CS50 course and started learning Javascript on a deep level. Beyond this, I didn't know what would set me up for landing a job. I was confident in my ability, but how could I grow my skills?

I started a research phase. I spoke with my dev friends (some who also made rapid career pivots into software engineering). The overwhelming advice I received was build something or contribute to open source projects and if you can, join a team and get actual experience developing a product with multiple engineers.

Someone pointed me in the direction of Codesmith, a software engineering immersive program. The face paced learning environment and collaborative approach to engineering stood out to me. But what stood out to me most was the opportunity to work on a team under the guidance of the tech accelerator OS Labs. I was sold.

At the end of 2019, I stepped down from my position as Assistant Pastor at Journey of Faith and started Codesmith. I excelled at programming. The pace was perfect for me because it coding clicked. After developing my skills, OS Labs connected me with the Nautilus team.

The Nautilus team shared a passion for devops. We created a desktop application called Nautilus. It's a Docker Compose visualization tool. On the Nautilus team, I got more than just the experience I was looking for--I built and launched a product that I am proud of and made some good friends along the way.

Securing a Job

With Nautilus launched, the team decided to pursue other opportunities while maintaining the application. For me this meant job searching. The job hunt is full of challenges far different from the challenges of learning to program. This may have been the most difficult part for me in the whole career pivot journey.

The difficulty was twofold. First, sending out a quality application for a quality company takes a lot of energy--writing a cover letter unique to the company; researching the company's values, tech stack, and industry; and going through the interview process with specific companies. It's a constant performance and self-promotion so that my skills and personality will be noticed by a company.

Second, after all that energy most of the time (99% for me, it took around 100 applications before I landed a job), the process ends in rejection. I needed courage and confidence to keep pushing. I held on to what I knew was true about my ability and kept applying amidst rejection. But this also took a lot of energy and many days ended with discouragement.

I just keep chugging along. I found ways to sustain myself and my drive for programming during this time. I worked on algorithms every morning for an hour. One to prep for technical interviews when they came. And two because algorithms are fun and helped keep my coding skills fresh.

Also, I continued to work personal projects. I built this website that functions as a portfolio/blogger. I learned PHP by building a CMS under the guidance of an online course. I got involved in working on a friends web application called winebud. All of these projects allowed me to do what I love while I continued to apply to jobs. I kept a regular work schedule working from 9 to 5 on job apps and personal projects. It was hard, self-motivated work. And it all paid off.

After about a month and a half job hunting, I landed a job with Green Street Advisors working on the external web team. I couldn't be more excited about this opportunity and the company. The team is filled with bright engineers who love what they do and are excited by building cool stuff. It's a collaborative work environment where I'll be able to learn from experienced engineers and contribute from my skill set.

I signed the contract on Friday, June 5th and now I anxiously await my start date of July 6th. My sister-in-law's words describe how I felt, "And just like that, career changed."

The hard work paid off. I get to do something that aligns with my skill set and my passion. I look forward to showing up to my job because I love the work that I am doing. I can't wait to build cool stuff with my team at Green Street Advisors.

As said at the beginning, "I have always been a problem solver, a tinkerer, and an explorer." Software engineering is the culmination of this drive. I like to say that I've always been one at heart--researching, implementing, assessing, repeat. Now, it's just activated.

Hello world. I'm Joshua and I'm a software engineer at Green Street Advisors.

Whatever the items, keeping them in my mind causes them to get jumbled. As an exercise, I've decided every so often to write my current to do list here.

1. Add an RSS feed for the writings section of this website.

2. Start consuming RSS feeds by setting up a feed reader and curating choice content from other sites.

3. Write about my journey to becoming a programmer.

4. Add a dark mode to this website.

5. Implement prev and next buttons for easier navigation through writings.

6. Read The Practice of Programming by Brian Kernighan and Rob Pike.

7. Build a CRUD application in PHP.

8. Create something with Vue in order to learn the framework.

9. Install Deno and experiment around with it.

The Nautilus team deployed the application on April 17th and we received great feedback from the Docker community. Our product hit top 10 on Hacker News at launch date and was mentioned on Google's Kubernetes Podcast (episode 99) as hot news related to microservices.

How Nautilus Came to Be

As a software engineer always seeking growth, I had multiple dev friends encourage me to build something. I researched what to build and if it would be possible to create with a team of other bright engineers. I discovered OS Labs, a nonprofit tech accelerator, through which I met the Nautilus team--Danny, Michael, Aris and Tyler.

As we discussed what excited us about the current web development landscape, we discovered a shared interest in DevOps, specifically containerization and container orchestration. After research and interaction with the Docker community, we heard an expressed desire for a Compose instance visualizer.

We were excited by the idea and got to work.

The Goals for Nautilus

From the very beginning, we approached Nautilus with three main goals.

1. Nautilus should be interactive and prioritize the most important information about each microservice by displaying it visually. To achieve this, we chose to work with D3.js, a powerful tool for data visualization.

2. Nautilus should protect the proprietary data of all users wanting to visualize their compose instance. This meant that uploading a docker-compose.yml file to a web server was not an option. Fortunately, we found Electron to be the perfect solution. By creating a desktop application, developers could open their compose file rather than upload.

3. Nautilus should have a code base built for scale. We knew that if Nautilus was successful and well received (as it indeed turned out to be), there would be a high possibility that OS Labs would bring in other engineers to work on Nautilus. Thus, we wanted to guard against technical debt from the beginning rather than playing catch-up down the road. For this purpose, we incorporated Typescript. While it meant a bit of on-boarding and more written code, the benefits of static type checking leading to less errors and more maintainable code won us over.

Technical Challenges along The Way

Unexpected technical challenges are par for the course when developing; Nautilus was no exception. The first major technical challenge faced was that by virtue of their relationship to the DOM, React and D3 don't play well together.

D3 interfaces with DOM in a similar way to jQuery--you select DOM elements, which are linked linked with a D3 object and then can use the D3 api to manipulate them. React interacts with the DOM through objects that represent the actual DOM (see the VDOM and React fiber).

Our solution to working with D3 in React was to run all D3 DOM manipulations in the useEffect function which fires after React has updated the actual DOM. This is necessary because if the D3 logical ran in the functional component prior to the return statement, D3 would attempt to manipulate DOM elements that don't exist yet.

This ties into how component lifecycles work in React. To oversimplify, the actual DOM doesn't update until a React function returns a React Element. Thus, placing all D3 functions in useEffect allow them to run after the component is actually rendered on the DOM.

For example, here's an overview of the flow of rendering when Nautilus renders containers:

|--> file gets uploaded
  |--> react component renders d3 container div
    |--> react fires useEffect function
      |--> d3 selects container div
          |--> d3 renders svgs within container div.

While this solved one problem, it lead to another--persisting the D3 simulation across React state changes.

We used the D3 force graph simulation to visualize the Compose instance. We added two views for the services--a depends on view and a networks view.

The depends_on property controls the order in which Compose will start each microservice. If a service such as MyApp depends on another such as AppDb, then Compose will wait to start the MyApp container until the AppDB container is running.

The network property controls what network each service should join. When in a shared network, the services can access each other by the service name on the specified CONTAINER_PORT. By default, Compose puts all services in one network. However, it is common to have multiple networks, such as a backend network and frontend network in a Compose application.

In order to have Nautilus visualize these relationships, the application needed to have a smooth transition from the depends on view to the networks view. We wanted the containers to glide into their new position, rather than removed from the DOM and then re-rendered in their new position.

The issue here is that the variable pointing to the D3 simulation object needed to be outside the useEffect functions. We used two useEffect functions--one controlling the depends on view and on controlling the networks view--and both needed the simulation variable within their scope. But if the simulation variable were to be initialized by React, it would be re-intialized on state changes.

We came up with the solution to create a global namespace that existed "outside" of React containing the d3 nodes, links, and force graph objects. Nautilus calls this d3State. The only time React interacted with d3State was on a file upload where it "set" the d3state. This setting restarts the d3 simulation with the new node values based on the parsed docker-compose.yml file.

To synthesize what's happening here, D3 controls the simulation data and all DOM elements associated with it. React controls what the simulation should be showing by telling D3 what to do with the simulation.

Take for example toggling ports on in Nautilus by clicking the ports button.

Here's what's happening under the hood:

|--> User clicks ports button
  |--> React state updates toggling ports on
    |--> useEffect containing d3 port logic fires
        (this is React telling d3 to show the ports)
      |--> d3 selects container nodes from the DOM
        |--> d3 appends port svgs to containers based on objects in d3State

This way, React and D3 work together to visualize the data instead of fighting for control over the DOM.

What I Learned from Nautilus

Developing an application from scratch is hard. There is a lot that goes into it--designing the UI, always thinking about the end user, setting up the dev environment, building out a code base, figuring out deployment solutions, etc. It's a lot of work and each decision is extra weighty because it will affect the trajectory of the application.

Polishing an application for production, even harder. The Nautilus team built out the MVP fairly quickly, despite the difficulty of building something from scratch. Much of our work was dedicated to that last 20% that makes an application production ready.

It's slow and tedious work where significant changes aren't happening to the application. Finding edge cases, optimizing the code base, interacting with real users, and making small tweaks to UI are necessary parts of the process.

The Future of Nautilus

The Nautilus founders will continue to maintain the application while seeking other opportunities to build cool stuff. We feel that the application has achieved what we wanted and are excited by exploring other opportunities.

Nautilus will continue to grow. OS Labs has offered to bring in another team of software engineers based in NY to continue working on the application. I'm excited about the posssibility that within the next couple of months Nautilus 2.0 should become available for download.

Stay connected by joining our slack, following the Nautilus repo on github, or checking out the website.

I recently spoke with a friend from undergrad, Jared Gorski. We talked about web development, his work at Liferay, my work on Nautilus (a dev tool that visualizes Docker Compose instances). He also started sharing with my how he recently updated his website to improve speed. After our conversation, I checked it out and was inspired. I had already been thinking about SSR (server side rendering) and how to leverage it. Thus, the mission to build this website was born.

Next.js and React

This website is built with Next.js, a complete solution to pre-rendering React for lightning fast serving of static webpages. Next.js comes ready for production with the option of pre-rendering your React website at build time or running a Next.js server that renders the HTML server side on each request. The former being significantly faster and preferred to maximize the benefits of Next.js.

React has a definite sweet spot of use cases. When building an application that relies heavily on dynamic data with each view changing based on the current user, React shines. The ability to write modular, functional, and declarative components is unparalleled in other frameworks, hence the popularity for React over others. But, the trend towards treating React as a silver bullet for modern development is a bit off. A website such as this one which provides the same view for all users doesn't need to push the building of the HTML to the client; enter Next.js.

Server-Side Rendering - An Old Tech Reskinned

The concept of SSR is not new when it comes to web development; Django, Flask/Python, PHP are all about server side rendering. The client requests a webpage, server queries database, server renders HTML based on data and then serves the HTML to the client along with statics assets on subsequent requests. I recently started working on a web application called winebud. It's built with PHP and the folder structure is strikingly similar to Next.js. PHP is server side rendering in it's prime.

So, what's the big deal about Next.js?

Next.js offers the ability to write React while leveraging the benefits of SSR. While it is true that it shines when building an SPA with dynamic data, React is also great because it's just JavaScipt--functional and declarative. It allows for clean code; enforces one way data flow; and enables the creation of reusable components. I could go on, but if you've worked with React you get it. It'd be a bummer to say bye-bye to React when it came time to develop a static website.

With Next.js, you get to build out your static website by writing React. There is some on-boarding that comes with how Next.js handles pages and learning new APIs for fetching dynamic data. But, at the core, it's just React. And so, by extensions, it's just JavaScript.

All that being said, here are my thoughts about the good and the bad.

The Good

1. Time to first paint is lightning fast

Duh. This is the point of per-rendered HTML. Seriously, try it out. Click around my website and notice how quickly the view is rendered.

As previously mentioned, Next.js builds the HTML from your React and then deploys the static HTML into production. Thus, no need to wait for React to build the webpage for you client side; it's already good to go. Next.js even allows for fetching of dynamic data at build time. While this doesn't work great for data this constantly updating, it works great for a site like this. Jdnordstrom really only gets new data when I add a new writing. So, it's easy to have Next.js rebuild and redeploy the all HTML with the updated content.

2. The dev environment requires minimal configuration

No need to mess with Webpack or Babel or server setup. Next.js comes with all of this pre-built. It even comes Typescript ready, which if you haven't used Typescript and benefited from the glories of static type checking... it's the best thing ever and if you aren't using it yet, you should be. I worked with it for the first time on Nautilus and I'm a convert and you should be as well.

Simply yarn (or npm if you're still into that) install next.js create a pages directory, add an index.tsx file and you're on your way.

3. Deployment with Vercel is simple and JAMStack compliant

JAMStack or JavaScript, APIs and Markdown is a philosophy about web development. The idea is that your website is only comprised of these three techs. This is achieved by serving all content from a CDN, serving only static assets and leveraging available APIs to do the heavy lifting work a server would normally do.

Vercel, created by the makers of Next.js, functions as a light weight CI/CD tool that webhooks into your GitHub repo. It builds and deploys the website to a production like environment on all PRs. And then deploys into production on merges into the default branch. It's integrated with Next.js which makes the configuration minimal and a simple solution.

The Bad

1. It's still a React app

What I mean by this is that all of the React files still accompany a Next.js website and these files are comparatively large to the rest of the application. By itself, React weighs in around 106kb. This is large by comparison--the HTML for the home page here is a measly 6.26kb and uses minimal CSS and JavaScript (not accounting for the React ecosystem). What this means is that this website would be significantly faster without React and Next.js.

Most static websites don't need React running in the background. While this does come with certain benefits, it still feels a bit too heavy for the simplicity of many static webpages (this one being a prime example).

2. Time to interactivity still "slow"

I want to caveat this by saying that "slow" is a relative term; we're talking about milliseconds here. But in web development, the faster the website the better UX, which means higher returning user rater, which means greater profit.

The time to first paint is lightning fast because of the pre-rendering powers of Next.js. Yet as mentioned in the point above, the JavaScript file is large. This means the time to webpage responsiveness is the same speed as a React site. While the time to first paint is a huge benefit, Next.js only goes halfway in boosting the speed of your webpage.

And we're back to the fact that writing in plain JavaScript, HTML and CSS will be the fastest when it comes to a static site. This leads to a question of whether or not these negatives out weight the benefits of developing in React. Vanilla web development is a lot of copy and pasting. React improves the dev environment so much so that it's a worthy trade-off.

A Quick Note about Design

Minimal and old school internet modernized are the design goals for this website. In order to achieve this, the two step process of designing and then implementing were a growth inducing challenge.

Graphic design is a whole field of expertise that I've only dabbled in as an amateur. I usually design by starting out with a vision and then changing it based on what looks good once I see it. But, envisioning and then implementing in CSS at the same time is laborious. Ideally, I'd learn adobe one day.

CSS is easy to learn, but difficult to master. In the past, I've turned to styling libraries such as Bootstrap and Material UI to make CSS less scary. But, I felt these libraries stunting my growth as a frontend developer. This website is all home-brew CSS. Here's what I learned: there's a lot that can be achieved with CSS sans JavaScript and the transition property is hard.

Final Thoughts

This website was a journey in exploring the new (or rather the reskinned) technology of server-side rendering and a study on static website optimization. I learned a lot as a software engineer, had fun, and am proud of the end product. Programming excites me. I am constantly iterating upon projects and expanding my sphere of knowledge. jdnordstrom.com will continue to evolve as I evolve as a software engineer.

P.S. If you want to see the magic that makes it happen, here's this (the website's github repo).