DEV Community: Kirill Rogovoy

No architecture is better than bad architecture

Kirill Rogovoy — Tue, 22 Nov 2022 17:03:10 +0000

It took me several years to learn how to write code that scales to 10s of team members and a million lines of code. It took even more time to learn to write stupid code again.

Turns out, "building a solid architecture" in your code can easily be busy work and procrastination.

Turns out, you can waste a lot of energy trying to get rid of all code duplication and coming up with powerful abstractions to support "future use cases."

Turns out, one part of your code can intentionally be a well-thought, protected piece of engineering marvel, while the other one should get you fired.

When you first learn the "best coding practices", somehow you assume that there is a clear line between good and bad architecture. You read or hear horror stories about unmaintainable projects with too much rotten spaghetti code. Inevitably, you end up working on one.

You start grasping what it means to separate concerns, extract abstractions, invert dependencies, and so on. Once in a while, you get fewer than 50 comments on your pull requests. Now you feel like a real deal!

Those horror stories you heard... they were real. Without enough care, forethought, and discipline, a project gets messy faster than expected. You see spreadsheet after spreadsheet of "prioritized tech debt" that doesn't get fixed anyway because you need to ship. And the only person who still knew how things worked has just quit!

But all that is in the past. Over the years, you've developed a dozen heuristics and found the best rules that prevent your code from being rewritten two years down the road (now it's three years!) Yay!

Going far or going fast

So far, I've been describing what I like to call "going far with code." Anyone can write code that lasts days before becoming unmaintainable. Learning to keep codebases alive and thriving for years of active work takes practice, tears, and a few rewrites.

Now, if you work for an organization with (a) enough resources and (b) high certainty of what you are building, going far would be your most important hard skill. To a large extent, that's what would make you a Senior Software Engineer and pay your unbelievable salary.

However, if you've ever worked with startups or founded your own for-profit projects (lacking in both resource and certainty), you'd quickly point out that "going far" is not what's on your mind most of the time.

Going fast is.

Turns out, architecting code—introducing granular concepts, abstractions, relationships, and giving all those things names, scopes, and responsibilities—has a cost. On top of that, undoing such structures is 10 times more costly than building them.

Because of the time pressure, you will more likely be adding more and more stuff to leaky abstractions than tearing them down and rewriting the whole scope.

Another risk is that architecting and structuring your code is a great and fun way to procrastinate. As a technical founder, I don't like many things I have to do to run a successful project. Tinkering with code often just feels like a refuge from all the anxiety generated by things I should be doing instead.

A lot of time, the costs of creating too much structure are more nuanced than "quality takes time." For one, more often than not, you simply don't know what you are building yet, in the grand scheme of things. Most code will end up being thrown away or rewritten as you get closer to product-market fit, and rarely is it easy to know which code will stay, so you tend to treat almost all code as temporary.

So what's the optimal solution here? Do we really have to go back and start writing the same shitty code we did at the start? That doesn't sound right!

Writing stupid code well

I don't think I have the best answers yet.
However, let me share a few practical heuristics I've learned, that helped me avoid poor outcomes of both extremes: an unmaintainable project or terribly slow velocity.

1. No code is equal

As with many things, there are a lot of cases of Pareto distribution in your code.

The first time it occurred to me was when I tried to figure out how to write as few tests as possible that would provide the largest improvement in stability. It quickly became apparent that only a tiny part of my code is called most often and, should it fail, would bring the most trouble.

So, I extended the same model to deciding where I should put extra time and care and sacrifice some velocity now for long-term benefits.

I have a 3-year-old SaaS with 60k lines of code. When I started to pay attention, I was surprised to see that most code I didn't read or edit for months (or ever). Most API endpoints, most UI pages, etc. Also, a lot of that code was called orders of magnitude less often than the other.

And when I saw copy-paste and giant do-everything-at-once functions, I was weirdly so relieved I didn't waste time refactoring that. I mean... it works! I can still understand it well and make changes. I could invest a couple of hours in structuring it better and saving myself a few minutes the next time I work with it... in a year.

To be clear, I'm not advocating for writing bad code with a lot of smell per se. Instead, I mean writing simple code that often mixes the higher-level flow with lower-level details without being obsessive about areas of concern. It can still be elegant to an extent. It should still represent the intent well and explain what it does.

Another helpful trick here is fencing off the most important parts from the rest so that tar doesn't spill into your honey.

2. Let it beg for structure first

If the previous analogy was to writing tests, this one is going to bring up performance optimization.

One of the best heuristics regarding performance is that all improvements should be made with a profiler in front of you – No guessing!

I'd argue the same is useful for refactoring.

It's much easier to come up with generic cases (abstractions) when you already have 3-4 specific cases (often with code duplication.) Let those cases emerge first. That way, you won't have to predict the future anymore but rather just structure what's already there.

