Yesterday I read an amazing post by Mateusz Charytoniuk giving some beautiful advises to junior developers. I already had an idea of writing something about my first full-year career as a developer, but his writeup made me reconsider everything I wanted to talk about.

Who am I?

Formally I am only a photographer (with degree and all in that topic) with a small passion for hardware and software development, that came from the days of hosting Counter Strike 1.6/Source servers for my friends and me.

10 years ago, with the help of my parents, we started a small company that provided services like Media Creation (for advertising and social platforms) as well as Web Development (with the main focus to distribute those media that we created). This forced myself to learn at least the basics in every aspect of each production, service, workflow and development our company was involved.

Since I'm an insanely curious person this turned out to be an insanely easy task. Yet, I wasn't understanding a major flaw in this process.

How I messed up

As we all know, time is the most valuable thing.
It is one of those resources that most quickly runs out. It is how you calculate salaries, how you build promises for your clients and how you manage your employees, collaborators and tasks to do.

But if I made my employee/collaborator spend time explaining to me what they were doing, so that I could better understand and judge the client's request, that meant I was in fact wasting production time. And that's a cost.

Without a doubt, if I was an employee somewhere else and did not have any other fruitful aspects, I would have found myself fired. Because that would be something I would do.

Slowing down

As time went by I started realizing my crucial mistake. The fastest action I could take was to separate the learning process from the production one, while keeping them aligned.

Lets say a particular run in a project required a full rewrite of a backend, to provide internationalization support for newsletters: Do I know how to code it?

• No: I would write down everything I know that could be required for such task.
• Yes: well great! Lets create a small PoC (Proof of Concept).

Either way, it was only as a personal challenge to myself. Then once that work was done by the assignees, I would compare their amazing work to my garbage. If I had questions, I would have asked them outside of production time, but only if they wanted to answer.

At some point you'll find yourself structuring/coding things that start to be comparable to those others that you are comparing with. And here, IMHO, is where you should go after bigger targets.

Your most demanding Client

This is something I only realized in recent two years, mainly when I started having to cut down on maintenance costs for smaller projects (backstory: switching from PHP to NodeJS for those smaller PoC and MVPs (Minimum Viable Products)). As usual, I started taking notes about what I needed to go after to solve this issue, but the more I tried to make things clearer, the more what if a client asks ____? type of questions dominated.

I found myself everchanging plans to an everchanging hypothetical client. Forcing myself to increase quantity over quality (to adapt to all hypothesis), realizing that things would have only gone worst and drastically lowering my product's and production quality.

I needed an actual client. One that cared about quality, costs and optimizations. One that provided realistic deadlines but also didn't have time to waste. One that understood the importance of maintainability of workflows and code, as well as adaptability while preventing full commitments. One where if a particular project failed miserably, it wouldn't create repercussions. And there, is where I realized that THAT Client had to be myself.

Switching gears

I never been a developer, as much it has been a passion of mine I only coded once or twice a year and only for personal stuff. But since I was in the need to do some tests with JS Frameworks I had to start from somewhere.

Don't get me wrong, having access to countless years and years worth of content as tutorials, courses and such, with many being freely available, is a great thing! But as I learned from my photography background, watching countless hours on YouTube won't get you better at landing a contract nor making sure I won't fail.

So I sat down with that precious, most demanding, Client I've recently discovered and started selecting together which JavaScript Framework to pick. The choice wasn't lead by the Client itself but by me: that ideal developer that once the Framework was chosen there was no going back, you cannot maintain multiple projects in multiple Frameworks when you are busy learning and working. But since I had no programming skills I had to pick it by other factors: Docs and open Issues.

Weeks went by, fully reading at least once each Framework's Documentation, not understanding a single word. In the end, I found the one that mostly suited my style of thinking and approaching things, while taking into account all those additional requirements imposed by my Client. I was happy, but I knew I needed a realistic challenge.

A full year

That's it: I had the will to learn, I had a Client and now I had a Framework. What do I do? I start a full year of learning and building stuff. At first it didn't matter what I built (not really, only the first week or two has been like that. Soon after I started working on actual work we were missing).

The point is, I wanted to spent at least three hours each day doing something related to this: either studying other people's work, mostly from maintainers of the Framework I chose (you know, if you want to learn something, why not start from those that actually created it, right?) or by writing my own code. In the end I spent way more than 3 hours each day, but I had the luck of being able to do so. To track my progress I wanted to use my own profile on GitHub, via the Contribution Calendar.

(for those who don't know what this is: the calendar below shows the days of activity of a particular developer on GitHub, the more green the more active. But also my goal was that if a day remained gray I had to at least studied something)

Exactly one year ago is when I started. Currently I don't have a way to tell at what point I'm at now, what I know is that I'm mostly where I would like myself to be: with a good understanding of the tools I want/need to use and a great reproducibility and confidence in handling myself. Not only those countless failures and bugs I've encountered at some point were fixed by me, but I also managed to meet lots of great (and some not-so-great) people in the Open Source Community. Following many of them, but also having the pleasure to get followed back.

Using myself as the one that I had to confront with turned out to be a great idea.