DEV Community: Michal Mazurek

Marketing by being helpful

Michal Mazurek — Thu, 11 Jun 2020 09:25:21 +0000

Seth Godin, author of This Is Marketing has this to say:

Marketing is the generous act of helping someone solve a problem. Their problem. It's a chance to change the culture for the better. Marketing involves very little in the way of shouting, hustling, or coercion. It's a chance to serve, instead.

Let's have a look how that looks like on the Indie Hackers community. The opportunity presented below was achieved with the help of Syften, a social monitoring app.

Indie Hackers try to keep costs low

A programmer who quits his job to work on his own app is concerned with server costs. I noticed it's is a recurring pain in the community.

So when I learned how to get $5000 Amazon AWS credits for $49 I wrote an article about it. I configured Syften to notify me when someone complained about their infrastructure costs and waited. Sure enough, one day a “How much does it cost to run your side project?" thread popped up. I replied as soon as I got the notification and watched:

Note how I provide the solution in the comment itself. The focus is on helping, not promoting. I’m not tricking anyone into visiting my blog. My comment became the most upvoted one in the thread, and the thread reached the “top threads of the month” list. I got 17 upvotes, but did anyone click the link?

I promoted my blog only once that week, so all of this traffic came from that one comment. I also got five mailing list signups.

Summary

Well, that's it. Rather starighforward really:

Write down solutions to the most common problems
Set up an alert and get notified when someone mentions one of those problems
Be helpful
Link to your blog, saying that more details can be found there

A Small Warning About Unsplash

Michal Mazurek — Tue, 21 Apr 2020 05:48:05 +0000

Unsplash is a great website. It's a free and open library with a ton of beautiful pictures. You can use them however you wish and you don't need to add attribution, though I'm sure your readers will think more highly of you if you do.

Sounds perfect, so where is the catch?

It's so great that it's the go to source of graphics for a lot of bloggers. The same images are reused over and over again.

I feel like this guy keeps following me everywhere:

I used that very same picture for my own article not long ago. Then I saw someone else using it as well. And then I saw it again. And again...

They know

Unsplash is well aware of the high volume of reuse and in December 2019 they decided to capitalize on it.

What can you do?

Don't want your article to be part of a clone army? Then at least check your image with Google's Reverse Image Search before publishing.

Resources

Why I Discontinued My Standalone App (And Stick to SaaS From Now On)

Michal Mazurek — Sat, 25 Jan 2020 10:24:50 +0000

I'm a solo product developer and I've been working on Code Dog, a pull request reminder, for over a year. Until now it supported four Git sources - GitLab (.com and Self-Hosted) and BitBucket (Cloud and Server). Today I decided to drop support for BitBucket Server and GitLab Self-Hosted.

Code Dog Server

After my initial success with Code Dog Cloud I thought it would be smart to respond to market demand and add support for BitBucket Server and GitLab Self-Hosted. So many people asked for that - the market is there, I thought, it would be foolish not to.

But with time came experience, and with experience came the understanding of just how painful supporting a product like that is. Not just for me, but for the user as well.

A pain for the user

To set it up, the user had to:

Download it
Create a Slack App
Configure SSL so that Slack.com can connect to it
Create a new BitBucket/GitLab user
Configure access to BitBucket/GitLab
And lastly, configure Code Dog

All that just to try and see if they like the app.

A pain for me

At first I distributed the app as an executable. It soon turned out a lot of people considered that "insecure", and still more didn't have a Linux server available. I switched my distribution to a Docker image, but even then I received email after email asking me how to run it on Windows or an environment I was not familiar with.

But that was just the beginning. To make it work I had to interface with Slack, BitBucket and GitLab.

Slack

Slack is not that bad - the documentation is good and support is great. However from time to time they will introduce new features or make changes that required me to spend a day or two coding. One such example were private channels.

Additionally, to create an app, the user needs to do a lot of pointing and clicking, maybe half an hour. Next he has to copy all the necessary keys and IDs to Code Dog to make it work. And then he needs to set up SSL so that Slack.com can connect to it.