In other words, be moderate with removing (or preventing) code duplication and repeating yourself in general.

This idea is so popular that it has a Wikipedia article that refers to a book written in 1999!

It's not an absolute rule. Sometimes, especially in the case of utility functions, you just know that you need to make a building block first and then use it everywhere. Trust your intuition, but make sure you are conscious about the choice.

3. Always start with one

I find this concept so useful that I'm going to write a whole article dedicated to it.

The rule is pretty simple: Unless you have a strong argument against it, start with file, class, function, table, etc.

As with creating abstractions based on existing cases, splitting things up is always easier once you already have some material to work with. This way, you won't have to guess which buckets things will go into in the future.

Starting with one is a reliable (though radical) way to remove many mental barriers keeping you from actually delivering something.

As with other rules, there are perfect reasons to break them. Trust your intuition, but make sure you aren't procrastinating or putting off the actual work.

One example people often bring up is how Pieter Levels essentially had one index.php file for a business that generated crazy revenue.

That's it!

I guess the one-line summary is this: If you want to move fast, you have to put off building the architecture, and if some of your code is shit, at least let it be soft.

As always, thanks for getting this far.

If you liked this post, you might like those that will follow.

Follow me on Twitter at @krogovoy.

See you next time! 🙌

How I launched Impulse.dev

Kirill Rogovoy — Wed, 12 Oct 2022 09:49:14 +0000

I've been working on Impulse for six months, and a few weeks ago—Sep 28—I decided to finally make an official launch.

In this post, I want to reflect on what happened before, during, and after that launch. What I've learned and what I could have done differently.

I've never understood the grandiosity of Launching The Product. Don't you just post a bunch of links on websites with tons of traffic and cross your fingers?

It turns out you can definitely do that, but it will likely depend on luck more than you think. I had to do it the naive way to learn this lesson.

Before we get to the lesson, though, let's start with the inputs. I'll talk about what I had before the launch, the decision to launch now (not sooner nor later), and what came out of it.

Input 1: Product

Impulse is an open-source dev tool for web developers. It's free, and there's no business behind it.

It means several things:

There's no marketing budget. Putting money into acquiring users doesn't generate any money at the other end. So the decision here is to not put any money into the launch.
The target audience is developers. More specifically, people who use React and TailwindCSS. Developers are opinionated, and the market is tricky.
I can't (and am not incentivized to) apply any limited-offer kind of marketing, such as promo codes.

Also, Impulse is a single-player tool with no room for product-led marketing and no easy access to virality.

Having been in active development for six months, it went from "extremely buggy" to "slightly buggy" (the industry standard!) and also got a complete redesign a few weeks before the launch.

Input 2: Existing Impulse users

Impulse doesn't have any form of telemetry, so it's hard to say how many daily/weekly users it had. That's an unfortunate downside of running a browser-only self-hosted tool. I might decide to start collecting some minimal anonymized data in the future, but it's a tricky subject.

So the only data I had about users was anecdotal. Other than myself and my co-founder, I knew of just several people who would use Impulse sometimes.

There is, however, a secondary metric that at least can show some dynamics - downloads from NPM:

July: 299
August: 332
September (before launching): 409

One should not rely on this data in general because:

An undefined % of downloads is automated: bots, CI, local hooks, etc.
It's impossible to tell the retention. An undefined % of real people could uninstall the package just a few minutes after the download, and I wouldn't know.

However, you can still use these numbers to have some idea about the relative change in overall usage.

Some other product-related numbers before the launch:

30 Discord chat members
94 Github stars

Input 3: Personal audience

I had not been doing much publicly before starting Impulse, so the circle of people interested in hearing from me was close to "nobody".

Still, something is better than nothing. The numbers were:

140 followers on Twitter.
50 email subscribers from my previous writing.

I didn't have a vast private network either: just a handful of people who are relevant to the product and would be interested in helping me out.

Last but not least, I hadn't spent much time in development chats or communities. A few comments on HN, an argument on Reddit, and five minutes of scrolling Twitter are the limit of my online social activity for the day. Most of my social life happens offline.

So I'm not a recognized member of any specific online dev community.

Oh, and I don't have a day job, so there are no colleagues other than my co-founder.

Why launch now?

Arguably, the main risk here was launching too early for several reasons.

First, your product might be too raw, so even in the case of a successful launch, not many people would stick.

In the case of Impulse, we've been dogfooding it for long enough to hunt down most bugs and develop a usable, familiar, and pleasant UI.

Second, it's essential to communicate your product's value and what it does. Things like the website copy, README, tag lines, pictures, demos, etc.

I've struggled to explain what Impulse did and why since the beginning. I'm still not happy with that part, but six months was enough for better wording to emerge.

