Live data from Hacker News

Tales of coding from a beginner

medium.com

21–30 of 87 posts

Re: Tales of coding from a beginner

#21
post #6

Personally, I've always read '=' as meaning the left hand side was equal to the right. So if I see x = 5 then I'm already assigning the value of 5 to x, because they're equal! Does that make sense? Curious to see what others think, because before reading this article, I didn't even realize that was a particular tripping point for anyone looking to start programming.

Then you read it as assignment. It's a bit unfortunate that it means something else in mathematics. Pascal used := as the assignment operator, and used = as the equal test. It could also do 1-based indexing of arrays, which is another classic pain point when you start programming with just a tiny bit too much knowledge.

Re: Tales of coding from a beginner

#22

Question: I'm curious to hear other people's experiences with "4. Stop asking questions". I ask questions quite a bit. It does slow me down. But I feel like if I understand something, I can move faster in the longer term, besides the value derived from just understanding how the system/abstraction works.

I think the point is not to get paralysed by the desire to know everything at once.

Each question tends to just give rise to ten more. Which is fine for someone who has a conceptual understanding of programming-in-general (whether from studying it academically or just being more experienced/talented), enabling them to contextualise all that information. But for the beginner who is trying to self-tech (self-learn?), even if they understand the words, they don't really mean anything.

>Django is a application framework, written in Python, which follows the model–view–controller (MVC) architectural pattern

I may know what all those words mean and thus understand that sentence. I may know what MVC is (in that, again, I understand the words used to describe it). But until I've done a bit of Python and implemented something following the MVC pattern (and compared it to the alternatives) I don't really get it. The knowledge has to become practical to be useful.

It's better to only ask questions that go one level deep at a time, practise what you learned until you actually understand it, then ask the next level of questions.

For self-taught coders who are never going to be amazing at it but just want to make stuff (like me), I think this is very good advice.

Re: Tales of coding from a beginner

#23
post #10

[deleted]

Well, perhaps some HN users are interested in computers/tech but are not well-versed programmers. For them it might help. Furthermore, people who do believe they know how to program may identify with the story, hence it's an interesting read to some.

In college, I experienced: 1, 2, 3, 6, 8 and between 12 and 14 y/o I experienced the other numbers.

And she basically stated the article was about her building confidence in one of the first few sentences. So the article/author is quite upfront what this is about.

Re: Tales of coding from a beginner

#24
post #10

[deleted]

As someone who teaches programming, this was an interesting read for me, because it helps me understand the issues faced by people who are just trying their best to learn "software", but get stuck in lots of things including "Jargon".

Re: Tales of coding from a beginner

#25

Question: I'm curious to hear other people's experiences with "4. Stop asking questions". I ask questions quite a bit. It does slow me down. But I feel like if I understand something, I can move faster in the longer term, besides the value derived from just understanding how the system/abstraction works.

There's a line where you have to stop asking questions (lest you end up at the big bang). Experience will guide you in narrowing down where that line exactly is - over time, you better know what you don't know and don't need to know. I'm also a proponent of constantly asking "why? how?", but at the beginning, you have to at least pause between your questions to process what's happening, and sometimes trust that you h…

I agree with this, there is a line at which you have to stop. I need to know 'why' when I'm learning in order to put what I'm learning in context. This can often lead to chasing rabbits down innumerable holes.

Learning to stop asking why and at what point to just accept a certain level of understanding and move on has been tough for me.

Stopping asking right now doesn't preclude coming back later to flesh out your knowledge or course, which I've also found myself doing and it works well enough.

Re: Tales of coding from a beginner

#26

Just what the doctor ordered! I'm just starting out[1] and recognise all of these points, especially number 4 even though on first glance it might seem the wrong attitude. Every time I run into something new I feel the need to 'fully' understand it before moving on. With such a vast corpus of information out there and a lifetimes worth of skill development in just one particular branch (database admin anyone?) I have…

I think the tricky thing about #4 is essentially just the leaky abstraction issue.

Each one of us is working and building on mainly one layer of abstractions. It helps our puny human mind to comprehend and visualize whatever limited functionality we are trying to do. Unfortunately, most abstractions are leaky, and when things spill over, you have to learn how to clean up (and then the next one spill over, we got the yak-shaving situation that any developer would encounter at least once ...).

It's not unique to programming. But in other subjects, when the abstraction is leaky you probably doesn't know it yet until you learn more. Here when abstractions break, things stopped working immediately. I guess that could be both a good and bad thing?

Re: Tales of coding from a beginner

#27

Just what the doctor ordered! I'm just starting out[1] and recognise all of these points, especially number 4 even though on first glance it might seem the wrong attitude. Every time I run into something new I feel the need to 'fully' understand it before moving on. With such a vast corpus of information out there and a lifetimes worth of skill development in just one particular branch (database admin anyone?) I have…

Take a look at rawgit for demoing your github work: https://rawgit.com/. Your google clone becomes: https://cdn.rawgit.com/PuffinBlue/google-homepage/master/ind.... Far more easy.

Re: Tales of coding from a beginner

#28

Just what the doctor ordered! I'm just starting out[1] and recognise all of these points, especially number 4 even though on first glance it might seem the wrong attitude. Every time I run into something new I feel the need to 'fully' understand it before moving on. With such a vast corpus of information out there and a lifetimes worth of skill development in just one particular branch (database admin anyone?) I have…

Take a look at rawgit for demoing your github work: https://rawgit.com/ . Your google clone becomes: https://cdn.rawgit.com/PuffinBlue/google-homepage/master/ind... . Far more easy.

Thanks, that is easier. And I see the little microphone icon is misaligned now on Chrome, it used to be correct!

Re: Tales of coding from a beginner

#29
post #13

9. Learn to call it programming, not "coding". It's like a professional chef referring to what they do as "chopping".

Also note that a chef does not come up with their recipes in the kitchen, and neither should a good programmer.

That's a good sound bite statement but does not really follow from the original post, nor seems to be very accurate. What exactly is the relation between a chef work and a programmer, and what is the equivalent of recipe in programming?

Re: Tales of coding from a beginner

#30
post #26

Just what the doctor ordered! I'm just starting out[1] and recognise all of these points, especially number 4 even though on first glance it might seem the wrong attitude. Every time I run into something new I feel the need to 'fully' understand it before moving on. With such a vast corpus of information out there and a lifetimes worth of skill development in just one particular branch (database admin anyone?) I have…

I think the tricky thing about #4 is essentially just the leaky abstraction issue. Each one of us is working and building on mainly one layer of abstractions. It helps our puny human mind to comprehend and visualize whatever limited functionality we are trying to do. Unfortunately, most abstractions are leaky, and when things spill over, you have to learn how to clean up (and then the next one spill over, we got the…

Leaky abstraction is an interesting way to put it. That makes sense to me. I really do feel like I'm building something on a certain layer of abstraction.

I guess when something new comes up it has the potential to push you down a few more layers than you intend and you can get caught trying to race to the bottom of the stack and learn everything.

A certain amount of curiosity for what's going on 'underneath' is surely a healthy thing and probably helps long term progression, but for learning it can be a bit distracting!

Post reply on HN