Projects are great but there's a deceptively challenging step in "formulate a small and feasible project idea". It's really hard to come up with a small and feasible project when you're a beginner.
First, beginners don't know what's feasible. To a beginner all of programming is computer magic. There's not a lot of difference to a beginner between training a machine learning system for classifying different apples and a proper auth flow with OAuth[1]. Second, beginners don't have experience with product skills like scope cutting, setting milestones, etc. Some may say "that's all business nonsense!" but the lack of these skills has an effect.
When I'd mentor underclassmen in college, they'd always say something like "let's build a mobile app that lets people create accounts for their pets and then uses machine learning to pair them with the best possible dog walker" as their "small and feasible" project. And I'd have to be like woah there buddy let's get us to "a mobile app that lets you create an account and sign in" first.
What I always tell people is that they should make an outrageously simple project. One of my first projects was a blog in Rails. That's literally the first tutorial for Rails! But it turns out if you add stuff like comments and responsive design and deploy the blog, you end up learning a lot. Start stupidly simple and you'll be surprised how much you learn.
Overscoping a beginner project is completely harmless. The worst thing that can happen is that you get stuck along the way and realize that a feature is much more difficult or out right impossible. You then cut that feature or give up on the project if you've sunk enough time into it.
Fortunately, actual delivery of a beginner project is pointless. The only point is to learn by doing and you accomplish that regardless of whether your project fails. And failing projects is a lesson in itself on scope, estimation, and research; you won't get this experience if someone else is scoping for you like in a school project .
I disagree - a beginner who gets stuck for too long is very likely to give up trying to learn.
Yes, the learning comes from failing and eventually understanding. But that doesn't _feel_ like progress, what feels like progress is completing stuff and moving on. And if it doesn't feel like one is progressing, the incentive to continue is reduced.
Overscoping doesn’t imply you’ll get stuck. It just implies you won’t finish it anytime soon, and probably will start something else at some point. When I started programming, I learned a ton from projects I never finished as originally intended.
The most important thing is choosing something to build that you are excited about. If that means overscoping, it’s still better than selecting a smaller project that however you find boring.
It depends on whether the beginner has the mindset of "oh well I'm stuck, guess I'll do a different project/cut scope/ask for help" or has the mindset of "oh well I'm stuck, guess I'm not cut out to do projects"
> When I'd mentor underclassmen in college, they'd always say something like "let's build a mobile app that lets people create accounts for their pets and then uses machine learning to pair them with the best possible dog walker" as their "small and feasible" project.
Maybe they can mooch off some existing library or service. Yelp has an API which you could use to find dog walkers near you.
By the way, what's with the white on black monospace layout? Is that supposed to be cool or something?
Well it's in their profile (which is good practice so kudos for that). But if you see someone linking to the same site over and over again when the link content doesn't add any actual value it's kind of a giveaway.
There's a common trope that everyones first game is going to be an MMORPG from scratch.
I always try to convince them that a simple puzzle game is a much easier starting point, no AI, no netcode, minimal animation and good use of programming fundamentals; arrays, conditions etc.
Or to take a Unity FPS starter pack and go to town with the asset store.
I've seen a lot of beginners (typically those who learn through various YouTube videos and a some online pagess, but not through a systematic guide like a book) having a hard time deciding "what a super simple project" is.
For example: after learning the basic concepts of loop and condition checking, they have no idea how to utilise those in a very simple app. I say "hmm try to write a simple word guessing game... or a simple food ordering app". Usually you'll find various exercises provided in such books.
In fairness to those learning through YouTube or other modern sources: I learned from books and after finishing the exercises in the books I also had no idea what a "super simple project" was, or at least what one step up from the book was.
Ultimately I learned by starting projects that were too large, hitting a roadblock, and stepping back to learn about that thing. Then starting another project and repeating.
This process took years and years before I was reasonably confident in estimating the size of a project. And to be honest even now, nearly 25 years after writing my first tiny cli trivia game, I still get it wrong sometimes, especially in a new domain.
At the end of the day estimation is hard even for veterans of the software industry.
Note that the flowchart given (with its explicit instructions for beginners to back off —hopefully exponentially— upon discovering one has bitten off more than one can chew) may be applicable even for non-beginner programmers:
Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve. — Alan Perlis.
True, as the quote wasn't aimed at beginners. Keeping in mind that I was running the opposite implication (that the same flowchart for beginners is still suitable for experts), the mapping remains, although we (pace the XKCD!) probably ought to make explicit what that improvement might be:
Dealing with failure is easy: Work hard to improve [your ability to identify what subset/spike of the project could be successful].
Agreed, a common misconception, imo, is that programming's some sort of math or language skill when really it's just learning how to break down computer magic into the simple underlying logic and systems that generate it.
First, beginners don't know what's feasible. To a beginner all of programming is computer magic. There's not a lot of difference to a beginner between training a machine learning system for classifying different apples and a proper auth flow with OAuth[1]. Second, beginners don't have experience with product skills like scope cutting, setting milestones, etc. Some may say "that's all business nonsense!" but the lack of these skills has an effect.
When I'd mentor underclassmen in college, they'd always say something like "let's build a mobile app that lets people create accounts for their pets and then uses machine learning to pair them with the best possible dog walker" as their "small and feasible" project. And I'd have to be like woah there buddy let's get us to "a mobile app that lets you create an account and sign in" first.
What I always tell people is that they should make an outrageously simple project. One of my first projects was a blog in Rails. That's literally the first tutorial for Rails! But it turns out if you add stuff like comments and responsive design and deploy the blog, you end up learning a lot. Start stupidly simple and you'll be surprised how much you learn.
[1]: https://xkcd.com/1425/