Third, I tend to see product launches mainly as multipliers of whatever traction you already have. There's a lot of luck involved, but your existing users and audience are, I believe, essential to a good launch.

For Impulse, the user base was definitely a weak spot and a good reason to push the launch back, but here's why I decided to go for it.

I've been working exclusively on this project for half a year and... I don't really know where it's going. One of the primary goals from the beginning was to make a product I could use for most of my UI work. And oh my God, have I achieved that. Having used Impulse regularly for months (including designing Impulse itself and impulse.dev), I can't imagine going back.

However, the other goal, expectedly, was to see if other people needed it and make a product that would be great to use for others.

It would be hard to continue to work on a product no one needs. And to figure that out, I need a stream of feedback. I need to test the demand.

Hence, launching Impulse was supposed to provide some clarity on that front. Ideally, you should have done more marketing and talked to the users more. In practice, I was past all of my deadlines for getting meaningful traction.

Before the launch day

"He who has begun has half done." — Horace

One lesson I could take away from the "launching guides" was that you have to pre-launch your launch. People should know you are launching, and posting a few teasers about your product doesn't hurt either.

So once I knew the launch date (I set it a few days in advance), I let the people know via Twitter, Discord, and email.

Kirill Rogovoy

@krogovoy

After a ground-up redesign, I'm going to finally launch Impulse the next week! 🎉

Wish me luck, haha

If you use it, please upgrade to the latest version and tell me what you think.

If you don't, now is the best moment to try it out.

11:28 AM - 23 Sep 2022

I could probably take it somewhat further, but I was too lazy. One missed opportunity here is that I could reach out to many more people privately, hoping they would upvote my postings, but it felt too ingenuine.

Another pre-launch thing you can't ignore is simply making sure that your website is accessible and fast, the meta tags for social sharing are set correctly, and Google indexes what it needs to index.

As I would learn, most of the launching happens before the launch day. It's not hard to press a bunch of "submit" buttons. The hard part is creating enough momentum for your launch to have a real effect.

Those include working on:

Brand awareness
Communities
Twitter following and capturing emails
Press coverage
and much more

But why do you need all that?

Well, if you want tons of people to see your product, you need a lot of upvotes, right? More upvotes -> more people see it -> more upvotes, and so on. Of course, it's not cool to ask your whole extended family and ex-classmates to create Product Hunt accounts and go vote for you. Such behavior will quickly get you in trouble.

But nobody said you couldn't broadcast your launch on the internet and "let people know."
(Product Hunt explicitly allows you to ask people to come to visit and comment, but not vote).

Another reason is that the second you submit your posts to websites like Product Hunt or Hacker News, that post stays in some sort of limbo: Unless enough people upvote it within a short period of time (the difference even between 0 and 10 upvotes at this point is huge), the post might never really surface. So you need that kick-starter crew more than anything.

Now, this whole tactic may seem ingenuine. Shouldn't the product's rank depend solely on the product itself?

In theory, it should. In practice, it is an ideal that's impossible to reach. It's a game, and games are played. Can you have a successful launch without all the preparations? Absolutely! Just less likely.

Again, you shouldn't ask people to upvote your posts. But everybody just knows that's what you want.

Anyway, as I would realize, most launch preparations are too late to do when the launch is tomorrow. Strategically, a successful launch should be just a culmination of months of marketing.

Hence, I did what I could still do: make a few public posts and talk to several people.

The lesson here is not to think about your launch date from day 1 of the project.

The lesson is that launching your product is just an extension of your marketing efforts overall.

Want to have a great launch? Do great marketing consistently for several months leading up to the launch.

Launch day

The plan was to launch on:

Product Hunt
Hacker News
Reddit

