2019 seems to be on its well on its way to become one of the most pivotal years of my life. This post outlines some recent thoughts about efficiency.

Reflecting on some negative results

In recent attempts to make one of those typical “2018 in review” posts, I’ve realized that despite having several ideas for projects and some of them being somewhat simple to implement, I didn’t ship anything besides my thesis last year 😐
It’s important to reflect on what you think went wrong, and this is how I generally come to terms with things that need to change. My situation is somewhat worse than if I’d just wanted to take my free time to do other things, because I actually sat down and tried to do some of my projects. I ended up with several unfinished proofs of concept which will likely never get shipped and that makes me feel bad. I know that this is widely accepted in the developer community, like hoarding domain names for cool projects you’re never going to have the time to implement and so on… But I don’t want that to be a thing for me. Every project I put time and effort into that doesn’t see the light of day is a failure in more than one aspect: I feel bad for not completing it, internally attribute it to my lack of skill or speed to get things done and it’s just a nasty bundle of feelings that I want to avoid. Instead of feeling like a complete idiot, I give myself some slack (I take some of the blame too) and I thought long and hard about what keeps me from shipping things, and I came up with several answers for that:

Perfectionism

This is one of the fallacies that has long existed in my mind. If I put something out there for the world to see, it needs to be perfect. And not just from the user’s perspective, every little component that lives inside it needs to be perfect as well. Everything needs to easily scale, not have bottlenecks, etc.
This is the quintessential problem that I fear is present in a lot of my work: I look at something simple, and indulge in making it unnecessarily complex by making sure I architect it in a way that can handle thousands if not millions of users. I have tens of pretty architecture drawings of projects I wanted to build that have never been implemented given the sheer complexity of what I design… It’s unfeasible for a single person to bring it to life, and herein lies the issue.
I need to properly managing the scope of my hobby projects going forward, limiting their scalability by design so that I can bring them to life myself. It’s also perfectly reasonable to just stick with architecting things if that’s what you enjoy, but since it pains me to have a bunch of unfinished ideas this is a decision that must be upheld.

Digging deeper into it, I found that perfectionism is often times an excuse for procrastination. It wasn’t easy to admit, but it makes complete sense. Most projects I have not followed through are either because I lost interest along the way (which for me is a valid excuse not to invest more time in it), or because it is taking too long for me to come up with something manageable to implement on my own.

Finally there is also the topic of enjoying yourself. People get pet projects for multiple reasons, one of which is building a portfolio. I argue that it is always wise to choose projects you enjoy rather than taking on something challenging just because of the complexity itself. I always choose something that excites me as a hobby, but introspection has allowed me to see that on several occasions, ideas that were selected for hobby projects start out as fun and motivating and end up challenging, hard to materialize, and distant from the initial vision. And yes, you guessed it right, it’s all thanks to “perfectionism”.

Realizing this has changed the way I look at myself and others alike. It seems that real life is filled with compromise (shocking, I know), and that’s OK. It doesn’t actually matter that you designed a spec for a system capable of handling incredible load, achievement and happiness come from the things that you were able to bring to life.

Inertia

Getting comfortable is a cardinal sin in the IT industry. There is a constant need to adapt to the current best practices and people need to be open minded about learning new concepts if it makes them more productive. On the other hand, there is an unspoken feeling of hopelessness when you finally get good at something (e.g. a popular framework) only to find out that it will be unwise to continue using it (e.g. maybe some big corporation stopped supporting your framework¹).
You might be able to use a single language or framework for your entire career, but today I find that unlikely, as more and more options present themselves. Soon enough a new status quo emerges where it is established that Language 1 is good for developing CLI applications, you should use Language 2 for web development and Language 3 is the hot new thing for writing high performance code. Fill the blanks in as you see fit.

Don’t read me wrong, I think inertia is important. Let me drop some commit strip knowledge here:

While specific to the JavaSript world, I think this is also a great insight about recent language trends. In a sea of possible choices there are, of course, promising options, but inertia stops us from being the sheep depicted above. But now we’re faced with a dichotomy between “keeping up to date” which seems terribly chaotic, or double down on our own areas of expertise, risking becoming less relevant over time and vulnerable to stagnation.

I’m a firm believer that you can be a jack-of-all-trades, but you need to master a small set of tools or languages in order to secure a meaningful job. For any particular task you need to be able to quickly come up with a reasonable solution. Languages come and go and you can switch the tools you decide to master over time, but at any given moment you need to be able to work fast on problems relevant to your industry.

