Signup to the waiting list!
Every time you post a harsh comment on Reddit about something or someone, a developer bucket leaks.
Every time you post an issue on a repository trying to push your own agenda while being mean to the people that put countless hours into trying to do a good job on that project, a developer bucket leaks.
Every time you post a mean tweet trashing a library in favor of another one, a developer bucket leaks.
Anyone who’s ever posted some of their work on Reddit, Hacker News, or any of those big sites know that there’s a lot of fear involved in the process. Fear of not being good enough, fear of being judged. Even if your work is great, sometimes a harsh comment shows up. And even one harsh comment can dry up dozens of positive ones. I don’t know what psychological theory explains this experience, but that’s how it feels.
A few days ago I decided to post a link to one of my blog posts on Reddit. A comment said that the blog post I wrote, which was carefully written after many days of drafting it, was trash and just a hook to get people to buy my poorly written ebook.
That comment stuck in the back of my mind for the whole afternoon, and instead of motivating me to do better, it made me angry. My bucket was emptied in 2 seconds and took the whole day to fill up again.
That person moved on, yet nothing good happened as a result of their action. It was a very unproductive thing for everyone involved.
One suggestion: especially with written words, pay more attention to how they could be interpreted on the receiving end. Be kind, even kinder than in real life, because emotions are dried up when expressed in text form.
How to fill buckets
As quickly as people can empty buckets, they can fill the buckets again. Those times are wonderful.
I had been blogging for a few months, consistently, when a person wrote me an email. He said that one blog post I wrote had been very helpful, and helped him solve a problem. He then went on and said “you should write a book.”
Now, as a blogger, that’s an awesome thing to hear. It means your work has proven to be useful. Someone wants you to even write a book. And guess what, my bucket was so full of joy and motivation that I decided to start writing a book that very evening.
How we can do better
We start the day with our developer bucket empty, and ideally, we’d like to have it full when we are done for the day.
Our buckets already leak a lot, because we think we are always one step behind the others, we suffer impostor syndrome, we have easy access to code superstars that tweet day and night about the marvels they are building, or crank out a YouTube screencast a day, or live stream like it was the most natural thing to do.
It’s easy to feel like you are not good enough. But if you are good enough for the majority of the people, you should not bother with what a minority of them thinks. You can’t please everyone.
As a developer involved in mentoring, I usually draft content for beginners. It’s awesome when people give back even by sending a quick thank you, or by sharing a tweet.
I think we’re all in the same boat. While some people try to impress others by launching their strong opinions into the world, we must pay special attention when communicating with the others. This is especially true for developers, because we almost exclusively communicate using text, and it’s easy to misinterpret the content of a sentence if you’re not super careful.
Focus on filling buckets
Have you ever said thanks to the developer of a library that saved you 10 hours of work on Twitter or via email? Do it, and fill that person’s bucket.
When you read a blog post that helps you with something you’re stuck with, take the time to thank the person that wrote it. Just a one-liner via email or Twitter can make that person’s day, and motivate them to write another post in the future, since they feel useful to the world. They helped you, so help them in return!
Have you ever opened an issue on a GitHub project just to say good things and provide constructive feedback? Do it, and fill the project developer’s buckets.
Developers burn out with their Open Source projects because everyone is just asking for help to build their paid projects. GitHub has an Issues tab (which involves work for the maintainer) and a Pull Requests tab (which is even more work, since the maintainer needs to understand the code someone else wrote, figure out if that’s a good thing to add, and manage rejections if that’s the case).
But there’s no “Thanks” tab, where people can praise the project. People can only star a project, but that means very little. Consider doing a little bit more for those people that do very hard work, and help them fill their buckets.
Have you ever publicly thanked a developer for their Open Source code?
Have you ever made a PR just to fix a little thing you notice in a library, even in its documentation, just to make sure tomorrow no one will see that glitch ever again? Do it, and fill the project developer’s buckets.
It’s great to have someone, like you, point out an unnoticed typo that has been there for months. Other people have probably looked at it and immediately lowered their perception about the quality of the project.
It’s always harder to fill a bucket than to empty it, but I think it’s worth it.
Together we can all go a long way.
More lab tutorials:
- The stack I use to run this blog
- 8 good reasons to become a software developer
- SEO for developers writing blogs
- Review of the book The 4-Hour Work Week
- Build a lifestyle business
- Build your own platform
- As an indie maker, what kind of product should you build?
- Create your own job security
- Developers, learn marketing
- The freedom of a product business
- Generating value
- Have a purpose for your business
- The idea is nothing
- The niche
- Remote working for software developers
- Product / market fit
- The best podcasts for frontend developers
- Why should I create an email list?
- Disconnect time from money
- The scarcity principle applied to software products
- The social proof principle
- How I added Dark Mode to my website
- My notes on the Deep Work book
- The pros of using a boring stack
- How to estimate programming time
- On going independent as a developer
- How to learn how to learn
- Why interview questions for programming jobs are so difficult?
- Do I need a degree to be a programmer?
- Everyone can learn programming
- How to be productive
- How to get the real number of pageviews of a static site
- Have you filled a developer bucket today?
- How I record my videos
- All the software projects I made in the past
- Tutorial purgatory from the perspective of a tutorial maker
- Every developer should have a blog. Here’s why, and how to stick with it
- Having a business mindset for developers
- How to write Unmaintainable Code
- What is Imposter Syndrome
- How to work from home without going crazy
- How I prototype a Web Page
- You should be the worst developer in your team
- How to start a blog using Hugo
- Write what you don't know
- How to block distractions using uBlock Origin
- Coding is an art
- I wrote 1 blog post every day for 2 years. Here's 5 things I learned about SEO
- Dealing with the fire
- On being a generalist
- The Developer’s Dilemma
- My plan for being hired as a Go developer. In 2017
- Productivity gains of using a Mac and an iOS device
- How to go from tutorials to your own project
- This is my little Digital Garden
- How to start freelancing as a developer
- Sharing the Journey Towards Building a Software Product Business
- Subfolder vs subdomain
- How I use text expanding to save time
- Software is a superpower
- I love books
- How I decided to create a new projects management app
- On using IndexedDB as the main database
- How to automatically cut silence in videos