Because Product Hunt has the concept of daily ranking (everybody wants to be the #1 Product of the Day), the first thing I did was craft the PH post, submit it, and add a PH link to impulse.dev.

Then I would send a new series of posts on Twitter, Discord, and email.

Kirill Rogovoy

@krogovoy

It's on! Impulse is on Product Hunt! 🏆

producthunt.com/posts/impulse-…

I have no idea what I'm doing. :)

07:12 AM - 28 Sep 2022

A few hours later, I'd make a Show HN post and then 8 Reddit posts (to different subreddits) 20-30 minutes apart. Because I prepared most of the texts and media in advance, this process did feel like just pressing a bunch of submit buttons.

That was it. All I had to do was wait and react to comments.

It felt like opening a new store and sitting in an empty space behind the counter, waiting for someone to arrive.

And someone did!

Expectations

Before getting to the results, think about what expectations you would have about this launch.

My thinking at this point was that, with a tiny audience and lack of marketing before the launch day, the results would mainly be up to Math.random() of the world.

Sure, I tried my best to write the copy, make the landing page, tag lines, and so on. But I couldn't control much beyond that.

So any outcome, including (or especially) having 0 views, was expected.

Results

Product Hunt:

47 upvotes
10 comments
Day rank #27
186 unique LP views

Hacker News:

1 upvote
16 unique LP views

Reddit (total for 8 posts):

193 upvotes
55 comments
893 unique LP views

There were also 787 unique LP views with an undefined referrer and a long tail of isolated visits from random places.

Ultimately, it amounted to about 2000 unique LP visits within 48 hours after the launch.

For comparison, my blog post that kicked off my work on Impulse had 20k page views just from Hacker News.

Other effects:

94 -> 180 Github stars
30 -> 39 Discord members

Was this launch a success?

Yes and no.

On the one hand, 2k views and #27 Product of the Day are not what you typically see in articles about launches.

On the other hand, it did get things moving.

impulse.dev's typical daily traffic grew from {'<'}10 to about 50.

One week after the launch, Impulse got featured in tldr.tech, which generated 2646 page views, more than from launching, but I doubt that Impulse would have been spotted without the launch.

As for the actual users, several new people came to Discord and Github with questions and issues, which I tried my best to resolve. A few people left positive feedback about their experience too.

I still don't know how many people use it consistently, though.

Lessons learned

Ultimately, I'm not happy or sad about this launch because I think I set the right expectations. It did give Impulse a boost, but it's just one drop in the sea of marketing that needs to be done to take it to the next level.

Several things I'd do differently:

Reach out to more people privately and tell them about the launch.
Maybe reach out to all stargazers with public email, but I'm still 50/50 on whether or not it's spamming.
Launch on more websites. Especially since Impulse is 100% open-source. There are many more places it could have been featured (and still can, only independently from the launch).
Think about the launch day one month prior to it instead of several days.

"There are no silver bullets, only lead ones." – Ben Horowitz

Anyway, the journey is far from over. Impulse is definitely entering a new stage, and I'm excited to learn what it means.

Stay tuned!

And, you know, why not give Impulse a star?

I quit my business to start an open-source dev tool

Kirill Rogovoy — Mon, 25 Jul 2022 13:16:23 +0000

This is a story of me quitting my job as a web dev, starting my first SaaS, burning through all of my savings, and finding what I really wanted to do.

Also, this post is my attempt to start sharing my honest experiences, however good or bad, on the internet. Both as a form of journaling for myself and as a case study for the community.

I want these to be more like personal letters and less like self-promotional feel-good traffic-generating positively-thinking marketing posts.

I want to stay vulnerable and honest.

It's going to be ugly.

Quitting my job to start an online product

In January 2020, I quit my job as a web developer to start a SaaS with a partner. It was the boldest move I've ever made in my professional life. I was scared but unbelievably excited. Starting my own project has been my gestalt for years.

It's finally happening!

I was very lucky to have been making more than I've been spending for several years and investing that in S&P500 during the bull phase of the market. It resulted in enough savings to not think about money for at least a few years.

Looking back, I can't help but think that having too much cash runway can jeopardize your venture: too easy to get comfortable.

We didn't know what we wanted to build. Still, we wanted to work together (having been colleagues for 3.5+ years), and we knew that the stars might not align again in the future.

With a sense of freedom but also immense pressure that I couldn't explain, we started to brainstorm ideas. At that moment, neither of us had something he had always wanted to build (and that would also qualify as a viable business opportunity), so the process was a combination of looking inward and seeking gaps in markets.

It was the first time I internalized that the price for all the freedom I felt at the time was the heavy burden of uncertainty. Before 2020, I had been a web developer (with a mixture of leading teams, product management, analytics, and other things) for 7 years. There had always been someone to tell me, at least on some level, what goal should be achieved.

Being able to do whatever I wanted did not taste as sweet as I had pictured. It felt like we could make any number of bad decisions, and there was nobody to tell us that.

However, that feeling was also one of the best exercises for taking responsibility for your life. In the end, dealing with uncertainty and taking personal responsibility for tough decisions are things you train by practicing, not learning from books.

I'm so tempted to say that, in hindsight, that experience has taught me to take ultimate responsibility for my life decisions and made me an exceptionally self-directed person. But it would be a lie. I'm 2.5 years into "doing whatever I want", and, at best, I've learned to freak out less. Being truly responsible for one's each and every decision is tough. Not as a concept but as a practice.

Taking on food tech

Those few days of brainstorming and scoring different ideas using a dozen factors finally led us to the one problem we chose to solve.

We wanted all restaurants and cafes in the world to have modern digital menus with high-quality photos of each meal, and the ability to take orders online. (Keep in mind that we are still several months away from the worldwide pandemic.)

We also saw a business opportunity: why wouldn't restaurants pay us for a significant improvement (in our minds) of the experience of their visitors.

We called our project Foodba simply because there was a cheap-ish .com domain.
I know.

What we didn't see at the moment is that we only cared about the visitors. We knew nothing about people running restaurants, nor did we really care.

Being blind to that, we ran 10s of "customer interviews" with almost everybody telling us that having those digital menus would be great. None of those people were running restaurants.

Had we talked to people that we actually expected to pay us, the whole venture would have been different.

Anyway, we ended up building an MVP and leveraging our personal networks to find first several customers that would agree to use our product for free. In return, we could study how they operated in general, along with their specific feedback about the product.

We actually enjoyed this period. We had to do everything: build the product, talk to customers, design and print QR codes for them, and even take professional photos of 100s of meals. We were hustling!

We didn't make money yet, but it already started to feel like a hell of an adventure.

Wear masks and keep distance

Then Covid happened. Ouch!

Undoubtedly, it has shaken almost every industry, with the hospitality businesses being especially vulnerable. Today you serve; tomorrow, you're closed. You launch takeaway, but nobody orders. You lean on delivery, but the food platform commissions only bring you losses.

To make things worse, nobody knew what to expect next, and everybody was cutting losses. There was no solid ground. Problems would come and go in a matter of weeks, so it was problematic to capture a specific pain that we could solve.

At the same time, we felt like we really worked hard and were productive. Finally, it really felt like "building a startup": talking to customers almost every day, building something to solve at least some problem (however fleeting), getting feedback, etc.

It was exhausting but somewhat rewarding.

Looking back, I think the pandemic was the real reason we had any traction. People in crisis needed help, and we wanted to be useful.

Even though it never felt like we found any product-market fit, in December 2020 (one year in), we had almost 50 paid customers. In June, we had none, so it felt like a success!

Also, every indie hacker knows that the feeling of people actually handing you money for something you've done is ecstatic. At least in the beginning.

By that point, people would buy our product for a bunch of different reasons. None of them were allowed to have paper menus, so some just wanted a better experience than an ugly PDF behind a QR code. Some wanted to run their own delivery. Some wanted to run Facebook re-targeting campaigns. Some just thought that it was trendy to have a digital menu.
Our "customer profile" was a mess.

Let's take a moment to reflect.

Two dudes spent one year building a product full-time. Results:

~$600 MRR.
No clear product-market fit.
No clear way for scaling.

By this point, the cumulative opportunity cost is in $100,000s.

Would you continue such a venture?

That's a tough choice.

We did.

Product-market misfit

Still thinking back on our decision to continue, it's worth mentioning that, of course, it's not just about money.

We have learned so much. Not just about building a product but sales, marketing, UX, you name it.

Persistence. We have learned how to not quit when things don't work.

In the end, working on the business was simply fun and fulfilling.

And so, we began scaling.

From this point, there were only three kinds of tasks we could afford to do:

Fixing something that's broken.
Whatever brings us new customers.
Whatever helps us spend less time on support.

Our problem with scaling was that we tried to do things as if we had a product-market fit without actually having it.

Usually, scaling your business means that you already have one or many sales/marketing channels that work on a small scale. You invest more time and money in developing them. You do it until you hit a point when growing it becomes more expensive than the potential output.

But it wasn't really our situation.

We were still unsure if our customer was closer to a hotel restaurant, a downtown tourist venue, or a local coffee shop.

A random venue from Google Ads would just sign up and use the service with no questions or assistance. At the same time, we would spend two days making custom QR codes and making a photoshoot for 60 menu items for a local restaurant in London, only to get ghosted. At least they fed us. Once.

It wasn't going well.

I still remember the adrenaline rush of cold-calling random Asian woks. Poor busy exhausted administrators couldn't understand what I was talking about. Can I just go back to coding, please?

Our search for whoever we thought was the customer and for a scalable channel to get them would continue for months. We tried cold calls, cold visits, cold emails, ads, SEO, flyers, referrals, partnerships, and more.

Somewhere around that time, I started to realize I didn't like what we were doing anymore. 😬

First, I didn't really care about our clients. I had zero friends who were in the restaurant business. I, personally, wasn't interested in how restaurants were run and what a life of a staff member would be like.

All I cared about was me and people like me, who, among other things, visited restaurants. But visitors weren't the ones who paid, nor could we find a reasonable way to change that.

Second, I started to get bored as a developer. In the beginning, I'd learn a thing or two about running serverless functions, working with AWS, or optimizing images. But a QR menu service, with all its specialized features, is just a CRUD app.

It wasn't a problem per se. It's not realistic to have an app that's fun and challenging to develop day after day. Most apps on the internet are CRUD apps with bells and whistles.

However, coding had for a long time been my shelter. The place I could go after a day of palm-sweating cold calls and enjoy doing something I was actually good at. But for whatever reason, coding stopped being that place, and I didn't want to make things more complex just for entertainment.

Another sign of disliking the project was that I didn't want to discuss it with other people anymore. I felt ashamed but didn't know of what. I felt ashamed of feeling ashamed too.

And that's how 2021 went. We kept trying to find the product-market fit. Every week it seemed like the breakthrough was around the corner.

Some things worked. Most didn't.

We ended up growing our customer base from 50 to around 150 that year, tripling our MRR.

For the most part, we discovered a thousand ways that didn't work for us. I would often think about that to comfort myself and make it look like we were making progress.

More importantly, we managed to reflect on the key turning points that led us to where we were;
our biases and blind spots that kept us digging in the wrong direction. Or was the direction right, but we just executed poorly? I wouldn't know.

After a long New Year vacation, we agreed that the project wasn't doing well. We didn't know what to do, but we surely were demotivated.

Goodbye Blue Sky

(I live in Ukraine.)

I don't remember much between Feb 24 and late March. It has condensed into one hazy memory filled with sounds of sirens, midnight doom scrolling, and moving places.

All I can say is that I'm lucky to be writing this post on a fancy laptop while sipping fresh filter coffee in the beautiful city of Lviv, with all my body parts appropriately hanging from the right spots.

This post isn't about the war, and I'm certainly not the one to have suffered the most, but you can imagine that an experience like that might make one reflect more on their life choices.

That reflection made it crystal clear that it was time to turn the page.

Luckily, about the time I ran out of my savings, which had supported me for almost 2.5 years, our business started to generate just enough profit for me to not look for a job or a side gig.

We jointly decided to keep the business operating and heavily automate whatever still required our attention. But we quit investing any new effort.

Finally, we were free to choose what would be next. All the anxiety of "doing whatever you want" came back in an instant, on top of not knowing what would happen tomorrow in my physical environment.

Lessons (not) learned

It might seem that two and a half years of running a SaaS app should have given me a lot of insight on how to properly do it.

It has not.

At best, I went from having no idea to having some idea about what I was doing. At the same time, it made me feel much more comfortable about being incompetent.

It completely dispelled the illusion that one must first get good at something and then do it. It doesn't make much sense if you are a heart surgeon or a pilot. But when it comes to doing silly things on the web, such as in my case, I found the scrappy just-do-it attitude to be the most productive.

Lesson 1: find users you care about

I've learned that it's essential for me to be able to relate to my users deeply.

Over the last few months, I've spoken to a dozen of developers I had never met before. Oh. My. God. What a contrast.

We could talk for hours. I understand them. They understand me. It feels more like two kids discussing toys. I loved it!

Comparing that to people who run restaurants, the difference in my attitude is stark.

Although typing curly braces isn't by far the only interest of mine, feeling that I'm "a part of the tribe" makes me want to contribute in a completely different way.

It also makes it much easier to actually use what you make.

When working for companies, I always felt the urge to improve the tools my team and I used. I don't know why. Instead of applying my craft and solving problems with it, I wanted to improve the craft itself. I wanted to think and talk about how we do more than what we do.

This realization made it clear: I want to do stuff for people I'm excited to talk to. Those I want to learn about even without having a project in mind.

Lesson 2: second order effects

Whatever project you do, there are always results that outlive the project: skills acquired, people met, doors opened.

Turns out, you can (and should) consider that when choosing what to do.

With Foodba, I didn't. Therefore:

I gained a lot of domain knowledge (food industry) I will not use.
I gained zero contacts that could be my future customers, partners, employees, employers, etc.
I didn't increase my "luck surface area."

That sucks because, as I stop working on Foodba, it feels like not much has changed since 2020. It doesn't feel like I gained any inertia. No unfair advantages. No trump cards to play.

This time, I can do better. At least by entering the domain where I see myself doing much more projects and creating long-lasting value beyond any specific endeavor.

Example? You are looking at it.

Tim Ferriss once said on his podcast something that stuck with me:

Even if this fails, are there skills and relationships that I can develop that will carry over into other things?

Lesson 3: pick the right kind of challenge

I want a challenge, but not any challenge.

The ability of an entrepreneur to do whatever it takes to get the job done is often romanticized. And for good reasons.

However, I've realized that I simply don't want to succeed at all costs. Doing what I love (most of the time) is in many ways more important to me.

There are skills I don't want to develop or activities that make me want to quit. Things like making cold calls, dealing with a lot of ops work, or writing SEO-optimized marketing posts.

Those aren't bad things to do. They are just not what fulfills me.

At the same time, there are a ton of difficult challenges I'm excited to take on:

Writing
Being proactively useful for the community
Build a community of my own
Mind-boggling tech problems
Building in public while staying authentic

Avoiding things I don't like doesn't mean I will stay away from opportunities that would work best if I did those things. I'll be happy to delegate them. I just want to make sure it's not something that's critical to do at the early stages.

Starting an open-source dev tool

Finally, pieces are coming together:

I like making tools
The tech community is my tribe
It fits the challenges I chose

To me, the tech industry is unlike any other field.

It's brutal in its own ways. But also uniquely rewarding.

It's highly competitive but fairly meritocratic.

I believe it to still be the Wild West.

And so, I've decided to give it a try. I'll do my best to be as valuable as possible to my tribe while explicitly doing things I enjoy the most.

That includes several (scary) things I've never done:

Starting a newsletter and this blog
Exploring social media as a platform to create value
Building in public while staying as honest as possible
Finally, making a tool I have wanted for a long time, 100% open-source

Impulse.dev: first baby steps

In April, I posted my first public article since 2018:
Writing HTML sucks and No-code doesn't help.

It brought 20K page views, 168 HN comments, and 40 email subscribers. Yay!

It might not seem like much, but it was nerve-wracking for a person who isn't used to any public attention or criticism.

Two months later, I released the first alpha version and recorded a 42-minute demo (I know!), available at impulse.dev.

Luckily, my partner from the previous venture joined me, so that period didn't feel lonely or like too much work.

I tried to write about our alpha release in Writing HTML sucks less with Impulse, but nobody read it.

When you spend several hours (or days) meticulously capturing your thoughts into text, and then nothing happens, you feel like nothing's worth doing anymore. :) But hey, it's a very long game, right?

Anyway, here I am, alternating between writing this post and thinking if any of this was ever a good idea.

I'm omitting a lot of details about building Impulse. This new journey deserves many more posts, and I'm already 3000 words in. :)

