2020 was something else. We can all agree on that. Most of us worked remotely. The tech industry is currently thriving. A lot of people have lost their jobs around the world. We’ve all limited our social contacts and kept distance to other people.
It was a stressful year, no doubt. I’m glad it’s behind us even though this situation hasn’t gotten any better. Now I can take a minute and reflect on what I did or accomplished during 2020. I didn’t have any specific goals or milestones. I simply did a lot of stuff which I felt like I could benefit from, in the future.
So, once again I’m listing some highlights from 2020.
My toolbox got bigger
In my previous blog post I talked about a toolbox we developers often keep. It’s filled with our favorite toys. Programming languages, libraries, frameworks, proprietary software etc. Often when I start a new project I look at my toolbox and pick up a few toys I think would be perfect for this project.
This year I mostly grew my front-end compartment. I tried Gatsby, Next.js, Nuxt.js, both React and Vue.js on multiple successful projects, and various packages for those two frameworks. I tried different CSS frameworks like Tailwind CSS, and UI component libraries such as Bootstrap (funny enough, I never used Bootstrap much before), Material UI, Semantic UI… But I also explored more into Node.js in a sense where I developed multiple severless solutions using AWS Lambda or built API’s using Express.js. And Docker. I used Docker on multiple projects.
The thing I learned with these was that you may seem cool just because your toolbox is big, but unless you can really profit out of it, it’s best to advertise only the toys you like most. As 2020 got further I started to notice that jumping between React and Vue.js, different state management solutions and other packages, I spent hours on each project just reading through documentation. I kept forgetting how I can set up a Redux store, or add a middleware to Nuxt.js or what kind of API some component has. The time I spent on just shifting through docs started to bother me.
The reason I kept jumping between React and Vue.js so much was simply because often projects I got hired for involved other developers, who preferred one or the other. Frameworks I could almost always pick myself, so I tried a few of them to determine which I could stick with. They all work great, but some might involve more work than others.
Prioritization
When working on multiple projects simultaneously, I started to prioritize work more. Even now I have a list of four separate projects listed on my whiteboard, and a todo list for each one. I prioritize work on the highest ranked projects and if I get those done, I move to the next one on the list. The bottom project is often some personal application or platform I’m building.
Prioritization is pretty basic stuff, but I’m a person who will begin to procrastinate, if I get overwhelmed with different things I should do. Writing all of them down on a list and marking them off one by one helps avoid this.
Todo list
This was something I kept changing throughout the year. I tried to be cool and just use a notebook and pen, then I tried using post-it notes, but both of these fell short when you don’t have access to them unless you carry those on your at all times.
So, going digital I’ve tried different platforms for this; Microsoft’s Todo, Microsoft OneNote, Trello, Notion… I finally landed with Notion as it was really fast, simple to use, worked on multiple devices with ease and you can use it for notes, documentation and todo lists. It’s now one of my favorite tools.
Prototyping
I really got value out of prototyping solutions and design this year. I could quickly showcase ideas for customers and we could iterate them on a rapid pace. It helps you not commit too much and helps innovation. You can use it both for design and development.
Don’t spend too much time up front on software design
I’ve mentioned before that I started to rewrite Xerberus (my pet project) last year and I still haven’t gotten very far. I’ve been swamped with other work, but I also noticed that I spent a considerable amount of time (around 6 months) thinking about the up front design instead of just jumping on to implement it. I finally managed to put together some code late last year that fits nicely with the idea of using domain driven design (DDD) while using Doctrine ORM and GraphQL.
This week I happened to stumble on an interview on YouTube (YT), where Simon Brown & Stefan Tilkov (both of which I had watched on YT before) talk about architecture before coding. You can check it through here. I found it quite an interesting talk that also covers how too much up front design can be bad.
Based on what I learned through my own experiences, further strengthened by what Simon and Stefan discuss on the video, architecture evolves as you develop your software. Doing too much up front design will only further highlight the mistakes you made with the design later on, or it will end up hurting development, or product.
Docker replaced a bunch of stuff for me
Up until last year I used to develop websites and other web related solutions using WAMP on my Windows machine, or Apache, MySQL and PHP on my Macbook. Last year, as I had to reinstall my Macbook and my PC, I decided that I won’t be installing those packages anymore. Docker should suffice. And it did.
Docker offers all the tools you need to develop your software without the need to install a database engine on your own machine. I now use Docker for every development project where I need a runtime and a database. It doesn’t take you much time to write your docker-compose.yml file which consists of maybe PHP, PostgreSQL and Node.js to run your tech stack. This comes in really handy.
I shifted to API first approach
Most of the websites, or applications, I now build are API first. Before 2020 I mostly completed websites using some type of templating solution offered by a framework, or by a CMS. That changed after I introduced myself properly to React and Vue.js.
I started to dig in more to Wordpress and how to use it as a REST API. From there I started looking for other CMS solutions which only work as an API and came across Strapi, which I found amazing. Contentful was also one platform that I used on a personal project, which is an API-first development platform.
This has improved my API design skills tremendously and helped me develop flexible front-end solutions with modern frameworks, quite quickly.
Final words
I also learned the importance of using metrics and in general monitoring your application for errors and status. There are plenty of tools out there to do this and utilizing them gives you visibility to your production apps. I’ve built dashboards on both Azure and AWS which help me monitor those resources. Throw in a few alerts for some metrics and you got yourself a good start in regards of visibility.