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.
This misses a big part of why books and lectures are much more effective than the author presents. In books and lectures a practitioner is offering you shortcuts and advice to avoid pitfalls and accelerate your learning in a polished well thought out way (if the author/instructor is good - big if). Sure, not everyone retains them. But for those who do they can practice by doing without banging their head against the wall as much.
My experience is that those who can pay attention to a book/lecture and do plenty of practice by doing are the fastest learners.
Which lesson will you carry with you longer? The time you saw a presentation and the speaker warned against X, or the time that X bit you in the ass and you learned from experience why it’s a bad idea? Much of the detail you’re referring to can absolutely be learned valuably from a presentation, but folks with more experience can grok the lesson and reasons behind it much better. Presentation and book learning absent practical experience leads to things like everything being forced through an OOP lens for example.
I mostly agree with this, but there's one thing missing: beginners find it very difficult to come up with good projects. Just yesterday someone asked me for resources to learn how to write an operating system. It turned out he barely knew what a pointer is.
Doing stuff is the best way to learn, 100%. But recommending interesting and simple stuff to do is a huge help. Since they don't quite understand computers, they also don't quite understand the complexity of different things. I remember what kinds of things I wanted to do as a beginner, I thought I could do it all.
Also, a quick note: it would be great if you'd support prefers-color-scheme, my browser is set to light but I'm reading this in dark mode, which is harder for me.
I agree that working on a project is the best way to learn programming, but I have to emphasize: it's the structured learning that ties it all together and allows you to get a better understanding on how to tackle such projects, whether self-learning or guided. You need to be methodically exposed to available tools, solutions, and common practices you may not have come across when working on a project.
> Now, to be clear, nothing about this model is scientific, [...]
This one always gets me. I've been trying hard these days to give better, clearer, more actionable advice to beginners who want to learn how to program.
I think, at the most basic level, we understand that our estimation of how much we learn from some particular teacher/course/method is wildly inaccurate, and it's a poor way to assess how effective that teacher/course/method is. Someone constructing a cute pyramid diagram is not much better.
It's also not about maximizing retention. That's a very one-dimensional way of looking at effectiveness. All of these ways of learning have their own place.
We DO have decades of qualitative and quantitative research into computer science pedagogy. We CAN do better than draw up a pyramid like this. It's nice to acknowledge that the pyramid is not scientific, but why would we not then dig through the journals a little bit to find some papers on computer science pedagogy?
Actually, there is a framework used in education. I learned about it when teaching foreign languages.
It is about how to structure a unit about any given topic:
1. Presentation/ Introduction to the topic with examples
2. Explanation
3. Verification that topic was understood in theory
4. Practice with isolated exercises
5. Transfer new knowledge to personal context
So lectures, articles and such can serve as an introduction to a topic. Step 3 is difficult when learning on your own. I would suggest the Feynman method here. If you can explain it, you understood.
Then look for exercises. Tutorials are great here. Try to solve it on your own, then look at the (possible) solution.
Then lastly, go and using it in your own context, outside of a tutorial, will solidify your knowledge.
> I don’t think anyone would disagree that actually doing a task is the best way to learn more about it.
Eh, for me, reading would be my 90%. I have almost a photographic memory for anything I read.
Audio-visual, demonstration, and group discussion are absolutely my worst ways to learn anything.
Practice by doing would be second to reading for me. Teaching others is helpful once I have read up on the subject, but is abysmal if I’m not already almost an expert on the subject.
If you’re spending your time reading programming resources and following tutorials directly, regularly checking against a guide to ensure your program matches the example, you’re almost surely doing yourself a disservice. Your success in following a guide lies in your ability to grasp the concepts, not to type a working program.
i like tutorials to give me a starting point. when i want to build something that i don't know how to do from scratch i look for a tutorial that builds something similar, and then start making changes until i get the result i want. that's where the learning happens.
You mean the retention rate for each learning method? Those are mutually exclusive… I guess this is a good example of OP’s claim that reading is only 10% effective.
Who are these beginner devs? Do people actually get a bachelors degree and proceed to not work in the field?
Who are these people who take up a craft of creating software and need to be told to, create software, to get better at it?
Presumably, people who get into this, already want to create stuff. If they have some other motivation, I don't want anyone telling them the 'secret' :)
It happens a lot more than you'd think. Programming continues to be big money even if you're awful at it. To give a lousy comparison, imagine a story with a really lousy wizard; they can mess up/fail most of the time, but as long as a few times a year they make some pretty lights and woo their audience, probably they'll stay in favor, since it's still magic to everyone else. The failures likely are written off as "well it just happens like that sometimes."
The big issue is that even if new programmers understand the basics of programming and how to get a functional program, the discipline of identifying when the problem you're dealing which actually has well defined business rules is another craft altogether.
Blank Page Anxiety is just as real for code I suppose as it is for other types of writing, and having a system with structured "write something that does X Y Z" is often essential for a lot of people as it's the only way they know how to produce code.
As an example, we sometimes take in fresh from University trainees for some general datacenter/IT work who come from compsci/bootcamps, and they always say they want to develop this skillset more, but never write a single line of code (we stress heavily that this would be paid work you get time set aside for; usually no takers).
I'm not a programmer by trade, but I am very lazy and have gotten pretty good at figuring out when spending a week to write some tooling is less time than the total time over a year I would spend on a common task and write tooling accordingly.
Finding problem and developing a solution is not a skill that is out there by default, but it is fairly easy to learn. I like technical problems and hearing about them because it's fun to think about, and once some basic code got into my skillset, it was an additional solution to many of these problems. Listening to people describe their challenges is a great source of projects to practice on. The satisfaction of someone telling me "wow, you have no idea how much time this saves me every week" is a pretty good inspiration to keep learning and doing more; it's "production code" and the benefit is immediately apparent.
I never go out seeking a problem to code a solution for, but instead just like talking about technical things. Inevitably, a problem comes up that I think "how hard could that be to write a program for?" and a new project is born. (Sometimes the answer turns out to be "very hard", but those are really fun projects once I'm past the frustration :) )
Hi, I was one at one point. I'm an aerospace engineer, not a software guy. I merely dabble in coding and as such I don't know how to implement a quadtree or what Dijkstra's Algorithm is for. I've been coding off and on in some capacity since the early 2000s. I learned what closures were a year or two ago.
Not everyone who slings code has a comp sci/software eng degree.
A bachelors degree is an undergraduate degree, ie it’s designed to prepare you for a graduate degree. On its own (traditionally) it’s not so useful, but people still accept it as the lowest common denominator of education because the world is a much different place now.
"Create Project Idea" seems a rather unnecessary step. We already have a canon of CS exercises (sorts/searches, trees/graphs, parsers, ray-tracers, etc...)--all of which can be easily verified against their more battle-tested counterparts, and serve as superior preparation for the inevitable leetcode interview.
Learners need projects they care about, project they feel ownership about. Most students aren't motivated to do some standard project. In formal education, we make them care about these standard projects by giving credit. But that sort of extrinsic motivation isn't that helpful for deep learning, I've found. It'd be better if a student has a problem they truly care about, somehow. Unfortunately, turning their need into a workable project isn't as easy as you'd hope.
As a beginner programmer currently learning Django, the biggest challenge I have is working out how to structure data models (E.g what should be a separate model that is referenced with a foreign key, vs just a field, or a sub class etc)
Does anyone have any recommendations for learning good practices when designing these models?
There are multiple things that come to mind, that you can look into, perhaps find a good explanatory text or video about:
ERM - Entity Relationship Model
1., 2., and 3. normal form for relational databases (usefule to avoid redundancy and designing it, so that it can be extended later, and avoiding pitfalls like non atomic values).
User stories and thinking about, whether they can be comfortably implemented using the proposed model.
SQL - for understanding what might happen behind the ORM (Object Relational Mapper).
Those things are however not Django specific, which might be the reason, why one might struggle with them, if one is just starting out coding with Django. Django tutorials will usually not cover these. However for a personal project, maybe a not perfect database design is OK as well. Do not despair because of it.
Probably the whole picture of how you want to use the data in your database needs to be considered to judge this properly. There are "escape hatches" like having a separate entity, which is called something like "ProductAttribute", with a foreign key being the actual "Product". The Product would still have attributes, which every product has, lets say a name, a product id, a creation date, etc., while ProductAttribute could contain any other attribute, not relevant for all products.
Why is this an "escape hatch"? Well, if you want to process that data later, it would most likely be very convenient, if you had all product attributes as columns, instead of having them as rows in another table. One would then have to translate back to the usual form of having them as columns. It is possible, but annoying. However, if you never need to analyze the data like that, then storing in this kind of extra table might solve all your use cases. It is ultimately a trade-off between safety or type strictness and flexibility (being able to add arbitrary attributes without having to change the schema).
Another, but in my opinion quite bad, solution is, to have loads of empty columns for future attributes. But it is really a terrible solution, running contrary to any good database design.
That’s definitely a data modelling learning topic and not Django. (You just use django to implement your design decisions)
I’m on mobile so can’t easily locate specific recommendations but if you Google data/database modelling/design, normalization etc you should find a wealth of info.
For me it was learning by practice. I had to build something, get stuck, and then search till I found the answer and repeat until the thing was built. And the thing was never important but just something to practice on. Like “make a countdown clock”
>Chat room helpers often will try and lead you to discover the right answer yourself. It may feel frustrating, but play their game and you will learn. This is the discussion level of the pyramid.
I fucking hate this so much. You spend hours trawling through Google search results and finally decide the answer isn't out there. Stack overflow is caustic so you don't want to ask there. Hop on IRC and ask "how do I do X?" and now you have to deal with a bunch of "well what happens if you do <tangentially-related-thing>?"
Fucking answer the question or don't offer yourself as a helper.
Absolutely not. If you've actually done the research that leads the knowledge gatekeeper to ask these, these questions are easy for you to answer. If you haven't then you're wasting their time.
>Absolutely not. If you've actually done the research that leads the knowledge gatekeeper to ask these, these questions are easy for you to answer.
Depending on the specifics of the question being asked, sure, I agree.
But speaking only for myself, I abhor playing silly coy games of cat and mouse. I only come to chat rooms as a third/last resort exactly because so often you can't get a direct answer without satisfying somebody's ego first. It's basically hazing.
I've got a thousand things to do and it would be more expedient for both asker and giver if the response to "How do I do X?" was a simple "via Y".
The people in the chatroom interact more with people who do not do this. They're trying to prevent wasting their own time, and leaving askers with precise answers to questions they didn't need answered, or sending them down the wrong path and fielding tons of opaque questions rather than finding out what's actually going on.
I get that you don't want to waste your time, that's entirely reasonable... but by asking for help you are asking others to donate their time. Refusing to acknowledge that their strategy helps them preserve their time just makes you the asshole, not them.
I am in IT/dev for 35 years and love to discover new stuff, and to help others to start. I am a HUGE fan of what I call "bootstrapping" knowledge.
Say I know Python and want to code in Go. I craft a question that shows that I understand the problem but could not find the documentation that would explain this in Go. This is obviously not "how to assign a variable" but rather "how to asses the kind of error returned by the function" (in Python you would do that with an exception, in Go this is borderline voodoo to understand that the error is because there is no network, rather than a DNS issue for instance).
I then get either downvoted because my question is not elitist enough, or someone plays kindergarten teacher by saying "you have toooo ... u... un... unwraaaa...?"
These people are fucking annoying and the site become s shitshow (yes - I am looking at you Stack Overflow questions tagged with golang)
Just say "you need to unwrap the error by doing this and that, the documentation is here). I do not want them to explain me what an error is, or why there can be many, or the philosophical religion of the one who coded it that way. I. Just. Want. To. Start. Somewhere.
If it wasn't for #startups people spending hours holding my stupid hand through mundane problems for hours I would be nowhere and likely homeless. Imagine being able to frequent a pub with super smart people ready to help at any given time. IRC is/was that.
After hours of searching, it is annoying when the reply is something like "does this chat look like Google to you?" (though fortunately those are pretty rare), but the answers trying to teach you how to discover answers to your original question are closer to "teaching a man to fish", or the Socratic method: you'll probably discover the answer soon (possibly with additional help), and will be able to discover similar ones in the future.
That approach is both more educational and may be easier on helpers themselves; answering the same (or very similar) questions, often from the same people, isn't particularly fun or productive.
> Stack overflow is caustic so you don't want to ask there.
I have only positive experiences with asking on Stack Overflow. Nine times out of ten I have gotten a useful answer. In one case, an answer provided a 20-line code snippet, which would have taken me days to figure out on my own.
The key is to ask clear and focused questions, and explain what you have already tried and why it didn't work.
Sure, there are always some answers or comments which are unhelpful or which completely miss the point of the question. But the value of a QA forum is given by the value of the best answers, not the worst.
I’m new to Clojure, coming from Ruby and C and Pascal - there is no way I’m am leading myself to use ‘juxt’ and possibly combining it with ‘into {}’ (ruby’s each_with_object gets you close, but it’s not as powerful)
There are a bunch of paradigms that are really useful, but you can’t get to from here without specific help or examples
We've taken "Show HN" out of the title now.