The last topic I haven't touched on is money. Everyone who ran open-source projects without significant backing from Big Tech would tell you that it's very hard to make a living off open-source. And they are right. I'd like to discuss it in detail in future posts, but it's definitely a long-term concern.

Follow my journey

If you liked this post, you might like those that will follow.

Subscribe to the newsletter using the form below, and follow me on Twitter.

If you use TailwindCSS, you might find impulse.dev useful!

See you next time! 🙌

P.S.
I spent more than a week doing nothing but working on this post. Writing is fucking hard. If you have reached this far, thank you.

Writing HTML sucks less with Impulse

Kirill Rogovoy — Thu, 07 Jul 2022 12:53:54 +0000

This post is a follow-up to Writing HTML sucks and No-code doesn't help that I published two months ago.

A quick recap of opinions I expressed in that article:

Writing HTML is slow and boring.
No-code tools are great but aren't suitable for a lot of projects. Also, developers don't like them.
When it comes to creating UIs, developers are the underserved customers.
Having a tight feedback loop is crucial. It's not tight enough when you need to develop the UI by writing code in the editor.
We can do better.

I've also suggested a solution. I wanted a tool that worked directly with my code, allowing me to edit the UI inside the browser.

I wanted a tool that's made for developers, with zero abstractions on top of HTML/CSS and a keyboard-driven UX.

