10 Years as a Software Developer
In July of 2011, I finished my degree in computer science and got my first job. That was 10 years ago.
Today, I want to look back and share some of the lessons I've learned.
A Brief History of Me
Before I start talking about what I learned, I will review the journey that got me here. If you don't care about any of this, feel free to skip to the next part.
Before the beginning
Before I knew anything about programming, I wanted to be a graphic designer. My programming experience going into university was completely non-existent. I knew so little, in fact, that I didn't even know what I was getting myself into.
What I knew was that I liked mathematics and computers more than I liked the subjects I saw on the curriculum for an art degree. So I figured (wrongly) that if I studied computer science, I would learn Photoshop in some of the subjects.
I realize how stupid that sounds, but to my 18 year old self this made perfect sense. In high school, all the subjects I had taken related with computers had been all about teaching us how to use programs like Microsoft Word or AutoCAD. So in my mind, doing a career about it would just mean learning how to use more programs.
In the end, however, it turned out for the better because I love programming!
2011: Getting started
It was 2011, and I was 21. I had completed my bachelor's degree in 3 years, so my academic experience was rather short. I could have done a couple more years to get a full degree, but this time I understood the curriculum and I decided that I wanted to do something else. I had fallen in love with algorithms, but I was still very much interested in graphics. So I found the perfect follow-up, I started a masters degree in Artificial Intelligence and Computer Vision.
But there was something else nagging at me. I was enjoying the student life and working on my assignments, but I craved real-life experience. I had heard about entrepreneurship, and the concept was extremely appealing to me (even though, like with the CS degree, I knew nothing about it). As these things go, turns out that a friend of mine was starting an entrepreneurial endeavor and offered me to join them part-time. That's how I got my first job at Ilurus. Later on we started working on a different project called Veziko.
It was at this time that I started to follow others' work online. Probably the first developer I ever followed (and still do!) was Jeffrey Way, who taught me about CodeIgniter. This also meant I started learning about The Web, which I had seen close to nothing in university.
I also started listening to podcasts, and the first one was Entrepreneur on Fire. I don't listen to this one anymore, and my idea of entrepreneurship has changed a lot since (at the time, I saw entrepreneurship as a synonym with Silicon Valley and the VC unicorn madness). But this period definitely set the pillars for my ideals today, and I started to understand what this entrepreneurship thing was about.
But then, 2012 happened.
2012: Seizing the opportunity
In the summer of 2012, another friend reached out to me with an opportunity to work at an international company called Toro. It was a french-founded asian company, headquartered in Taiwan, with plans to open a new office in Barcelona the following year. They were hiring 10 developers to participate in a 5 months training program in Taiwan, who would then come back to inaugurate the Barcelona office in January 2013.
On the one hand, I still enjoyed learning about the entrepreneurship scene, and to this day I still look back at my days at Veziko as one of my dearest professional experiences. But I thought things were moving too slow, so I still craved that real-life experience. Now I understand that things take time, but I was young and ignorant then. And as much as I was enjoying the master degree, it was still purely academical.
On the other hand, Toro was already in business, I would gain international experience, and they were working with mobile technologies — which I knew were going to become the future (I knew because a teacher told me, I wasn't that insightful).
So it wasn't an easy decision to make, but in the end I decided to seize the opportunity (this was my first blog post ever, and yes, I also cringe reading it).
After the 5 months adventure in Taiwan, things were relatively stable. In January 2013 we opened the Barcelona office. As destiny would have it, I managed to continue pursuing my interests in graphics and UI. Most of my work at this company revolved around creating a UI engine for J2ME-like applications. I say J2ME-like because applications were written using J2ME, but they run on top of a cross-platform virtual machine. One of the challenges, then, was to replicate native components as much as possible. This seemed crazy at the time, but today we have Flutter which is kind of doing the same, so maybe it wasn't so crazy after all. Other than UI, I also got some experience working with assembler code and virtual machines. To this day, this has been my most technically intensive role. I even tutored a thesis on true-type font rendering, believe it or not.
I worked at Toro for two years, and I learned a lot given that this was my first "real job". But I still hadn't been cured of the bug of entrepreneurship, so in the summer of 2014 I decided to quit.
2014: Entrepreneurship
If Veziko had been pure entrepreneurship, Toro was my first experience working in a corporate environment. It still had a startup vibe, but there was definitely a lot more bureaucracy. So I still yearned to do things my own way, and I wanted to experience working in the full stack. Not "full stack" as in development stack, but the full product stack. I wanted to take an idea from inception to reality and experience all that goes with it.
Years before, I told myself that even though I was getting a job, my primary goal was still to learn. And it would be until I was 25 years old. I was 24 when I quit Toro, and I had some savings. That's why I decided this would be my best chance to do entrepreneurship. Even if it didn't pan out, I would learn a lot.
Now, the problem was that I wanted to do "something", but I didn't know what! Yes, that's the text book definition of a wantrepreneur. Struggling with this is how I came up with posts like In the search of value.
But that situation wasn't so bad, because it gave me the chance to experiment and follow my curiosity. In this period, I planted the seeds for some of the things that I value the most today. For example, I created this website. It was also during this time that I really started getting into web development, and fell in love with Laravel.
I decided to release my products under a brand. That's how I came up with Lincoln's Chilli, which I called my "entrepreneurial sandbox". Most of the projects I started are discontinued now, but one of them survives: Quick Pick. This was actually the first product I ever made, and it embodies that notion of doing everything myself. It's 100% hand-crafted. I got some help from my girlfriend who sketched the characters in paper, which I then digitized and colored for the game. Even the music you hear is actually me playing the guitar! (don't get too excited though, it's a silly tune).
In parallel with doing my own thing, I also collaborated with a friend for something more ambitious. Actually, if I have to be honest, it was too ambitious. We created an online turn-based card game for mobile phones. You can think about it like a mix between Magic the Gathering and Chess. And we weren't shy on features. I implemented from scratch: a leveling system, a backend to manage the library of cards, a custom protocol to synchronize (and replay) actions across devices, bots with different difficulties, an interactive tutorial, etc.
I would agree if you say that it was a bit overengineered. However, working on this project was extremely fun and insightful. We also collaborated with illustrators and sound designers, so it wasn't just about programming. The game is no longer available, but you can find some screenshots – and an APK to play offline – in the projects page.
So, for two years, I had been working on my own projects full-time. But let's talk numbers. Do you know how much money I made? 0€. Yes, that's not a typo: 0, zero, nothing. And it wasn't because I didn't monetize my products; the card game launched with in-app purchases, and my latest product wasn't free to use. I even had ads on my second product, but it made almost nothing so I didn't bother cashing out.
The critical mistake I made was always the same: launching to crickets. I learned, the hard-way, that it doesn't matter how good your product is. If you are not solving a real problem, it will not work. And marketing is also very important, something I did almost none of. Not to mention time, there is no such thing as an overnight success, and most of my projects were finished at launch. I'm not saying that my products were great either, but I learned this because it didn't matter how much effort I put into a project, the response was always the same: crickets.
So I won't try to sugar coat it, let's call it what it was: failure.
But if I'm honest, I don't regret a minute of it. I mentioned how my main goal was to learn, and I had definitely done that. There is a valley of difference between doing something as an employee and doing it for yourself.
And just when I was about to start looking for a job and leave aside this entrepreneurial pipe dream... I co-founded a startup.
2016: Startup life
After spending a couple of years trying to push my ideas into the market, which doesn't work, I was ready to go back to a stable job. But before I even applied anywhere, I got a new opportunity. Yet another friend had rented an office in a scientific park in my home town. And the person renting the office next door had just launched their idea and was looking for a technical co-founder.
The vision was to give people access to sport facilities without paying subscription nor registration, just paying for their use in minutes. There was a gym across the street, and they had already run a pilot with good results. The name of the project was Geemba.
The prospects were really good: the location was great, there was a technical challenge, and the business idea resonated with me. But not everything was sunshine and roses. My savings were running out, and taking this kind of position wouldn't guarantee a stable income for a while. What's worse, I had to invest money in order to found the company. And I was 26! So the learning excuse was out.
But I really wanted to do it, so I decided to join with a couple of conditions. We opted for a government-backed loan called Enisa. If that was granted, together with our own money, we had a financial runway of about a year without relying on external investment. I had to ask for a personal loan to cover my part, but I would get it back with a (very low) salary and doing some freelancing on the side.
So that's how I managed to kick it up a notch and became the "CTO" of a startup. I put that in quotes because it's ridiculous to call anyone CTO for a two-person company. But that's how things go in the entrepreneurship scene.
The next year and a half was great. It was bittersweet having to freelance to get out of debt, but I wouldn't have changed it for the world. We ended up hiring some part-time employees, and because we were located next to a university we also had a couple of students doing internships. I even did some presentations in the university and joined as part of the jury for a couple of master theses.
On the product side, I was very happy with the solution we came up with. Customers would download the mobile app, introduce payment details, and request access before arriving at the gym. Once they got there, the receptionist would accept the request from their private dashboard and let them in. At that point, the timer started counting. When they left, the receptionist ended their session and we charged them for the exact amount of minutes they had spent inside the facilities.
On the technical side, I also learned a lot. I started using Vue, another one of my core technologies today. As you can imagine, building all the moving pieces was not trivial (the app, the backend, the receptionist's dashboard, etc.). To top it off, everything had to work in real time and payments were involved! Thank God that Stripe already existed. Fortunately, we never had any serious technical issues.
But if you're reading this, you know it didn't end well. Customers loved the idea, but finding gyms willing to do it was a different story. Many of them actually thought this was a threat to their business model, because they depended so much on customers paying subscriptions (even if they didn't attend the facilities, does that ring a bell?).
We started with this idea of "gym by hours", but we slowly began catering more to the gym's needs: we built a CRM for all their customers (not just the ones using our app), we created an editor to make personal training plans, etc. Eventually, we started to run out of money and our only option was to seek external investment. I'm happy to say we didn't even try, we didn't waste a single minute on that.
A year and a half before, we set out to validate the idea. After having given it our all, we decided that this was it for us. Could it have worked if we kept grinding? Sure. Could we have done it better? Absolutely. Do I regret quitting or even trying? Nope.
If you're curious, you can also learn more about Geemba in the projects page.
So after almost 4 years working on my own projects full-time, I went back to the workforce.
2018: The wrong bus
If you've paid attention, you may have noticed that this was my first time looking for a job. So my job hunting skills were virtually non-existent. To make things worse, I didn't even know what to look for. Should I look for a management position? Technical lead? CTO at a startup? Fullstack developer? Frontend developer? Mobile developer?
Ultimately, I decided that I wanted to spend most of my time programming, so I looked for developer offers. But narrowing them down was still tougher than expected. I had my development stack of choice, but I didn't care about it as much as I cared about the values and mission of the organization I would join. Turns out that's not something you can filter by in job boards. In the end, after spending too much time searching and applying almost nowhere, I ended up joining a startup called MusicList.
Initially, I was looking forward to it, because I was the first employee and I thought I could have an active role in shaping the values of the company. But soon I realized that wasn't going to happen. The values of the founders were too different from mine. And I didn't notice before joining because their values were not that different from mine 4 years before. In the 4 years of walking my own entrepreneurial journey, I had changed.
I'm not saying their values were necessarily bad, or that they were trying to do something unethical. But they were on the Venture Capital Startup hamster wheel, and I was done with that. By this time, I was more interested in privacy and sustainability than growth. I also started reading Seth Godin's blog, which gave me a new perspective on how to do things. Right about that time, he published a post called The wrong bus that had a big impact on me. I was on this bus headed to startup land, and I didn't like it. I'm sure it helps that I read it while riding a bus, on my 1-hour commute, in the middle of August, whilst most of my friends were enjoying their summer holidays.
So, shortly after joining, I was back on the job hunt. But this time, I was in no rush. I finally had a stable salary and no debts, and I had just moved out of my parents house (yes, at 28 years old!). The work itself wasn't bad either, I was using Laravel and learning about React, which completed my curriculum with professional experience with "the big 3" frontend frameworks (React, Vue and Angular). But all that time, I wasn't completely happy because I knew I didn't like were I was going.
The following year and a half I transitioned from accepting the situation to almost quitting. From the start, I was completely honest with my colleagues and I even published a public blog post announcing that I was looking for work. I also asked others for advice. It was during this time that I learned that job boards can be some of the worst places to find a job (at least the kind of job I was looking for).
Other than job seeking, I still had the entrepreneurial bug in me (I guess it's never going away). So I joined Seth Godin's The Bootstrapper's Workshop, which pushed me to start working in the open. This is also when I learned about Cypress, TailwindCSS, and Solid; the three technologies that completed my current stack.
Even though doing that on the side was great, I became ever more uncomfortable with my day job. Eventually, I decided to quit for good. But I didn't want to go into entrepreneurship again, so I would be quitting into unemployment. Talking with someone in an event, I had a crazy idea. I had heard about the mythical 4-day workweek, and I thought that dedicating an entire day a week to my side-projects would satiate my hunger for purpose (at least for the time being). So I went ahead and asked for it. If my request was denied, I would quit altogether.
I really saw this as an excuse to tell myself in order to justify quitting without a plan, I totally expected it to be denied. But to my surprise, they accepted. And this is how I started experiencing a 4-day workweek, and haven't looked back since. It's funny how two of the best decisions in my career came out of a period when I felt the most out of place: working in the open and the 4-day workweek.
A couple of months after that, it seems like my job seeking efforts finally started paying off, because I got an offer I was excited for. I was offered a Mobile Developer position at Moodle.
2020: The right bus?
In November 2019, I joined Moodle. I hadn't been unemployed for long, but I had been looking for work most of the time since January of 2018.
In all that time, you must think I sent hundreds of applications, right? Well, I only sent 21. That's like 1 per month. Of those 21, I was rejected from 9, didn't hear back from 7, didn't get clear answers from 3, and was accepted in 2 (MusicList and Moodle). And 3 out of those 21 were Moodle. The first time I applied was for MoodleNet Technical Architect (this happened before joining MusicList) — I was rejected. The second one was for PHP developer — I didn't hear back. And the last one was for Mobile Developer — I was accepted.
All of this is to say that job seeking is hard. At least it was for me with the parameters I set for myself. But I did it! I am finally working at a company with values I share.
So, am I on the right bus now?
I guess there's no way to know, but I would say that I am. I'm not a "startup guy" anymore, although I still call myself an entrepreneur. I cringe a bit at the term, but I haven't found a better word for describing what I do. I could just say that I am a developer (and sometimes I do), but I enjoy working on other parts of the product besides code. I could also call myself a maker or something else, but I don't feel identified by any of those terms. So I'm sticking with entrepreneur for the time being. Even though I don't care about earning money with my projects, so I guess that's not very entrepreneurial. Regardless of what I call myself, I think I'm in the right path.
I've also found a good balance between being an employee and working on my own projects. I never went into entrepreneurship for the riches, I just wanted to do work I cared about. So I'm fine being an employee if I'm contributing to a worthy goal. But there are still things I want to do that will never happen as an employee, so having a 4-day workweek makes my side-projects sustainable. Even if my salary has nothing to do with them.
2021 and beyond
So, what are my plans for the future?
The truth is that I have none, other than continue doing what I'm already doing. That doesn't mean that I'll work at Moodle for the rest of my life, but I have no plans of leaving in the foreseeable future. And I'm still very excited about my side-projects, so I'm not running out of ideas anytime soon.
Things have changed a lot in 10 years, so there's no way of knowing what will happen in the next 10. If anything, I have to say that I'm extremely lucky to be where I am, because even though I have my gripes with the current state of the software industry, I love it.
Lessons Learned
Now that we've got that out of the way, let me start with the part that could actually be helpful to you.
Here's 10 lessons I learned in 10 years.
1. Values > UX > DX
If you expected this post to be only about development, I'm sorry to disappoint. Yes, I am a developer, and these are the lessons I've learned as a software engineer. But it's impossible for me to see my career as "only tech". I think we — as engineers and human beings — are responsible for what our work contributes to.
This wasn't obvious when I embarked on this journey. But now, it's one of my core tenets. In the work I do, be it as an employee or not, the most important question I ask is what is it for?. If I'm contributing to something that is not aligned with my values, I don't care how nice it looks or how fun it is to code — I won't do it.
As a consequence of that, and given my interest in design, I also place a great importance on UX (User Experience). I like to think about it in terms of Kano model, focusing on what actually has a real impact on people.
But I'm no designer, so I also care about DX (Developer Experience). I've talked about how much I like Laravel and Vue, and that's how I want all my development experience to be. I want to spend my time solving real problems, instead of battling accidental complexity or fighting against my tools.
These three — Values, UX, and DX — build on each other, and it is possible to tend to all of them. That comes at a cost, you will be slower in the short term. But I believe it pays off in the long term. That's why most of the time I'll choose to cut the scope instead of degrading quality.
2. Write good code
Every developer loves good code. But there is something subjective in determining whether some code is "good" or "bad". You could measure how well it solves a problem, how often it crashes, or how easy it is to extend. But if we're honest with ourselves, the only valid measurement of code quality is WTFs/minute. So, good code is simple code.
However, that's easier said than done. According to Rich Hickey, simplicity is objective. But I think that's an oversimplification. Sure, you could write the simplest code ever, but as soon as it needs to interact with other code, it won't be as useful. The opposite of that is overengineering. If you write your code so flexible that it can do anything, it'll become a complex mess. So the challenge is in balancing both. I try to resolve this tension with conceptual compressions. Simple enough to be understood from the outside, yet powerful enough to be useful.
There are many concepts that have influenced my idea of what makes "good code": the SOLID principles, YAGNI, First principles, doing code katas, etc. But there is something beyond that. There isn't a specific way to measure good code, but I can recognize it when I see it. Some people call this "taste", I often call it "elegance". Regardless of how you call it, there is something I'm convinced of. Programming is not just science, programming is an art. And that's why I love it so much.
Write good code, make good art.
3. Be opinionated
One of the earliest ideas that is taught to developers is to "use the right tool for the job". While I agree on the overall idea, I have to say that most of the time it doesn't matter.
This is particularly irrelevant when it comes down to framework comparisons. There are tons of articles talking about Vue vs React vs Angular vs [insert new JS framework here]. The truth is that you'll be able to do the same thing with all of them. And I'm not saying that these comparisons are useless. But the chances that they actually matter for your project are slim. In the end, I chose the one that I enjoy working with the most.
React is all the rage today, but for the life of me I don't see how anyone likes it more than Vue. Now, before you jump down my throat maybe wait until you finish reading the blog post. I never felt comfortable writing React (who ever thought that throwing a Promise makes sense!?), whilst using Vue is effortless. I'll even go further and say that Vue helps me become a better developer. And that's something I'd say for all my favorite tools: Laravel, Vue, TailwindCSS and Cypress. I don't think it's coincidence that all of them also have great documentation.
I'm aware that I'm often misunderstood when I raise this point, so let me clarify. I am talking about personal preference here. When I join a team, there are more important things I care about. So I'm more than happy to work with the tools that are already in place. Even if I were in a position to make the choice, maybe I wouldn't chose my favorite tools for a team project anyways.
This also doesn't mean that I never ever want to learn anything new, quite the opposite. I don't find technology worthy of taking this position every day. But when I do, they convert struggle into bliss. One common occurrence is that I'll start using patterns I learned in these tools elsewhere. For example, I'm always porting Laravel facades to other languages.
And I'll finish by saying that frameworks and libraries are not the only tools I'm referring to here. Your programming environment also matters, and I have to credit Caleb's awesome course for showing me that.
4. Never stop learning
If I think about it, I learned about my favorite technologies on my own. And if I had to say what made me grow the most as a developer, I'm not sure if I would credit my work on "real projects".
I mentioned it before, but it bears repeating. There is a valley of difference between doing something as an employee and doing it for yourself. I've also learned a lot from watching conference talks and reading books and blogs, but nothing beats doing something from scratch on your own. That's why I think it's important to be deliberate about improving yourself, instead of expecting it to happen as a side-effect of doing your job.
I know there are a lot of developers who don't want to dedicate any time outside their working hours to coding. And that is totally fine, I don't think that should be a requirement. The problem comes when companies don't allocate resources to self-improvement. And even when they do, most of the time it is only for technologies that are relevant to the company. I'm sure there are times when you come across a new technology or paradigm that gets you excited, but you don't do anything about it because it's not relevant to the project you're working on (and there are deadlines). However, following that curiosity is what will make you a better developer in the long run.
To be clear, I don't think this is inherently wrong from the company's point of view. After all, in our capitalist society, employment is an exchange of labor for money. Which can be done as humanly and fairly as possible, but that's what it is. And you could choose to live outside of capitalism, but good luck with that (I'm not being snarky, I'm trying to do some of that myself).
But there is a loophole. We, developers, are in an extremely privileged position. There is certainly no shortage of jobs, salaries are among the highest in many professions, and remote work opens many doors. If you use this to your advantage, you can navigate this capitalist system to keep improving while having great work-life balance.
I'm taking advantage of this situation with a 4-day workweek. I don't see it as a 4-day workweek at all, I see it as a 4-day main project and 1-day side-project workweek. If you think this is crazy, maybe it's because you haven't tried it yet (I certainly did before giving it a shot). But it's not the only way. You can also take sabbaticals or switch to freelancing for a while.
Now, I know what you're thinking, and I don't want to get into financial independence, cost of living, and all that jazz. But I'll say that if you don't have that kind of buffer (in your lifetime, not at any given point), you've got bigger problems to worry about. We are privileged enough to not have to worry about this. If you want to learn more about these topics, I recommend checking out the blogs of JLCollins and Mr. Money Mustache.
5. Think long term
Code is read more than it is written. You'll only write it once, but there is no limit to how many times it can be read. Whenever I look at code I wrote years ago, I'm often glad that I cared about readability and following best practices (although be careful with so-called "best practices", there's no silver bullet). If this made a difference for me, you can only imagine how important it is for other people reading your code.
At the beginning of my career, I wasn't sure if agonizing over details was worth it (and it seems like I wasn't alone). I would spend too much time thinking about things like variable names or code. I did it because I couldn't help myself (and to be honest, I enjoy it). But I had the impression that it wasn't the best use of my time. Over the years, I've found that eventually it pays off. Sure, there is code that nobody will read. There is code that doesn't even make it to a commit. But the point is that the way you do anything is the way you do everything. There is a fine line between things that matter and nitpicking though, so I try to be practical about it.
Looking at the broader picture, it is essential to separate the urgent from the important. There are things that are urgent and important, so you'll naturally do those first. However, the trouble begins when you start prioritizing the urgent things that are not important over the important things that are not urgent. We always want to get things done as soon as possible. But things take time, and there's no shortcut that can change that. So give them the time they deserve. When I get stuck on a problem, the most effective solution is always to give it time. I leave it for the next day, or I go work on something else. When I come back, it always gets easier.
And you have to apply this mindset to your mental bandwidth as well. If you're mindlessly checking tasks off a TODO list, you're only being reactive and you'll never get anywhere. You need to be proactive, you need time to ponder and to follow your curiosity. That's how you'll make your best breakthroughs. It can feel like this is slowing you down in the short term, but these are the types of actions that will compound into your best results in the long term.
Zooming out even more, you can also apply this to your career. It's fine if you're lost for a while, if you keep working on it eventually you will get what you deserve. In the short term, luck is a big factor. If you don't succeed passing an interview, or if your project doesn't get the response you expected, that doesn't mean that you did anything wrong. By the same token, if you succeed that doesn't mean you did everything well. But in the long term, luck is diluted.
However, there is something crucial to keep in mind. The "long term" can be longer than you'll be on this path. Longer than you'll be alive, for that matter. So you should be comfortable with not getting what you want. Don't put yourself in a bad position with the hopes that it will eventually pay off. I've had my ups and downs, but I've never been done something I didn't want to do. Plan for tomorrow, live for today.
6. Use systems and processes
Regardless of how much experience you have, you're still human, you will make errors. Not only that, our brains are not wired for long-term thinking, so if we only follow our gut, we'll be all over the place. This can be improved with discipline and deliberate practice, but we will never become perfect beings. That's why I think it's important to have systems in place.
Peer reviews, schedules, workflows, linting rules, etc. All of them help us reduce human error and become more consistent. But you should also be careful that your systems don't get in your way. There's a reason why most people hate bureaucracy. Even though it's inevitable to a certain extreme, it should be minimized.
And systems are not something set in stone. You should create your own processes, see how they are working (or how they aren't) and improve them accordingly. And that, in itself, is an ongoing process. I'm always trying new things and reflecting on how my systems are doing.
I have written about this before, so if you are interested you should check out Rigid-Flexible Planning and Order vs Chaos.
7. Remember nothing
Some years ago, I talked about the power of ignorance, and it is still one of my most controversial ideas. But 5 years after writing that post, I still agree with most of it.
In programming in particular, it may seem counter-intuitive to say that, because there is so much jargon you "have to know". But actually, when I say "remember nothing" I really mean "remember nothing on purpose". When you are learning about a new technology, a new design pattern, or a new paradigm, the name of the thing is the least important. It's not the same to know the name of something than knowing something. If you really understand something, you'll learn its name without trying. So you should strive to understand, not to remember. The names will come naturally, and they will serve to compress ideas. Instead of explaining a design pattern every time, you'll just use the name as a shorthand for the entire concept.
At the beginning of my career, I used to take courses and read about the basics. Things I should already know, and I mostly did, but I still enjoyed drilling the basics. I did that until it got boring. And I think that's really important in order to interiorize the principles.
Another way of looking at this is the way you tackle problems. Whenever I am working on a project and something doesn't pan out, I will often spin up a hello world application and try to reproduce the problem in isolation. This is helpful to remove the existing baggage on the project, and helps giving me a fresh view on the problem. I also make a conscious effort not to remember the rationale behind some of my decisions (that's why I don't write comments too often). If later on I am reading some code and I don't understand it, or I'm calling a method that doesn't work as I expected, that's a great way to see it like a newcomer would. If it's not obvious, it's probably not right.
8. TDD is the way
Like most people, I wasn't too keen to get into TDD at first (Test Driven Development). But after having seen the other side, I can't go back anymore.
Let me be clear in saying that I don't believe in TDD as a dogmatic approach to coding. For example, I don't look at code coverage at all, because I think it's a perfect example of Goodhart's law. But now that I've gotten used to writing tests very often, I feel crippled when I can't do it. So let's call it TDDish.
The main reason why I think testing is great is that we all do it. When you are developing a new feature, you're probably running some code to see that it actually works: calling a script, opening the browser, etc. So you are effectively doing TDD already. The only step you're missing to follow the "TDD way" is to automate those tests. At first, this will slow you down and that's why many developers dread testing, as I did. But if you persist, you'll eventually reach a point where writing a test becomes as natural as calling a script or opening the browser. Once you get over that hump, testing will become an essential tool in your toolbox.
In the short term, this will give you a faster feedback loop when you're writing new code. I use Cypress very often instead of a normal browser, because it's so easy to automate what I would do by hand and I can time-travel between steps.
In the long term, it will let you sleep at night. And more importantly, it will allow you to refactor without fear of breaking existing functionality. And refactoring is crucial, I probably spend more time refactoring than I do writing new code. Without tests, you're often afraid of breaking things so you think twice before refactoring. And that leads down a dark path.
Testing is also great for maintenance. When you find a bug, you can just fix it and move on. But if you write a test reproducing the bug, you've fixed it forever. It's only fixed if there's a test.
I don't follow the doctrine of the testing pyramid, which dictates that you should have more unit tests than integration tests. I just write the tests I find useful, and those vary depending on what I'm working on. For example, when I'm writing a library I usually write a lot more unit tests, because it's more likely that those units end up being used in isolation. But when I'm writing apps, I rely almost exclusively on integration tests.
There are a couple of heuristics I use to gauge how my tests are doing. The first one is how often the software breaks. You'll always find bugs in your software, specially in edge cases. But if you're finding too many obvious problems that your tests weren't picking up, that's a bad sign. And the other heuristic I use is how often I need to change my tests when I'm refactoring. It is one thing if the refactor involves some change in functionality, but if every time you change something your entire test suite goes nuts, you're probably doing something wrong. Your tests should not replicate the structure of your code.
9. Be a team player
In this blog and my online persona I talk mostly about the work I do as an independent developer. However, that's not what I'm doing most of the time. And if given the choice, I'm not sure if I'd want to.
It doesn't matter how good you (think) you are, you won't get anywhere by yourself. Success and quality wise. There is a saying that goes "you are the average of the 5 people you spend the most time with". It can seem shallow to think this way, like you don't have a personality of your own. But whether I like it or not, it's true to a certain extent. And I'm not sure if that's because you seek people like yourself or because your environment shapes your personality. I guess it's a bit of both.
These 5 can be people who don't even know that you exist. If I had to list mine, I'm sure more than one would come up — because I spend a lot of time listening to podcasts, reading blogs and watching presentations. More often than not, however, you'll be surrounded by the people you work with. Naval Ravikant said "if you can't see yourself working with someone for life, don't work with them for a day". The first time I heard it, I disregarded it as idealistic. But the older the advice gets, the truer it sounds.
In most occasions, you won't be able to pick your peers. But you can pick the company you work for. If you're starting at a company with strong values, chances are that the people around you will share these values. Even better, because you didn't pick them, they'll bring diversity to your points of view and you will get out of your filter bubble.
But there is something you need to understand when you're joining an organization. It is extremely difficult to change the culture, in the same way that it is extremely difficult to change people. And to be honest, even though it can be frustrating at times, it's probably for the better. I often think about the four stages of competence, which explain how a person can know so little about a topic that they don't see the complexity and think it's easier than it seems. You are that person in more areas than you think. Most of the time, there's a reason why things are like they are.
But that doesn't mean you shouldn't strive to influence the culture anyways. I think the most important thing for a project to succeed is communication and awareness. It isn't following good practices, nor having a great technical solution, nor even having money (although these are important). The most important thing is communication. That's also one of the reasons why I prefer working at small companies, because I think it's easier to talk with the right person and understand what's going on. So, even though they can feel like chores, I think doing 1:1 meetings, managing expectations, and having regular updates is really important. Overcommunicating is way better than undercommunicating.
10. Know Thyself
If you've read this far (thanks!), chances are that you disagreed with something I said. And that is totally fine, I don't think what I say applies to everyone. Certainly not everything applied to me 10 years ago, and it may not apply to me 10 years from now. But there's something that is important for everyone: You should know yourself.
When I started working, I had this idea about what my career would be. I would start working as a "junior developer", then I would be a "senior developer", and eventually I would graduate to become a "manager". Now that couldn't be further from the truth. I have dabbled in managerial positions, and I enjoyed them to a certain extent. But programming has always been at the forefront of my job. And I would hate stepping away from the keyboard (or the whiteboard). Not everyone is like this, some people actually enjoy managing other people. Or — as good managers say — enabling others to do their best work. And I'm glad they exist, but I'm not one of them.
Later on, I started to have some doubts whether I wanted to work for someone else or I'd rather work for myself. I think the jury's still out on that one, but I know for sure I could be happy with either one. It depends more on what I'm doing — and who I'm doing it with — than how I'm doing it. Some people only care about the technology they use, or how much money they make. I'm not sure if I'm glad they exist, but I'm not one of them.
Since the beginning, I've been inclined to "do things right". Maybe too inclined, even, because I have been an architecture astronaut at times. And I worry that my experience is often a crutch more than it is an advantage. But I'm aware of that; of the good parts and the bad parts. And it's something I try to control with the systems I've put in place.
One great way to know yourself, is to work in the open. I have said it before, but for me working in the open is valuable in and of itself, even if no one is looking. And if you don't even know what working in the open means for you, just write. If you're not writing, you are not thinking.
You'll never finish this journey of introspection, but you must walk it. All along the way, you will change. We're all chameleons, so our colors won't be the same tomorrow as they were yesterday. And experience colors our vision of the world. If you think the way you do, it's because of what you've lived through. There's no other way to learn, and with new experiences there will come new lessons.
Onward
So, that's a good chunk of my thoughts right there! I hope it was useful to you, and I'm grateful for what my journey has been thus far.
I will continue working in the open, so if you want to keep up and see what I learn in real time, you're welcome to follow along!
2024 Update: I'm not working at Moodle anymore, you can learn more about why and what I'm doing next in The End of The Chapter.