The creation of my portfolio has been long overdue. I have made several attempts over the past few years, and for a variety of reasons, it’s taken me this long. The current iteration you’re seeing right now uses a Hugo (a static site generator) and a theme I designed.

My first portfolio attempt

I built an entire content management webapp starting from graphic design, frontend, backend, and everything in-between. I utilized Django REST Framework and ReactJS. It had a lot of features, like an admin panel, a customized WYSIWYG editor using Slate.js (which was a joy to use), drafting support, and autosave. At some point I might write some articles since there were some interesting backend classes I wrote.

One very large bug…

However, while I was working on the drafting feature on the frontend, I ran into a major design flaw with how I managed state. I developed a custom form renderer (EzForm) which made displaying forms really easy. All I had to do was configure the form with a Javascript object and all the fields would be styled exactly the way I wanted.

However, I improperly structured state handling within EzForm. It appeared to work with a standard React component where the only state update occured on the page load (to load any pre-populated data). Issues became apparent when I was building draft functionality. The backend successfully passed all the tests, and I thought the implementation was pretty elegant. All I had to do to make a model “draftable” was inherit a class. On the frontend, in theory, all I had to do was update the state of EzForm to switch between drafts.

Why a custom CMS is a mistake

Once I began to wrap my head around the problem, I knew it wouldn’t have an easy fix. I would have to completely re-work EzForm. This made me aware of a very unfortunate truth. I worked on this website for an entire summer, but I didn’t stop to think if doing a full-stack portfolio website was a good idea. It was a massive flex for sure, but would it really be worth it?

What I originally saw as a benefit and demonstration of my skill, building a full stack portfolio with a custom CMS, was in reality a stupid idea. If there were any issues that arose, bugs, problems in the deployment, someone hacking the site, I would be the one to fix it. There would be no tech support to call. Who knows how many hours of additional commitment maintaining the site would require. I built an entire service for only one person to use.

Despite the amount of web development experience I have, I do not want to pursue this as a career. Maybe maintaining a service would be a good exercise for someone else, but for someone who enjoys tinkering with hardware, it was a distraction from what was important to me.

Learning from my mistakes

After a long hiatus from working on my portfolio, I decided to take another crack at it. When I worked on the NASA BIG Idea Challenge, it became immediately clear how important it was that I document, and show off, all that I learned. This experience would only happen once in my entire lifetime, and I had no platform where I could share it.

I had a few key motivations for building the site.

1. Show off my design sense
2. Have a home for all my projects
3. Easily create logs as I make progress in my work
4. Have a home for my blog

Projects versus Journeys

One of the key distinctions I made with my site is the idea of a “journey”. I feel that projects are a general term that have a connotation of professional development, something you put on a resume. Meanwhile, a journey is something that occurs in the moment and can apply to any aspect of life. With my site, I wanted to showcase my projects as well as my hobbies and interests.

I have a lot of ideas on how to “show the journey” as its happening. But, I figured starting small and building the site to fit my needs than what I think I need is a better start.