Ultimately, I wanted a tool to make creating UIs fun and fast, without giving up on any of my code.

I wanted something that looked like this:

Two months and a few gallons of coffee in, as promised, I've made a prototype!

Introducing Impulse

Impulse allows you to edit your UI (think specific JSX code) visually inside your app by editing the DOM element.

Imagine if you could change the styles of any DOM element on the page using the Devtools, and it would be automatically saved to your code exactly the way you would do it yourself.

Impulse is that, and much more, but with a better UX.

It's completely local and open-source. No SaaS. No servers. No accounts.

It's built for React and works best if you use Tailwind. More on this below.

Most importantly, Impulse isn't a replacement for anything. It's an add-on. Just like Devtools, you use it when you need it and then stash it away.

Website: impulse.dev
Github: impulse-oss/impulse
Full 40-minute demo: https://youtu.be/QaTSsaGXCco

Why writing code isn't fast enough

I feel like it's important to reiterate the problem Impulse is solving.

Citing my previous post:

Sometimes, it's a 2-minute job. Fix some margin. No big deal. But sometimes I'd spend the whole day working on the UI, and the issue becomes much more apparent.

In that working-on-UI mode, writing HTML feels like trying to draw a picture by shooting arrows at the target. You shoot one, see where it landed, adjust, and shoot again. Code feels like the gap between you and the target.

