This post really resonates with me, especially points 1, 3, and 5.
I started blogging in 2001. I have old articles lying around that are completely obsolete - about PEAR, Swing, GWT, Subversion, etc.
I did it to share without having any idea who was reading or not. Probably nobody back then.
But it became a habit. Beyond tech topics, I started blogging about broader subjects: organization, hiring, salaries, company building.
And it's incredible how much I relied on it later as a sort of documentation, especially for everything related to company building. It's so valuable to re-read why we made certain decisions in the past. And it's also so valuable to be able to point new colleagues to that knowledge base.
And technically, I had fun. I went through Joomla, self-hosted WordPress, wordpress.com. I built my own plugins. Then I developed my own open source static blog generator (bloggrify.com) in the Nuxt ecosystem. That's when I created an English version of my blog.
Then I started feeling the need to share differently. I had the impression that blogging was becoming outdated, that younger generations weren't reading anymore. So I tried video format on YouTube.
I really enjoyed video production - there's still so much to learn: equipment, techniques, new tools.
But I realized that each format has its pros and cons. It's so much easier to update text when it becomes obsolete. It's also so much faster to produce. Video is so hard to make.
So I got back into writing and even took it further by creating a blogging platform (writizzy.com).
In short, I learned a lot because I documented everything I did, which forced me to dig deeper into each topic to avoid saying nonsense.
I also learned a lot because I wanted to test approaches, make videos, learn to build a static site generator and many other things, purely for the sake of learning.
Today, one piece of advice I give to every senior dev is to take the time to write. Doesn't matter if it's to publish somewhere or not. But to lay out your ideas, dig deeper into them, get perspective.
Thanks for this perspective—I'm the author, and I'm actually back to freelancing/solo now.
You're absolutely right. Staying senior and not chasing Staff+ roles is a totally valid choice. I was CTO at this company, but in previous roles, I personally aimed for more impact, not out of ambition or to play the game, but because I wanted to.
I wanted to move the product, shape the direction. I felt I could contribute beyond just my dev capacity, and that brought me satisfaction.
More importantly, we built this career path to give people who wanted to grow an alternative to pure management. That was the whole point: creating options.
But everyone finds fulfillment differently. I'm not saying this path is for everyone. Just sharing what worked for me and how we structured it at Malt.
I get the impression I hit a sensitive spot with my use of "enshittification" :)
Sorry about that. I realize this term has a very strict meaning in English, but it's a bit less true in my language (French).
I responded to this in another comment above, but basically I was using the term to encompass everything that contributes to degrading a product. Everything that makes it more complex, often tied to company growth (I started a company in 2012 that's now 700 people).
But I get the point. I see this touches on another topic around corporate malpractice. I honestly wasn't even aware of that.
Fair point. I realize that "enshittification" has a more specific meaning in English (I'm french). My bad
I was using it in a broader sense, connecting it to my previous company (700 people, I co-founded it in 2012).
I was thinking more about all the factors that increase product complexity, and it's far from being just about shareholders:
* The more people you add to a company, the more complexity you add because inherently, everyone wants to leave their mark. In the end, some people see themselves grow because they contributed to this or that new feature. Doesn't matter if it's redundant. Doesn't matter if 10 months later you realize it adds nothing. I've unfortunately seen this pattern repeat itself over and over.
* The bigger a company gets, the more it needs to respond to increasingly specific use cases. A salesperson tells you their client needs this. Customer support tells you a portion of your users are asking for that. Either you have enough perspective to say it doesn't fit your vision, or you don't, and you try to please everyone. But it's a huge source of complexity. And I could cite tons of examples from my old company.
And just to be transparent, I am using my blog as a journal, with short posts. I was not expecting that much traffic and I totally understand that it's maybe not as deep as you would expect ^^
If you're interested in the specific thing that other people mean by that word, the original Cory Doctorow essay that coined it is well worth a read:
https://pluralistic.net/2023/01/21/potemkin-ai/
Of course he followed it up with a book, so there's that as well if you want a deeper dive, but the essay is fairly comprehensive at least in laying out what he intends by the term.
You're right. I wrote this quickly after talking with Thomas, and the homepage example reminded me of these scalability issues I faced with my previous company (Malt).
I connected it to simplicity and focus. In my head the link was clear, but I get that it's not as obvious when written :)
I'm using this blog as a kind of journal—short posts, quick thoughts. So I totally understand if it leaves you wanting more.
Honestly didn't expect this much traffic, my other posts have just been read by friends ^^
I did it to share without having any idea who was reading or not. Probably nobody back then.
But it became a habit. Beyond tech topics, I started blogging about broader subjects: organization, hiring, salaries, company building.
And it's incredible how much I relied on it later as a sort of documentation, especially for everything related to company building. It's so valuable to re-read why we made certain decisions in the past. And it's also so valuable to be able to point new colleagues to that knowledge base.
And technically, I had fun. I went through Joomla, self-hosted WordPress, wordpress.com. I built my own plugins. Then I developed my own open source static blog generator (bloggrify.com) in the Nuxt ecosystem. That's when I created an English version of my blog.
Then I started feeling the need to share differently. I had the impression that blogging was becoming outdated, that younger generations weren't reading anymore. So I tried video format on YouTube.
I really enjoyed video production - there's still so much to learn: equipment, techniques, new tools.
But I realized that each format has its pros and cons. It's so much easier to update text when it becomes obsolete. It's also so much faster to produce. Video is so hard to make. So I got back into writing and even took it further by creating a blogging platform (writizzy.com).
In short, I learned a lot because I documented everything I did, which forced me to dig deeper into each topic to avoid saying nonsense. I also learned a lot because I wanted to test approaches, make videos, learn to build a static site generator and many other things, purely for the sake of learning.
Today, one piece of advice I give to every senior dev is to take the time to write. Doesn't matter if it's to publish somewhere or not. But to lay out your ideas, dig deeper into them, get perspective.