Feedback Loop
“I learned that the fastest way to improve is by reducing your iteration time and creating a tighter feedback loop.” - May 2024 blog
This is actually another reason why you should Work in Public.
There was this LinkedIn post recently that made me think about Side Projects, because I was a big proponent of building things from scratch.
This post makes a very good point about how side projects very often get very little input, and thus have virtually no feedback loop. Thus, you actually don’t learn faster because there isn’t anyone to give you feedback.
- Link if you don't see the embed https://www.linkedin.com/posts/ryanlpeterman_please-dont-apply-for-a-senior-dev-position-activity-7208483567159439360-vGSH?utm_source=share&utm_medium=member_desktopThis goes against my argument that I make that the best way to learn something deeply is to build it.
I guess you learn different things in both cases. it’s not contradictory to the statements made by Richard hamming doing Important Work.
When you’re locked away in your room working on side projects, you’re working deeply, but you’re isolated. You can’t get feedback, and thus the work that you’re doing is not necessarily important. To know whether it’s important, you MUST get feedback.
Are side projects bad then? I also say that the most important thing is to Ship. To build in the public is the fastest way to ship. To get feedback fast.
Thus, build side projects in public. You get best of both worlds.
I would still argue that side projects are valuable, because they let you go deep, and omit distractions when you don’t care.
So yes, it’s “faster” at work due to shorter feedback loops. But you don’t necessarily go deep on anything. But you do get practice shipping things.