We aren't blind to this problem. In fact, we got pretty good at shooting those arrows. Emmet saves us raw keystrokes, Tailwind (with its VS Code extension) saves us mental effort, Fast Refresh (aka Hot Module Replacement) shrinks the feedback loop, the browser's DOM explorer gives us some optics. We shoot those arrows from a machine gun.

But the distance is still there. The gap is still there. We are just traveling it faster.

Creating UI code is pretty damn fast in 2022. However, the constant context switching between the browser and the code editor hasn't gone away. And to me, it just feels wrong.

The feedback loop is tight but not tight enough.

It's not just speed. It's about fun too. For a long time, I hated coding the UIs. I loved the design phase, but writing the HTML down felt so boring.

Now I honestly look forward to it.

Why React

For one, it's what I've been using for the last few years, and it also happens to be the most popular front-end framework at the time of creating Impulse.

Another important reason is the little-known internal feature of React that allows you to know which DOM element was created by which piece of code with high precision.

I don't know if Vue or Svelte, or Angular do anything similar, but without that information, there's no Impulse.

I'm tempted to elaborate more on how it works exactly, but there's so much more to it, that it deserves a separate post. Please, let me know if you're curious!

Why Tailwind

In the demo above, I add the styles of the elements by adding Tailwind classes.

Tailwind has already been my go-to choice for more than two years,
but the fact that it uses utility classes for styling made it a great fit.

