Skip to content

Writing

Why a Personal Website?

Moshe Katz

Moshe Katz / April 13, 2021

11 min read

It was late at night, I was scrolling through my twitter feed and could swear that everyone was purchasing *.dev domains - it was only reasonable that I'd impulse buy one myself with moshekatz.dev.

That same day I also deployed my own blog, inspired by Dan Abramov's overreacted.io, and just like that, my personal website was live.

Happy ending, right? 🎉

Except two years later the only blog post I had written was a "temporary" placeholder titled "Hello World".

Moshe Katz website with only one post titled "Hello World"

That's right, I didn't write a single post in years.

But I want to change that, and this post acts as the first step in the way by helping me:

  1. Start creating content - by actually being the first post I'll publish.
  2. Sustain a content creation habit - by purifying the "why" of a personal website and the principles I plan to follow in order to stay consistent over time.

From a Content Consumer to a Content Creator

I want to become a better developer.

I want to become a better developer, so I read a lot of technical blog posts, educating myself with lessons learned and fresh perspectives. However, I've never shared my own post with the world (well, at least until now).

I want to become a better developer, so I npm install every single day, reusing other developers solutions to common problems. However, I rarely npm publish.

I can go on and on - taking courses, listening to podcasts and watching conference talks in contrast to teaching, recording and speaking.

These are all content consuming actions, lined up with the opposite content creating actions, indicating I consume much, much more than I create.

Now don't get me wrong, I find consuming content extremely valuable, as I consume everyday. It helps me grow not only as a developer but also as a somewhat knowledgeable person overall.

Yet, I believe that certain value can only be obtained by actually doing, creating and sharing - by making the transition from a content consumer to a content creator.

A Better Developer?

In general, creating content enables you to grow your development skills as you:

  • Learn more efficiently by applying what you learn.
  • Save time for future you, and potentially others, by allowing to reuse existing solutions, perspectives and mental models.
  • Improve your communicate skills, through clear writing, speech and code.

More specifically, there are two aspects of content creation that I find most suitable when starting to build a content creation habit:

  • Writing
  • Open sourcing

In the next sections I'll lay out why I think investing in them will actually make you a better developer.

Why Writing Will Make You a Better Developer

Good developers write. a lot. and not "just" code.

Here are some examples:

RFCs

As explained in the reactjs/rfcs repository:

The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project.

This process, in the format of a written structured template, forces better thought and better understanding of what's more important than what, and how things are related - resulting in better, more informed decisions.

Here are some RFCs I found interesting:

Documentation

This quote from Dave Nunez's article from Increment's documentation issue summarized the importance of documentation so well I'll just attach it:

GitHub’s 2017 Open Source Survey lists “incomplete or confusing documentation” as the number one problem encountered in open-source software development, observed by 93 percent of respondents. Yet 60 percent of contributors said they “rarely or never” contribute to documentation. GitHub concludes that “documentation is highly valued, but often overlooked”.

Tom Preston-Werner even suggests to start with the docs and not the code in his great post about Readme Driven Development.

Moreover, some companies, like Stripe, are known for their developer-first approach and outstanding documentation, which results in a massive growth and super happy customers:

Here are some documentations I was highly impressed by:

Development Roadmap

Building trust between a developer and his product/library users is hard, and development roadmaps are one of the best ways to do so.

A roadmap sometimes comes in the form of a blog post that reflects the plan forward, why some decisions were made, how will the migrations/deprecations/new features might look like and what you can do ahead of time to make the transition as smooth as possible.

Here are some of the development roadmaps I found great:

Blogs

Some of the best developers I follow on Twitter just happen to write excellent blog posts - I don't believe that's a coincidence.

Here are some of my personal favorites:

Verdict: ✅ Writing consistently over time will make you a better developer.

Why Open Sourcing Will Make You a Better Developer

Good developers contribute to open source. They often build in the open.

In general, open sourcing allows you to become a better developer as you:

  • Learn from code written by other developers.
  • Get your code reviewed by the community.
  • Practice decision making, prioritizing and marketing.

There are also indirect advantages to open source, as you grow a network of connections, boost your resume and in rare cases might even lead to a whole new business.

A Potential Business?

