Hacker News Reader

I actually think #5 is the most important and shouldn't be discounted. I like three month projects - something moderate hard that might or might not get shipped. A summer of evenings sort of thing is usually enough to get a good grasp for me.

View on HN

While this approach seems to work for a lot of people, personally I'm in the crowd that has a really hard time with that.

I'm just not a creative person. I consider myself a good developer when it comes to diving into an existing code base and figuring it out, fixing things and adding new features. But I simple cannot come up with stuff on my own. I've been trying ever since I was a kid and started programming, and now it's been 20+ years of drawing blanks when I try to "think of a project."

Hopefully I'm not alone in this :P

There's no need to be creative about it. I never try to (re-)invent the wheel myself. Once I'm done with #1 on the list I posted, I evaluate the strengths and weaknesses of the language and pick something that probably already exists. Say for the case of Rust when I was learning it ~3 years ago, that was a private dropbox-like service which syncs files I listed in a config file to a GCP filestore bucket. Nothing fancy or complicated but still - doing checksums, syncing, error reporting, all the usual stuff. Eventually further extended it to encrypt personal documents before pushing them and so on. Doesn't have to be big or complicated or something that no one has done before. Matter of fact, doing something that already exists is the better option cause you can transfer concepts.

Reply on news.ycombinator.com