Two years ago was my last week as a software engineer at Toptal where I was leading team of 12 people. Since then I work on my projects full-time. That was my the most productive and satisfying years for the whole decade-long+ career. While I still far from achieving my goal of building a sustainable business I learned a lot about product development, copy, marketing, and sales. In this article, I share lessons I learned as a developer while I was working on a dozen projects. If you like me, have an itch for making stuff and seeking for independence, this piece is for you.
Learning the best practices
My first years as a professional developer was rough. After I failed as an indie game developer for a few years I was working as a freelancer making various web projects. I was a developer you wouldn't want to see in your team. I worked long hours on low-budget projects with unrealistic estimations that were making both my clients and me disappointed in the outcome if there was one at all. Bugs, missed deadlines, features that didn't meet the expectations, I saw it all. I didn't know positive examples I but was sure that there's a better way to develop projects.
After yet another flopped project I opened for myself Ruby world that felt like a different realm. The community greatly influenced my views on development, project management, and business. I read Getting Real and all books I could find on business and project management. I religiously studied and tried all known methodologies that suppose to improve the code quality and productivity. SOLID, TDD, BDD, GTD, SCRUM, you name it. It took another few years before I became a developer that you would want to see on your team.
During all that time I was always working on side projects. I started dozens of them of all kinds, from todo lists, ticket trackers to social networks. They were taking all my free time, but I never managed to finish any of them. At first, I got excited about the idea, came up with a new shiny stack of technologies, and then developed it applying the best methodologies I learned the hard way. Then I would be stuck, lost interest or came up with a new, better idea. When I quit my job and started investing my own money into projects, I quickly realized what I was doing wrong.
Do your worst
The practices that are vital in teams might be poisonous when you work alone. Paradoxically, to do your best you must do your worst!
When there's dozen of people working on a single code base, it's necessary to ensure that the systems are designed well, the code is easy to read and have decent test coverage. Pull requests should be reviewed and merged only when they satisfy the team standards. "I'll refactor it later" never works in the teams because there's too much going on and more likely the next person that touches your code won't be you.
When you work alone, following the best practices slow you down. When you're the single code owner, you can defer writing tests until you met a critical part that can't break at any cost. Even then just couple end-to-end test could be enough. It doesn't mean that I avoid tests altogether. If the code is easy to write thought unit tests or too hard to test manually, I do it.
There's nothing worse in code design than a poorly chosen abstraction. When I develop my products, I prefer to copy-paste code two, three and even more times until I see a common pattern and if and only if I change it frequently. It doesn't matter if you have 3 repeating pieces in the code if you are never going to change it. After all, the whole point of refactoring is to make it easy to modify. I think this realization still applies to teams, but you must be systematical about it and keep a ticket in your backlog or notes in the comments.
Focusing on performance is another mistake I was repeatable making. We all the time see tweets and articles about the importance of small code bundle, fast response time or small memory print. Developers often shame companies for their sloppy work, and you might think that your small business won't survive without providing the top-notch experience. The truth is not that important if you never ship your project. People won't buy your product only because it loads in less than a second, but if it solves their problem, they will wait 5 seconds and even more. If your page has poor performance if the user created a lot of content that is a great problem to have because that means somebody actually uses it.
It doesn't matter how well your code is written, what is test coverage or how fast is it if it never shipped or has no users. Also, your first customers will be early adopters that want to have an advantage of being the first using it, and too polished product might signal them that it's too late.
Stick to the tech you already know
The whole career I was chasing the better programming languages, newest frameworks and most efficient ways to manage infrastructure. I tried at least one new tech in every side project I started, and because most of the time I was wrapping my head around and learning new concepts I never managed to get to shipping. No doubts it was beneficial for my career as I learned much more than the average engineer. It made my truly full-stack developer that can do everything from infrastructure to front-end. It also helped me to satisfy my passion for new tech without hurting my employer by experimenting in the production code.
When I started my indie maker adventure I wanted to ship instead of learning so I decided to stick to the stack, I know the best — JavaScript both on back-end and front-end. Even though I was capable of managing infrastructure myself, I choose the Firebase platform that provided everything from static website hosting, servers to a managed database. It wasn't optimal, most efficient and elegant, but because of my prior experience, it all helped me to start and focus on products quickly.
At the end of the day, I don't use most of the technologies I learned, and there's plenty of excellent examples of founders without prior programming experience that taught them self to code by doing and started making more money and much faster than me. It made me wonder if it was worth it all.
If your only goal is to learn new stuff, you can ignore my advice, but if you want to ship, avoid using new technologies unless necessary.
Be lean
For many years I worked in companies where quality was the priority. It wasn't acceptable to deploy half backed product that doesn't provide up to standard experience on all levels from the core functionality to small details. If the user enters their name, there must be a setting for that. If there's a list, there must be pagination. And so on and so forth.
When you are small, even a standard feature like name settings or password recovery could take the time that might be spent on more important things. When I was working on designs for my first big project, Ask User a widget for web sites, I noticed that I spend too much time on details that aren't necessary for the first release. I started cutting features until I left with the functionality that solves the main problem. During the development, I decided to step further and skipped things that seemed absolutely necessary at first, like the ability to remove created sites. I was planning to introduce that after the release but to my surprise, users didn't care. They wanted utterly different features that I didn't even think of initially.
Then I spend weeks writing a billing system only to learn that people don't ready to pay for the problem I solve. For the next project, Telepost, I decided to ask users to send me money to PayPal, and it worked out. Later I added a button "Activate the Pro plan" that does nothing but shows the message "We'll contact you soon" and sends me an email (using Zapier) with the user details. Then I'd talk with each interested customer individually. During the conversation, I was able to pitch my product and hear objections about why they aren't ready to pay. That not only saved me time but also helping to shape my project for users' needs.
Getting feedback as soon as possible and changing your product according to it, must be your top priority, so optimize for shipping fast. Cut as many features as possible, then cut more.
Afterword
Thank you for reading my article. I hope it was useful for you. I tried to outline the most important lessons I learned as a developer, but there's so much more to cover! If you liked it, please let me know. I'm planning to publish more articles on the topic including more business-oriented and if you're interested in reading them first, follow me on Twitter.
The photo for cover is kindly provided by chuttersnap on Unsplash
Top comments (17)
From dozens of failed projects and gigs to jumping from idea to idea. You just defined my story as if you were reading my mind. This article felt like I wrote it myself! (Difference being that I have less industry experience 🤣 and I'm horrible with words)
I can't wait to share your article. I have this one free app on Google play that took me 3 days to write and publish (the first version of course) and I have a 2 year long project that never saw the light.
Write more of these man!
I'm glad it resonated with you! Thank you for showing the support!
What stops you from releasing your two-year long project? Maybe you don't realize, but it's quite ready for its first users? A wise man said that what you should ship product while you still embarrassed about it. When you don't that means it's too late!
I had a breakthrough when I set myself a deadline to ship a web app in a week and did it publicly on Twitter. The combination of constants that made me think about how to reduce the scope and accountability helped to achieve the goal. Once I shipped it on Product Hunt and received a lot of positive feedback I got me wanting more of that. I got hooked!
I made the mistake of assuming. As you said, I hadn't even published any piece of it and I was struggling with how I'll be processing credit cards. I added so many features that tech debt caught up with me. I am still looking forward to working on it again. I'm still babysitting the android app for now.
I see. Good luck with both projects!
I agree with you.
When you are all by yourself, the most important thing is to have something out that solves the core problem well.
I am still in the fail and trying phase and definitely keep that post in mind
Good luck with your projects, Emmanuel! You can do it!
There’s quite a bit here I don’t agree with, but this, this here is the unadulterated truth.
I agree with you but I also have a different thought. As you keep learning through your side projects, you progress in knowledge. If you realize this too soon, you may never get that far within dozen years of working. Most of the time people spent at work for running deadline, and you would only learn most in your extra time.
So far, you should keep learning and building in parallel, so that you can still have something to release while keeping up with the world.
As I said, it depends on your goals. If you want to learn new tech, a side project is a perfect place for that. It doesn't necessarily mean that you will never ship it, but your chances will be much better if you stick to the stack you already know or at least limit unknowns. When you work on a product, you'll have plenty of learning beside programming: marketing, copy, sales, and support. Of course, it's just a matter of balance, picking a new existing tech might greatly help your motivation on the other hand too much learning could make you miserable when you realize that you work on a feature for a week that could finish in hours if you'd pick familiar framework/language/etc.
Anyways, it depends on context, the free time you have, your project, etc. Do what works best for you!
Same story as mine. Totally agree :-)
Thanks for writing
You're welcome, I'm glad to hear that I'm not alone!
Awesome! Thanx for the article!
I'm glad you liked it 🤗
Refreshing! While I don't necessarily agree I found the article refreshing :)
Thank you for your kind words ❤️
Thanks for the article, it's really sum up almost every facing issue while I was working with different kind of projects.
Thanks for thanks!