I first built a simple thing.
But it was buggy. I learned about debugging.
Then I wanted to add features to it. But the code was ugly. So I learned how to refactor.
Then I learned about modules to separate things out better.
Then I started breaking up bigger features into smaller features and planning my implementation - sometimes in a notebook. So, white boarding was now easy.
I'd then write the pseudo code as comments first. For obvious things, I'd delete the comments as I replaced them with actual code. For less obvious things, I'd leave the comment in-place.
I also became proficient enough that I could write code for whatever I was thinking without needing to constantly look up syntax. This made me fearless during pair programming.
I also found myself solving problems that more senior engineers talk about when they talk about battle wounds. This was awesome because, as soon as I talked about my (fairly simple, really) projects, it made the interviewers happy. I've received at least two jobs this way.
One big takeaway for me from doing this has been that simple code is far nicer to work with and return to than clever code. If your code is so simple that even a freshman in college can understand it, then thats a good thing!
There's no shortcut to just building things, no 100 second YT tutorial or lengthy HN exposition can substitute pure hours in assembling software. Sure, some people might pick it up a bit quicker/slower but fundamentally there's no better replacement.
One of the side benefits is you can version these projs and iterate/recoil in horror every 6-12 months for the next few decades -- once you can open that repo and not be shaken up then you've made it: time to retire as you're finally losing your faculties.
Comments
By building things on my own for myself.
I first built a simple thing. But it was buggy. I learned about debugging. Then I wanted to add features to it. But the code was ugly. So I learned how to refactor. Then I learned about modules to separate things out better.
Then I started breaking up bigger features into smaller features and planning my implementation - sometimes in a notebook. So, white boarding was now easy.
I'd then write the pseudo code as comments first. For obvious things, I'd delete the comments as I replaced them with actual code. For less obvious things, I'd leave the comment in-place.
I also became proficient enough that I could write code for whatever I was thinking without needing to constantly look up syntax. This made me fearless during pair programming.
I also found myself solving problems that more senior engineers talk about when they talk about battle wounds. This was awesome because, as soon as I talked about my (fairly simple, really) projects, it made the interviewers happy. I've received at least two jobs this way.
One big takeaway for me from doing this has been that simple code is far nicer to work with and return to than clever code. If your code is so simple that even a freshman in college can understand it, then thats a good thing!
There's no shortcut to just building things, no 100 second YT tutorial or lengthy HN exposition can substitute pure hours in assembling software. Sure, some people might pick it up a bit quicker/slower but fundamentally there's no better replacement.
One of the side benefits is you can version these projs and iterate/recoil in horror every 6-12 months for the next few decades -- once you can open that repo and not be shaken up then you've made it: time to retire as you're finally losing your faculties.