I will now send this to beginner programmers(headlinedev.xyz) A look at a common issue I see beginner devs go through. Probably the thing that weeds the most people out of development. |
I will now send this to beginner programmers(headlinedev.xyz) A look at a common issue I see beginner devs go through. Probably the thing that weeds the most people out of development. |
We've taken "Show HN" out of the title now.
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.
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 .
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.
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?
Yes. All CSS is written the way it is either for aesthetics or for accessiblity (readability, etc).
It’s just an ordered collection of exercises that starts easy and builds up to more challenging ones. I can’t overstate the power of this simple book.
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.
But they always wanna make an MMORPG
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.
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.
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.
My experience is that those who can pay attention to a book/lecture and do plenty of practice by doing are the fastest learners.
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.
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?
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.
https://www.semanticscholar.org/paper/The-Learning-Pyramid%3...
which I was pointed towards by
https://theeconomyofmeaning.com/2016/07/08/an-update-to-the-...
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.
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.
well he did say it's not scientific
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' :)
Does anyone have any recommendations for learning good practices when designing these models?
But also not super academic data structures etc
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.
For example a solar panel has to have a peak output, but no energy storage. But a battery type of product is required to have a storage capacity.
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.
It’s easy to explain data modeling (excel, sheet of paper). From there things start to make sense.
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.
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.
My best friend did exactly that.
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".
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.
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.
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.
What I would have given for someone to explain objects to me when I was trying be an object oriented programmer.
>objects are the things you think about first in designing a program and they are also the units of code that are eventually derived from the process.
Huh? Classes would confuse me. Methods would confuse me. I could get things to work but not understand why or how to extend and abstract properly.
At some point of learning you just need to be told the answer so you can move on.
There are a bunch of paradigms that are really useful, but you can’t get to from here without specific help or examples
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.
Dealing with failure is easy: Work hard to improve [your ability to identify what subset/spike of the project could be successful].
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.
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.