This caused an endless stream of emails asking me "where do I find the App ID" or "how do I configure SSL".

BitBucket

Don't even get me started with BitBucket. The Self-Hosted version is based on a completely different code base than the Cloud version. It's written in a different language, the APIs are different, and they have different bugs. I had to start from scratch.

And it's so unimaginably slow. If an instance has more than a few hundered repos it would take minutes to communicate with it, resulting in HTTP timeouts.

I'm grateful to the users that helped me debug it and I'm really sorry to let you down by discontinuing the product.

GitLab

GitLab has even more bugs than BitBucket and is not app friendly at all, it's like they weren't aware apps were a thing when they designed it.

Luckily, the Self-Hosted version uses the same code as the Cloud version so I could reuse large chunks of my code.

Still, integrating with the app and configuring webhooks was so time consuming and frustrating that few users finished the setup.

My breaking point

A few days ago I got yet another email from a user asking me how to solve a mysterious missing_scope error with the Slack API. I sat down and tried to debug it.

As I was slowly digging into the problem it began to dawn on me that catching up with API changes, library updates, and UI "improvements" is making my life miserable. Given the low return on investment I decided it's not the best use of my time.

I gave up.

I'm still working on the Cloud version. I can immediately catch errors, I have access to all of my debug information and I can deploy a new version within five minutes. I'm happy with it.

Conclusion

An indie maker should never attempt to tackle the standalone app market.
The amount of energy required to support it is incomparably larger than supporting a SaaS product.

There is a reason why there are so many companies that specialise solely in supporting Atlassian products.

The Fear of Merging

Michal Mazurek — Sun, 12 Jan 2020 12:55:14 +0000

I used to be a heavy coffee drinker, but once I realised how bad that was for my sleep I quit... Only to find that I've become a heavy tea drinker instead.

Intrigued by my body's pull towards hot beverages I wanted to understand why. The bestseller book The Power of Habit: Why We Do What We Do in Life and Business helped me solve the first piece of the puzzle.

The Power of Habit

In his book, the author explains:

Habits, scientists say, emerge because the brain is constantly looking for ways to save effort.

This process within our brains is a three-step loop. First, there is a cue, a trigger that tells your brain to go into automatic mode and which habit to use. Then there is the routine, which can be physical or mental or emotional. Finally, there is a reward, which helps your brain figure out if this particular loop is worth remembering for the future.

This effort-saving instinct is a huge advantage. An efficient brain requires less room, which makes for a smaller head, which makes childbirth easier and therefore causes fewer infant and mother deaths.

(Please see the How Habits Work appendix from the book for a more detailed description.)

Reverse Engineering My Habit

Clearly my routine was making a cup of coffee, and my reward was sitting down in front of my computer, hot beverage in hand, ready for more work.
But what was the cue for this habit, that in total occupied nearly an hour of my day? Newly aware of how the loop works I started paying attention to what made me put the kettle on.

The Fear of Merging

The second piece of the puzzle came from an unexpected source. Struggling to write articles for my blog I reached for The War of Art - a book about fighting procrastination for writers. Steven Pressfield, the author, writes:

There's a secret that real writers know that wannabe writers don't, and the secret is this: It's not the writing part that's hard. What's hard is sitting down to write.

But us programmers are strange beasts, we tend to be the opposite.
We'll jump headlong into our coding, shunning planning and tapping furiously at the keyboard. And when our code is ready we present it to our colleagues for review. Once it's reviewed and ready to go into production... Suddenly we don't want it anymore.

Suddenly we feel a need to check Hacker News, our emails, or... Spend 15 minutes making a cup of coffee.

That's it! My cue! Finally, I realised that my cravings start after I've:

Written an email and it's time to hit "send"
Written code and it's time to create a pull request
Got feedback on my pull request and it's time to merge it
Wrote a blog post and it's time to publish it

In other words I procrastinate every time it's time to step out of my comfort zone and do responsible, irreversible actions that can potentially lead to social repercussions.

