Code quality, knowing what's good, and competition π‘
Monday Ideas β Edition #102
βΉοΈ Bright Data β unleash AI web scraping
Most of the internet data is trapped inside web pages β not provided through APIs.
This is where web scraping comes into play, but doing it from a single computer can be unreliable due to IP restrictions, CAPTCHAs and rate limits.
Enter Bright Data, which I am happy to promote this week! Bright Data offers:
π₯οΈ Robust infrastructure β that includes proxy networks and web scrapers.
πΎ Pre-existing datasets β that might eliminate the need for scraping altogether.
π Various modes of integration β including low-code solutions and Python programming options.
You can learn more below π
1) β
What does code quality mean?
We talk aboutΒ codeΒ quality rather thanΒ productΒ quality because the former might very well be invisible to the final user.
In fact, we often sayΒ under the hoodΒ β which is aΒ carΒ metaphor.
In our context, the car is the full product. Like digital products, a car has a UI/UX, which is how the driver (user) interacts with it, and how the car makes them feel.
Then, if we continue with the metaphor, the software might be theΒ carΒ engine.
What makes an engine high quality?
Some things are universally important β like reliability and little need for maintenance. Others, instead, largely depend on the car β sports cars might be concerned about performance, while city cars care more about consumption.
This translates well to software.
It is virtually impossible to be good on every measure of quality, so, for many things, it is a matter of what is valuable to you.
There is an area, however, where the car metaphor breaks:Β software evolves.
Evolution gives maintainability a whole other dimension: itβs not just aboutΒ repairing defects, it is about being able to change the code to support what the future brings.
With that respect, high quality code has to be that that isΒ easy to change.
I quote my friend Joel on this:
Code that is easy to keep changing is code that is enjoyable to work on. It helps us feel smarter and enables us to do more valuable work for the organisations we work for. Everyone wins and thatβs why itβs such a valuable lens to look at code quality through.
I wrote a full article about code quality β you can find it below π
2) π₯ Knowing what makes good things good
When I reflect on my personal growth, I have found it useful to see my abilities through the lens of taste and skill.
Great taste is knowing whatβs good, and great skill is knowing how to build things. These two elements work together for growth: whenever my output is subpar with respect to my taste, then I know I need to improve my skills.
There is a third element, however, that I have consistently found in the most experienced people I know.
They do not only know what is good β they also know exactly why.
They know what makes good things good.
Which is less trivial than it seems.
I may watch hundreds of TV shows and develop a good, intuitive taste for good ones, but I may not be able to explain how my judgment works. And that may be fine, unless I ever want to create a TV show. At that point, closing that gap becomes crucial, because knowing what makes good things good is what ultimately allows my taste to turn into skills.
In my experience, I have found two ways that help you with that:
Just build stuff β being dissatisfied with your output constantly triggers your reasoning and makes you ask βwhy do I think this is crap?β.
Discuss with others β when you discuss some subject, you need to elaborate on your judgment. If you disagree with somebody about something being good, chances are you want to figure out why.
I wrote a full essay about this, which ended up becoming one of the most popular articles of last year π
3) βοΈΒ Donβt focus on competition
Last year I read Good Strategy / Bad Strategy by Richard Rumelt, and it made me think about the concept of competition in digital products.
The book provides many examples where people create strategies in direct response to their opponentsβ weaknesses.
This makes sense inΒ zero-sum games, where success always happens at the expense of someone else. Think of wars, or winning an election.
With digital products, though, this is not always the case.
Oftentimes, you are not winning customers over some competition β at least not a direct one. Think of these cases:
π Growing marketsΒ β when a market is growing, there are simply more customers coming in, so both you and your competitors might grow at the same time. E.g. newsletter writers recommend each other on Substack, banking on the fact that people will just readΒ more, instead of replacing their newsletter with someone elseβs.
β Little awarenessΒ β I often start using a product because it solves a problem of mine, totally unaware of the other products that exist in that space. If the tool does the job, thatβs fine! In these cases, for the product I choose, focusing on what its competitors do wouldnβt help to acquire me as a customer.
I have found that focusing too much on competition also leads to lazy product thinking. You benchmark what exists out there and create your own variation of that, sometimes missing out on truly unique opportunities you can go after.
So, I believe most of the time it is safer toΒ double downΒ on your own customers to make them happy, rather than acting based on what others do.
You can find the full book summary + review below π
And thatβs it for today! If you are finding this newsletter valuable, consider doing any of these:
1) π Subscribe to the paid versionΒ β if you arenβt already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about theΒ benefits of the paid plan here.
2)Β π»Β Read with your friendsΒ β Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you aΒ great week! βοΈ
Luca