If you are a web developer, maker or an entrepreneur who is trying to build a sustainable businesses,
Here is the Top 1 (yes, it's not a yet another Top 10 article) way to not mess up your project.
1. Don't be a perfectionist
If you really want to be a perfectionist, change the definition ð
Perfectionist - someone who takes the perfect next logical step for the project.
And not someone who keeps tweaking that 1px off margin ð€£
Not convinced yet? Sorry I didn't try to perfect this post ð€·
Original Tweet - https://twitter.com/onerinas/status/1399596072318640128
Update: Wrote about 2 tricks to stay motivated on your side project
Top comments (17)
I agree, but practically it takes decision making for the situation.
I want to release software that is "good enough" for me to be proud of but not waste time on. Like get it 80% or 90% correct and release today and fix later, rather than spending days, weeks or months getting it 100% ready. Or worse, never releasing, because the more you work with the software, the more potential bugs and features you'll spot. If you drop your standard too low, then your 70% correct software might be prone to bugs and being hard to change (because you never refactored and you left no docs or tests to help future you). But if it was an experiment, then maybe 70% is fine.
Also, consider who is the "good enough" target? When I make a website for the public to find as my hobby project, it is different to making something good enough to put in a dev portfolio for a portfolio, or maintaining ecommerce site for a client or employer who pays my bills.
And there is a difference between making something good enough for you to use and good enough for the open source community to use and maintain. I like to start small, focusing on my own needs and getting something out and working. Then if I like it and others show interest, I'll extend the docs and functionality. I also make use of a lot of templates so when I start a new project, I already have professional-looking documentation and project structure to save me time and effort, then I can drop in my project logic.
Pro tip:
Add versions to your software. Keep it as pre-release stage as a long as you want.
That will lower the expectations of the community and for yourself (you can break stuff and experiment with less fear that someone relies on your software).
When you think it is "good enough" to be relied upon as a library or CLI tool or whatever, then you can give it as release.
And publish it to a registry so people can install it.
From then on, there is a higher expectation from yourself and others to make "correct" software. It doesn't have to be perfect, but someone would hope that if they reported a bug that you'd fix it when you can.
Also you can still commit experimental code to your main branch. Just hold off on your
1.1.0increment until you are comfortable the code is "stable".True. I think this is the key. Try to make it work and useful for ourselves, put it out there.
When you make it public, we have to keep it mind that whole world doesn't sees that yet.
We got so much more potential customers yet to see/use the product yet.
Sometimes I make projects because I can use them daily.
Then someone makes a request for a feature or gets more stars than other projects of mine or someone asks when a feature will be done, then I use that as a motivation to keep improving it.
I like what you say but this only apply to anyone who has at least your level of experience. Such things told to me by experienced developers have left me very depressed as time because I couldn't do better. I don't blame them because when people gain experience, they forget how it was to be a beginner.
These days people with five years of experience talk as if they are Uncle Bob or TGOF (The Gang of Four). Have some empathy for newer developers because any attempts of enforcing your standards on them makes them perfectionists. That's just my humble 1.8 years of experience and I mean no offense towards you personally.
Hi, I'm sorry you felt that way from the comment and from conversations with other developers. Maybe you can explain more on which part you think is harmful?
My advice is indeed intended for beginners. When I coach beginners, I don't expect them to get their code efficient or pretty or to follow best practices. Some of them apologize for writing bad code that they are ashamed to show me or put online.
I assure them that I care more about solving their problem of making a tool or a website for themselves or for someone else. And that the understanding and code refinement will come with time. I don't hold them to standard of concepts they have never heard of.
I don't expect beginners who have the kind of habits and templates I have built up over years. But I do share those freely so that they can apply them too, if they choose to use those.
Most of my posts here are intros to a tools, or sharing my template projects, or giving advice and inspiration to beginner developers (on of those was by far my most well-received post based on feedback).
Reading your messages, you definitely sound like a senior developer whom I'd want to be my senior. I don't have any degree and I worked very hard to learn how to code, I was 19 and took me a year to teach myself full-stack. I have colleagues that are far more experienced than I but usually they end up asking me questions when they can't figure something out. I'm not saying I'm Einstein. Far from it. I just study and work very hard every day.
Given my situation, I used to suffer from imposter syndrome and suffered from confidence issues, still do to some extent. When I tried to apply for jobs, I was usually ghosted. In coding interviews when I did a lot, I was using excessive abstraction, when I used what I needed, I failed to add or didn't add a line. When I try to share my opinion, somehow I'm wrong because an experience developer say that SEO is not an issue for a website built with React on the front-end because modern day bots can figure it out. (No, not Gatsby or Next, pure React). When I say SEO is not an issue. "View Page Source" shows that SEO sucks.
Maybe I've been applying to the wrong places or today's software engineering scene is full of stigma and perfectionists who just want to appear smarter than you. The thing is, I end up believing them because I feel they know what they're talking about. Which is just exhausting because I find every developer has opinions and they judge you and your work based on their opinions.
Unfortunately developers are going to be the same as any non developer field. Some want to tell you that you are wrong because they get satisfaction from being right. Post a message online with a bold claim or a deliberate inaccurate fact and just see how quickly people will jump in to correct you! Dev and non dev topics both.
Or they feel their way is threatened and get defensive (I have learned to stay out of best OS, best framework, best paradigm or best language debates online because it gets messy and too emotional and in the end no one had a solution that fits every case)
And then you will have some developers who are patient with you and have awareness that just because we do something differently or have different knowledge doesn't mean we have to be critical. I hope you find a company and team that has that culture.
I've also learnt to give me opinions without stating them as facts, or I say "such and such worked for me, so i recommend, but it might not be right for you". That takes maturity and awareness which not everyone has.
Thank you Michael, this means a lot to me.
I'd like to see if I can provide guidance in dealing with job seeking, learning direction or habits, or any topics you need help with (I am interested to talk more on the React SEO thing as I've spent some time on that recently - it's a complex one).
Let me know if you want to connect on LinkedIn or Twitter and maybe set up a video chat. I've done that with a couple of people over the last year and it has been fun and rewarding on both sides of the conversation.
There's an equally important addendum to that #1 of yours....
1b. ...but don't be sloppy either: I know of projects that, in the pursuit of the "ship fast" strategy, are so poorly written ("POC quality"). Then the apps gets successful, but the sloppy foundation source code never gets refactored throughout all releases thereafter. This is not good either.
This is a very short post but I think every developer should read this at the start of their day. I wasn't a code perfectionist but somewhere down the line hearing about clean code, patterns etc made me a perfectionist. The ability to write clean code comes with time. Yes, you can read books like Clean Code, Design Patterns, Refactoring but that will not make a significant difference if you are a newbie.
Such a perfectionist mentally can leave you very exhausted. Be kind to yourself and talk other people's advice and views with the grain of salt. Keep doing what you are doing, keep getting better. Write shit code and improve it later when you have the project completed. Thanks for sharing this.
The "Clean Code Architecture" is poison for me, even if I'm not a newbie. Sorry Uncle Bob.
I don't think it is an architecture but rather a way of doing things. Uncle Bob has been doing it for more than 30 years so I think he knows what he's talking about. It is only the current generation of "senior" developers that gives it a bad name by talking excessively about it in hopes of appearing smarter or better.
I agree completely. Partly the reason why I had to enclose it in quotes. Lots of folks are over-using the concept in places where they shouldn't, thus just making simple things complicated. I would use the exact same words you did, "in hopes of appearing smarter or better". You nailed it!
I can relate ð