More often than not, open source creators/maintainers are not rewarded for their hard work, as Kitze once wrote: "GitHub stars won’t pay your rent".

However, there is an emerging business model where an open source project raises awareness and usage to a tool, while the creators make a paid service with a value proposition that is based on that tool. Here are some examples:

Also, here are some examples to open source projects being built in the open:

  • egghead-next - the frontend for egghead.io.
  • excalidraw - virtual whiteboard for sketching hand-drawn like diagrams.
  • spectrum - simple, powerful online communities.
  • reach-ui - the accessible foundation for React apps and design systems.
  • supabase - the open source Firebase alternative.
  • moshekatz.dev - this website 😊.

Verdict: ✅ Open sourcing will make you a better developer, and might even open up interesting career paths.

The Principles

Forming a habit requires first sticking to a routine, and those are the principles I plan to follow in order to achieve that.

Learn in Public

Shawn Wang (or as I refer to him in my head - "The learn-in-public Guy") already wrote a great post about this topic.

I've probably re-read this post a thousand times by now, so why not just share a part of it in the form of a conversation with my head:

You already know that you will never be done learning. But most people "learn in private", and lurk. They consume content without creating any themselves. Again, that's fine, but we're here to talk about being in the top quintile.

Top quintile? I guess this content creation habit is a thing after all. OK, I'm on board, but what content should I create?

Whatever your thing is, make the thing you wish you had found when you were learning. Don't judge your results by "claps" or retweets or stars or upvotes - just talk to yourself from 3 months ago. I keep an almost-daily dev blog written for no one else but me.

And what if no one will ever read this?

Guess what? It's not about reaching as many people as possible with your content. If you can do that, great, remember me when you're famous. But chances are that by far the biggest beneficiary of you trying to help past you is future you. If others benefit, that's icing.

Thanks Shawn, always a pleasure.

(p.s - here's the link to the post again, I recommend reading it in its entirety if you haven't)

Dogfooding

As explained by JetBrains in their article about the topic:

In the software development industry, dogfooding is the practice of testing your products within your company, using them as the end users would. Effectively, you have to eat your own dog food to ensure that your product is of the highest quality.

In my opinion, there are 2 main advantages to dogfooding when creating content, and especially when creating software - the first is sustainability and the second is a better end product.

Sustainability

When using your own open source software, you're motivated fix bugs and add features as you, as a user yourself, directly profit from those.

The same applies to a blog post you wrote and re-read or references to in the appropriate context.

Simply put, the intentions of the creator and the user are mostly aligned, hence, making it sustainable to maintain over time.

Better End Product

After learning how JetBrains utilizes dogfooding to make better software, let me also quote the engineering team of Facebook on the topic, from their Introducing Relay Hooks blog post:

But new does not mean untested: the rewritten facebook.com is entirely powered by Relay Hooks, and these APIs have been the recommended way to use Relay at Facebook since mid-2019.

So APIs that were released in March-2021 powered facebook.com over a year before the release - that's some confidence.

Let's look at another example, again, related to Facebook's engineering culture:

The only reason the bug got caught before rolling out to the public is the process of dogfooding. Less production bugs => better software => happier users. Sounds good to me.

In addition, I was surprised to find out the amount of successful projects that started as a "solution to my own problem", thus were inherently "dogfooded" - for instance, React and Tailwind CSS that actually powers the current version of this website.

Put the Content First

Creating content should be easy, and shouldn't be dependent on other tasks (e.g., a website redesign).

Publishing content should be frictionless.

As smooth the content creation pipeline is, the less excuses I have to not create - that's the magic of "making the right thing the easy thing".

Here are two products that implements this principle brilliantly:

Also, here are some blog posts that really got me thinking about this mental model:

Closing Words

The combination of consuming and creating content, consistently over time, will make you a better developer.

Balance is key though, and it's not a 0 or 1 scenario, as:

  • if you'd never consume, you'd stay in the same place.
  • if you'd never create, then why did you just learn?

So to wrap up, inspired by this tweet from Guillermo Rauch, I'll try to close out with a call to action for every developer reading this:

Create content. Not too many. Mostly write, words and code.

Discuss on Twitter • Edit on GitHub