I'm sure Alex and Rahul talk about this in their Masterclass "How To Write Better Code Faster as a Software Engineer", but wondering how to write clean code, particularly in the context of someone who doesn't have technical people available to review my pull requests in my work or in side-projects.
I'm sure this skill is almost entirely developed by working with talented people and writing a lot of code, but is there a place for resources like "Clean Code" the book or courses on Udemy?
You're right that the best way to develop this skill is to actually write lots of code with talented people around you.
If you don't have technical people to review your PRs in work or side projects, an alternative is to contribute to open source. That's the beauty of software -- if you put in the time/effort, you can find great people to work with pretty easily! One open source project that comes to mind (and one we use for Taro analytics) is PostHog. They have tons of repos and I'm sure you could find something to contribute to.
I don't have any recommendations off the top of my head for books/courses. I'd probably start with looking at respected developers in the field and following their blog posts or code contributions.
This is a great question! I have a lot of thoughts here, so I'll split them up into 3 separate responses:
I'm sure this skill is almost entirely developed by working with talented people and writing a lot of code...
You're 100% correct! Unfortunately, this makes it pretty tricky to learn how to write good code by yourself. Code quality is something you improve at through a mix of institutional knowledge and communal effort.
...but is there a place for resources like "Clean Code" the book or courses on Udemy?
This is the really hard part about learning what good code looks like - There's no concrete definition. Good code is more about the fundamentals rather than the code itself. To clarify, here's an example.
Let's say you're working at some tech company with thorough code review, and you put out a pull request. You get the following feedback:
"There is too much code in this 1 class - It's over 500 lines! Please abstract some of the logic outside of it into different classes to shrink it down to 250 lines or less."
Let's ignore how prescriptive the 250 lines thing is and focus on what you, as the software engineer looking to learn what clean code looks like, should take away from this interaction.
Let's unpack this:
I talk about this concept in our video about "doing the simple thing first", but I wanted to provide a concrete example to make things clearer. As I mentioned in my earlier response, clean code is all about the nuance. This means that code which is legitimately high-quality in one company's codebase can be terrible in another's.
I remember there was this earlier-in-career Android engineer at Instagram who was really swept up in "clean code". For context, the Instagram Android codebase is famously simple, almost primitive. Anyways, this is what that engineer did:
This is why I have generally been disappointed with resources I find online about how to write "clean code". They're often too prescriptive, missing the point of what clean code actually is. They'll recommend certain modern frameworks (e.g. "This new library is the best way to build a Node.js REST API") or dogmatic tactics (e.g. "All code needs 100% automated test coverage").
At the end of the day, your goal is to make your code not suck, which I talk about in-depth here. This will look and feel different to everyone, but the important thing is championing this mentality.
I know I just dumped out a bunch of very abstract, wishy-washy stuff, so I'll actually answer the question now 😛
There's 2 big strategies that come to mind for me:
Writing better code is fundamentally about removing pain, whether it's pain for the user or pain for the engineer as they strive to deliver value to the user. And at the end of the day, it is very easy to generate pain with software (hopefully unintentionally of course, haha). You just have to build stuff and actually care about it.
Thank you for such an incredibly detailed response, Alex!