An email may cause disagreement ("Sorry, but you're wrong")
A pull request may reduce our status ("How could you not spot this bug?")
Releasing code to production may subject us to anger ("How could you crash our app?")
Publishing a blog post may lead to rejection (nobody reads it)

These are all primal fears stemming from our social nature. They used to save our lives (being excluded from the tribe meant certain death), but now they just get in the way.

I wanted to see what would happen if I stopped drinking both coffee and tea. I laughed out loud when I found myself pacing mindlessly in the kitchen one day. The code was ready and it was time for a release. The loop was still there.

Breaking The Loop

Let's get down to business.

Every time you grab that cup of coffee you know what you have to do. You know why you put off doing it. And you know how good it will feel once you do it. So how can you overwrite your primal instincts?

There are a few easy to implement behaviours you can utilise to help you with that.

Reduce The Friction

In Deep Work Cal Newport reminds us that:

A now voluminous line of inquiry, initiated in a series of pioneering papers also written by Roy Baumeister, has established the following important (and at the time, unexpected) truth about willpower: You have a finite amount of willpower that becomes depleted as you use it.

You struggle with yourself every time you decide on what to focus on next.
Do I work on A or B? Do I reply to my emails now or later? Where will I go for lunch today? All of these are decisions that deplete your willpower. The professional in you will tell you to work harder, while the energy saving instincts will tell you to rest.

To save yourself from that strain plan your day at the end of the previous one. The procrastinator in you will no longer be able to have his say, and you'll save yourself a ton of decision making the next day.

And after you do your planning stop thinking about work. At least consciously. The author continues:

If you need to do a math calculation, only your conscious mind is able to follow the precise arithmetic rules needed for correctness. On the other hand, for decisions that involve large amounts of information and multiple vague, and perhaps even conflicting, constraints, your unconscious mind is well suited to tackle the issue.

The implication of this line of research is that providing your conscious brain time to rest enables your unconscious mind to take a shift sorting through your most complex professional challenges. A shutdown habit, therefore, is not necessarily reducing the amount of time you're engaged in productive work, but is instead diversifying the type of work you deploy.

Let your unconscious brain work for a change.

Redefine Your Tasks

What's easier: replying to twenty emails, or replying to one email?

Split up your work into small, easy chunks. Ones that will make you say: "okay, this next task is small enough, I'll just do one more and only then I'll grab a coffee". And after they're all done you won't even want your coffee anymore.

So instead of "Write Feature X" your task becomes a list:

Write simple prototype
Write tests
Make code look nice
Create a PR
Get reviews
Merge PR

Would you want to go for coffee now, if all that's between you and that nice fuzzy feeling of accomplishment is pressing the merge button? Or would you rather press it now, and enjoy the rest of your day guilt free?

Increase The Punishment

You evolved in an environment in which humans died from hunger - your brain will always choose conserving energy over work if given the choice.

If there are no negative consequences of slacking then you will find new, creative ways to slack.

You can introduce negative consequences by increasing visibility. If you're perceived as slowing the team down you'll feel shame - your brain will want to avoid that!

Are daily standup meetings effective because they improve communication, or because nobody wants to be the one saying "I browsed Reddit all day yesterday"?

Increase The Reward

Parkinson's law states that:

work expands so as to fill the time available for its completion

Unless you live under a rock you'll occasionally read that if a company introduces a 4-day workweek or reduces the number of hours worked per day productivity stays the same, or even increases.

If you allow yourself to finish work early, your brain will stop coming up with ideas on how to fill up time and rather will find ways in which you can finish faster.

Reduce Your Push-To-Merge Time Automatically

With all these insights in mind I wrote a tool that automates some of these points.

Code Dog will post a list of your team's open Pull Requests to a Slack channel.

The application is designed to:

Identify blockers
Identify next steps required to keep the momentum going
Increase visibility
Reduce reaction time

It supports GitLab and BitBucket. For GitHub see Pull Reminders.