It also allows you to not come up with semantic names for styles which helps you tighten the feedback loop, which has been my goal in the first place.

Since using Tailwind is as easy as adding or removing classes, it naturally made it trivial to integrate with.

If you haven't used Tailwind, this project might be a great reason to try it out. Full-pledged support with auto-completion and other goodies is on its way.

What Impulse can do

Since Impulse knows the exact source code that created any given DOM element on the page, it unlocks some powerful features.

1. Edit classes

Use Impulse to add or remove classes from any DOM element, and it will also edit your code.

With Tailwind, it means that you can style any element without leaving the browser while seeing your changes apply instantly.

2. Add, move, and remove elements

With the ability to add styles, this allows you to create whole new UIs without leaving the browser. Again, all of the changes get saved to the source code.

Oftentimes I'd catch myself spending 30 minutes straight creating new UI in the browser without looking at the code even once. Then, when I do open the code, it's exactly the same code I would have written manually.

3. Jump to code

The most versatile feature I use on both new and existing projects.

There are a lot of things Impulse can't do, either conceptually, or just yet.

Impulse isn't a no-code tool in the sense that it'd discourage you from using your editor. In fact, most things are easier to do with code. Impulse is just trying to fix the boring parts.

So, every time you do need to switch to your code editor, save yourself some brain cycles by using this feature to instantly jump to the place you are looking for.

No more mental mapping between which exact code created that <div> you are staring at.

No more looking up the classes in Dev Tools to search for them in your code to find that node.

Just press C.

Feedback needed!

So far, I've been trying to create what's been missing from my world.

That's not the end goal but a necessary step.

I want to build what people need.

The best way one can contribute to Impulse is to give it a try and share honest feedback. :)

Please, reach out to me directly or join the Impulse Discord server.

If you need help or some onboarding session, I'm happy to jump on the call!

Website: impulse.dev
Github: impulse-oss/impulse
Full 40-minute demo: https://youtu.be/QaTSsaGXCco

Hacktoberfest 2019: four PRs to Parcel

Kirill Rogovoy — Tue, 08 Oct 2019 13:04:42 +0000

So here it goes — four PRs submitted for this year's challenge!

It took me several days to find issues of the right size, debug them down, and submit the solutions, but it was worth it. :)

Honestly, every PR here is quite small, but I'm still satisfied with the impact.

Tracking how much different code is read (literally)

Kirill Rogovoy — Thu, 13 Jun 2019 18:12:04 +0000

Hey, hope you are having a great Thursday!

I've been engaged in various discussions about eliminating tech debt and refactoring stuff out.

One of the goals of such sessions is to prioritize issues, so we spend our precious refactoring time fixing up the most important stuff.

A helpful rule for that process is "change code that people work with and read, and don't bother about the code that is read once in a while and is relatively simple even if flawed in some ways."

This is not the only rule, but definitely a good indicator on what to look at first. At least from my experience.

But here's the problem. When it comes to debates about which code we read and change more often, most of the process is just guessing. We try to gauge that from the intuitive context that we have at the moment: recent features, major features, plans, opinions, etc.

Even though we usually end up with a not very bad estimation, there's really no good way to measure or reflect on that process.

So it got me thinking: isn't it just a technical problem that we could solve with tools?

We could track how much (and how often) different files are changed using history from Git. The data is in front of us, and we would use something similar to https://github.com/jez/git-heatmap to assess that.
But point 1 is just half of the story. Wouldn't it be also great to track how much developers read different parts of the code? This would probably require an editor extension that would track all the cursor movements and jumps + navigation between files — perhaps a trivial thing to code for most of the popular editors. Then we would build a similar heatmap of how the code is read.

Questions:

Is the whole refactoring problem something that you are regularly solving at your organization as well? What's your approach and what are your struggles?
Would that code navigation tracker be of any use to you? Can you think of a project that can already do that?

Thanks for reading! Here is a ship-shipping ship, shipping shipping ships