41–50 of 87 posts
9. Learn to call it programming, not "coding". It's like a professional chef referring to what they do as "chopping".
For me, "software engineering" is even better term.
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.
Earlier quoted context omitted.
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 sure…
For example, if you are doing front-end JavaScript development it can be very good to understand HTTP, and have at least a vague idea of how things like TCP/IP and DNS work. Nothing kills productivity like hitting a bug that you can't even investigate without someone else's help.
Earlier quoted context omitted.
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?), e…
To elaborate, the goal should be to move forward by cycling between asking questions and doing something: Ask question Do something (ie bang out code) The "do something" will never be perfect, so don't waste hours trying to understand the theory perfectly. Use the coding time as a way to both test your knowledge and drive further questions. This is why it's helpful to pick a motivating project while learning to code.…
Very much the case for me, yeah. I've tried learning from tutorials and books and I just get bored. But if I come up with an idea and try to make it, I love it, learning the bits I need as I need them.
Should note that I think that if one is capable of learning the academic way, that's probably a better approach. Understanding programming in the general and thus being able to apply it to the specific. You'll certainly make better code that way.
But for me, for whom learning that way is never going to work, the ad-hoc way is fine. It doesn't really matter if my code is scrappy so long as it works and doesn't do harm.
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.
Earlier quoted context omitted.
For me, "software engineering" is even better term.
"software engineering" feels broader, like it includes knowing the right aspects of project management and risk for the given project and business needs, beyond just getting something to work.
Earlier quoted context omitted.
Also note that a chef does not come up with their recipes in the kitchen, and neither should a good programmer.
Well, good chefs do, it's called author's cuisine I believe. Someone, somewhere, has to come up with some recipes - and hold on there, I know it sounds like crazy talking, but why wouldn't these people be chefs, who already cook for a living?
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.
Earlier quoted context omitted.
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?
Probably, chef work is not that similar to programming. Construction would be more prolific analogy. Note using of construction related language in software world, eg "development", "architecture".
But programming can (and also should) be play. For me it's explorative and playful, I'm just trying to make a fun thing happen or see what things I can connect together in what interesting ways. I imagine it's the same for kids taking their first steps by making lights flash with a RPi and Python and then wondering what they can do next (led by imagination).
The latter is very much like being in a kitchen and throwing ingredients together, trying things out to see what tastes good.
I think limiting ones thinking of programming to the former sort devalues it.
“be ready to do it every day, be ready to learn for the next 10 years”
asked him to seriously think about that and we’ll talk again in a week
there is much more to it, but imho those are the 2 points that I’ve seen somehow valid for the last 20 years or so
and when I read “I’ve been on again off again with it” I thought “first mistake”, really if I would have 2 quick advices to give
do it everyday: because it test how much you can take, if you feel programming 2 days in a row is “too much” that’s probably a good sign “it’s not for you”
be ready to do it for 10 years: search “Teach Yourself Programming in Ten Years” by Peter Norvig and you will understand why.
A lot of ppl when it come to “learn how to program” underestimate very basic stuff like the involvement and the time it take, I saw ppl give up just because it took too much time or because they thought they would be good at it much sooner.
So yeah staying in front of a computer for hours, for days, solving problems with code, it may not fit everyone, but to me the longer you can keep at it, or if you forgot to eat, to sleep while doing it, are in general good signs of “you can do it”.
All the 8 points are very valid, even if some could be argued, I personally remember the fear, back in the 90s for a full month I was paralysed because of the fear to do wrong, the fear to break stuff.
If it was not for this older guy who kept encouraging and reassuring me I would have probably gave up, so I would say try to get a mentor.
But the opposite advice would work too: don’t get a mentor and try to understand everything by yourself, or in another context: resist the urge to go ask your question on stack overflow and try to solve as much of it by yourself. Solved it? then keep not asking questions on stack overflow as long as you can.
IMHO there are many ways to learn programming, some advices would not fit everyone, there are no best ways to do it.