My point with this is that we need to strike a balance somehow. To keep sane, we should avoid keeping up to date with the tools and languages du jour while keeping in touch with others that might venture into new territory. Engaging with the community thus seems like the best option, since you can, on your own availability and time, read about new and exciting technologies from people actually using them, taking their feedback into consideration and weighing in the cost of learning new tools with the expected benefit.

Old Habits

Sometimes we do things in a particular way because that’s how we always did them. It becomes a sort of ritual or tradition to do it in the way we do it, and these types of habits tend to be hard to kill. Sounds strange…? I’ll give you an example.

I’m renting a VPS for a few years now. I’ve been about 1.5 years on DigitalOcean and now I’m in a more traditional VPS in order to get a better deal. I’ve learned countless things that I would not have otherwise learned without this server², but I’ve also grown into accepting that things just work that way. I get bored before I post a new blog entry because I know it means I have to SSH in and sync the changes. I need to go in occasionally and do software updates and maintenance. This is one of the old habits, but I’m sure there are more.

For example, do you still use a default installation of bash despite knowing that zsh with the “Oh My Zsh” framework would make you incredibly faster? Maybe this is the wrong question to ask you, but perhaps when reading this you can remember your own habits that need replacing… 😉

This is probably the hardest category to fix when analyzing your own behavior, because you only realize an old habit is obsolete when you know there is a better way to do things. So how do you find out better ways to do things? I have an answer, but you can probably find alternative ways.
The idea is to look out for conference talks related with new paradigms of doing things. Think AWS re:Invent, or other conferences focusing on operational aspects or developer tools. I watch videos of other conferences, and I was shocked at how good and thought provoking these two talks were:

• Monica Dinculescu on Bet you Didn’t Think Your Browser Could Do That
• Sarah Drasner on Serverless Functions and Vue.js

In them, both speakers go into the details of building applications with Lambda functions³ and a front-end framework. Since FaaS is a newer paradigm, I think not many people are exploring the possibilities, and I was very impressed with what you can do with this new type of application architecture. It gives you a platform to run code on managed infrastructure without compromising scalability.
Of course, usability is a bit limited, and FaaS is not a panacea, but it’s undoubtedly something that will remove a significant amount of friction from application development, and that will enable developers to become more productive. In Sarah’s talk, she shows several examples on how to build a sort of e-commerce application with a payment gateway, something I’m fairly certain would freak out many developers when developing for a traditional hosting platform.

So what do I actually need to change?

This is something specific to the issues I’ve identified in my workflow, so perhaps they aren’t as relevant to you. It should be fairly trivial to identify what needs changing after you’re presented a much better way of doing things you do on a regular basis.

From watching the above talks I became aware of Netlify, a company whose business model is deploying your application for you. They integrate with GitHub, so you can have a build script taking every new commit to a specific branch and deploying it somewhere. You can add your own domains. You can integrate with identity management tools and other amazing plugins that allow you to build surprisingly complex applications without managing a single server. I did some math about the amount of time I spent managing my server in relation to the time I have to work on hobbies, and I’m fairly confident that this sudden change in paradigm is going to be revolutionary for me. And I welcome it.

Pushing forwards

The idea behind moving to managed infrastructure isn’t particularly new, it’s just that it used to be prohibitively expensive. I did some napkin math and once I move over to something like AWS CloudFront or Netlify I should be able to save about $100 per year, which is pretty neat.

The idea that a newer development workflow not only saves time but is also cheaper is almost hard to understand. I think the cost of FaaS might rise once enough people are using it, but I hope not 🤞

Afterthoughts

I’ve noticed that this entry might suggest that I’m now fascinated with the whole FaaS paradigm and that I advocate we should move everything to functions. This wasn’t my intention; instead I wanted to raise awareness for a valid and viable alternative to today’s standard practices.
Moreover, sometimes transitioning to a managed service can be a bad move. For instance, I’ve used Medium but have since moved back to hosting my own blog. When I started writing on Medium, they promised a free model for readers, but that has since degenerated into allowing 5 blog reads per month to non paying users. This means it won’t be my platform of choice, since it hurts many other writers I hold in high regard – people that trusted Medium when moving from Blogger or other legacy blogging software and then got their content behind a paywall against their will.