Spending time on things that matter

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.

1. For  example when I was getting good at Angular 1, the Google team decided  to start from scratch, with completely new syntax and a new learning  curve. Now on its 8th version, I hope that thing dies for good.  “Superheroic Framework”, my ass! ^[return]
2. Setting  up a web server, configuring HTTPS with Let’s Encrypt, configuring TLS  parameters, increasing security with a robust set of security headers,  etc. ^[return]
3. I refuse to use Serverless here. ^[return]