Public Learning

project-centric learning for becoming a software engineer

Final Recap

Turning Frogs Into Princes, One Line Of CSS At A Time

Feedback for the 200 OK website and configuration interface had been mildly positive to neutral (“spinach green” being the most negative, “simple and functional” the most commonly used description). But nothing is more damning than faint praise and I was growing weary of the green-colored looks as well. Plus, I was still missing a proper landing page anyway. My initial idea of just sticking a single button on the page was neat, but ultimately didn’t reflect the power of 200 OK’s administrative features anymore. Plus, if I want to make a good impression with what’s very likely one of the only things a future employer is really going to see, I needed a website that appeared a bit more professional.

I am unfortunately not a designer, but I have a few strong opinions on typography thanks to ten years of typesetting books. So my goal was to not overdo it with graphical fidelity but instead rely on a careful font choice and some fitting color scheme (see the end result here).
Even more unfortunately, I am also not a good web designer, thus I was properly challenged with all the necessary custom CSS and Bulma configuration to make all the white space and margins and paddings to my liking. I also revamped the main logo that so far has only been a bunch of almost haphazardly styled text. Again, whenever I tried to integrate an actual graphical element (like a gear or some other piece of machinery that has a symbolic meaning related to APIs) I was very unhappy with the result, therefore I settled on a simple text and a box style that could also represent a UI element for some HTTP request tool, displaying the eponymous status code for your request was successful.

During the logo experimentation phase I also chose the two primary colors and hence got rid of the boring old green. Once both the logo and the color scheme were fixed, the rest of the landing page layout kind of fell into place. It was still a long, iterative process, but I had a picture in mind that I could simply try and bring to life and it turns out that it exudes that hip SaaS startup vibe that I was aiming for. There is the big call to action button, the stylized image of something vaguely related to the product, the three-column feature list with artsy iconography - I like it. Plus, thanks to Bulma’s magic, retaining the snappy responsiveness was really easy. Though I am bit disturbed by the size of the main stylesheet file (got to reduce it somehow in the next few days), Bulma has been a joy to work with.

Why Waste Time Say Lot Word?

Another mountain to climb concerned the writing of many words. There were two todo items looming on the horizon as soon as the project was mostly done:

  1. A user documentation. I have suffered through many incomplete, outdated or just badly written docs over the last month, and similarly I have marvelled at some pretty good docs, so I knew that I would like to be categorized under the latter.
  2. A technical case study. The importance of good document laying out the technical challenges that were overcome during the project’s development can not be overstated. That is what literally every single person who got out of Launch School and found their first job has told me, so I am not going to doubt it.

Writing documentation for your own project is hard, because you already know all the intricacies of how to use it, and it can be hard to see things from the perspective of someone thinking Well, what is this 200 OK thing? However, the importance of technical writing can not be overstated and that’s why I have spent a rather large amount of time on a proper guide on how to use 200 OK.

Clocking in at roughly 3,000 words, the documentation is basically done, but it still lives in a markdown file that I now have to properly convert into HTML with a nice table of contents. That is what I am currently working on, after that comes the case study. For that, I can thankfully draw from all the weekly recaps I have written since they contain almost any problem I have encountered, failed at and ultimately solved.

Failing Forward

When I was reading my old blog posts over the weekend, I realized that I have made so many mistakes, it’s astonishing that 200 OK still arrived at a state where it is doing what it is supposed to do. Reflecting on the last five months, I have ultimately come to peace with what, for a long time, I considered a bad overall experience: a good software engineer seems to just be someone who has failed many, many times, but learned from each of those mistakes. This failing forward experience is how I would best describe my development process.

It has left me with quite a few phases of intense frustration because it is only in hindsight that the path to a working solution for some particular problem becomes clear. Especially without anyone else whose brain I could pick, the iterative process of slowly converging towards an impelementation that satisfies the requirements (both in a working as intended way as well as in keeping it maintainable should a need for change arise) can take a while for a novice programmer like me. Still, this was to be expected as I was dealing with a problem space completely new to me.

I am probably going to reflect a bit more on the last five months in a separate post. Depending on the result of my job search, my final judgement on whether it was worth it might change. Until then, the 20+ posts I made during that time can stand on their own.