I love this, and I’m stealing it. it’s a perfect description of competency in a language, imo.
I absolutely understand the emphasis on shipping, and i actually have recently come to lament some of my unshipped projects lately (I’m in a phase of finishing instead of starting projects myself, and sometimes have felt like I haven’t gotten to ship anything in my software career, but that’s another story for another day) but part of the core skills I attribute to allowing me to finish are the same ones leet code interviews helped me polish. how one works on a low-level data structure is one of the core aspects of software engineering i examine in a new hire.
What I think I’m trying to say is, I don’t mean to stop working on shipping a project to focus on leet code toy problems, but rather that a lot of leet code interview problems have given me better insights on how to focus and solve problems im trying to ship. I have found great value in going back and rehashing leet code interview problems and turning them into tiny libraries after i was given them. So much so that I’ve turned it into an exercise. I’ll have to write a full post about it sometime, but writing tiny libraries has been one of the best things I’ve done for my technical skills.
> I’ll have to write a full post about it sometime,
I'd read that.
> but writing tiny libraries has been one of the best things I’ve done for my technical skills.
I do that all the time. When I get to a bunch of code that I think has reuse potential (like, say, a backend connection SDK), I break it into a standalone GitHub repo, set it up as an SPM package, and give it The Full Monty for testing and documentation. The testing code usually dwarfs the implementation code, and the documentation is...well, you can see for yourself. Here's a few of the packages that I've written: https://riftvalleysoftware.com/work/open-source-projects/
I usually take a few days off the main project, write, test, document, and release the subproject, then re-absorb it into the main project.
I love this, and I’m stealing it. it’s a perfect description of competency in a language, imo.
I absolutely understand the emphasis on shipping, and i actually have recently come to lament some of my unshipped projects lately (I’m in a phase of finishing instead of starting projects myself, and sometimes have felt like I haven’t gotten to ship anything in my software career, but that’s another story for another day) but part of the core skills I attribute to allowing me to finish are the same ones leet code interviews helped me polish. how one works on a low-level data structure is one of the core aspects of software engineering i examine in a new hire.
What I think I’m trying to say is, I don’t mean to stop working on shipping a project to focus on leet code toy problems, but rather that a lot of leet code interview problems have given me better insights on how to focus and solve problems im trying to ship. I have found great value in going back and rehashing leet code interview problems and turning them into tiny libraries after i was given them. So much so that I’ve turned it into an exercise. I’ll have to write a full post about it sometime, but writing tiny libraries has been one of the best things I’ve done for my technical skills.