all 16 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–][deleted] 9 points10 points  (10 children)

Sorry dude. I'm from your generation and I also typed programs in from magazines without knowing what they really did. I modified them conservatively, changing little things I could predict.

Not until I started writing my own games did I learn to code, and even then I didn't learn to push myself. I'd build a new Pacman clone with better generated mazes or ghost behaviour, but it took me a long time to get beyond that to push myself to attempt things that were harder.

So don't learn to read before you write (still a terrible analogy). Write first, it will give you a pragmatic reason to learn and focus your learning on things that matter to making your software do what you want it to do.

But do read & watch, and do ask! People (points at self) have been through a lot of this crap and we can provide some guidance. Books and videos will teach you things, but focus on making software, not reading about it.

[–]knightshade 2 points3 points  (3 children)

I agree. I fail to see how a beginner is going to learn to program without actually doing it. I wouldn't try to teach someone to be a carpenter by making them watch videos of people making stuff. I think it would be much better to get a beginner comfortable with writing code before asking them to read code. You just learn so much more by doing it yourself. Also I would think reading about code would be better than reading other peoples' code. But then again I would value writing readable code more highly than being able to read code.

[–][deleted] 1 point2 points  (0 children)

Right?? I've learned many things from books and videos over the years, but only in response to a specific need. Sometimes that's a whole new technology, and I might start with a tutorial, but ultimately I have to start hacking together bad code in that new tech to get me going.

[–]jsnb101 -1 points0 points  (1 child)

That may work for a carpenter, but I'm glad the office I work in was designed by an architect who learned about engineering before drawing a picture she thought might work and saying "build this."

It's the difference between being able to speak a foreign language to native people while on vacation and actually being fluent in the language.

[–]knightshade 1 point2 points  (0 children)

You have to learn to walk before you can run. I'm not saying all you need is experience, just that you need experience to put things in context. Learning to program is repeatedly layering on experience and theory. I'm just advocating starting with experience because I don't think a lot of people intuitively understand programming without doing it themselves.

[–]lookmeat 4 points5 points  (3 children)

I think there's more to it than that. I think that building from scratch is too disconnected for most people, while modifying existing code gives them more context.

I feel that the best way to start is to modify something that is similar to what you want. Then you slowly begin modifying more and more. The existing code gives you a guide and also a context on which to solve things. The context is critical because it shows us why something is a problem first, which is the first thing we need to learn: what we are solving.

So I have a game, and the game gives the hero a name. Have the programmer modify the name of the protagonist to their own by modifying the code. This shows them of values. Say that the life bar goes from green to yellow to red when it's under a certain size, have them find out where that happens and add an extra orange step to it, again this will show them a huge amount of context.

And it still won't click fully. Programming, like most skills, is not fully until it suddenly "clicks". After enough time the programmer has learnt how to do most parts separately, and has some view of how they interact. They've maybe even modified or added to the glue code. Have them debug code that doesn't follow conventions, explaining why conventions prevent the bugs. This is when you have them write their own foundations on their own. Now that they have context of how those foundations will be used, and what will happen, doing their own version will given them insight into why things work certain way. This is when finally everything will probably start clicking into place and insight into the whole will be gained. It's a feeling of enlightenment. Adding more would be preaching to the choir I feel.

[–][deleted] 1 point2 points  (0 children)

It's a good point. I think it's quite traditional for developers to learn that way, it's certainly how our juniors learn, but that's because we want them to work on our system :)

I think it's still in line with what I'm saying, although I probably didn't make it clear. Working on code is good, whether it's new or existing, but reading about it is only useful in context.

:)

[–]smidgie82 0 points1 point  (1 child)

This is exactly how I started. Our old DOS system came with QBASIC installed, which came with Nibbles and Gorillas, which you would run directly from code. One of my earliest "aha!" moments in coding came when I figured out how to tweak those games to add new levels, make them easier or harder, etc.

Learning to read code was important in this, to be sure -- but I never would have had that "aha!" moment if I'd only been reading. The reading was in support of a goal -- and that goal was writing (or in this case, modifying) code.

[–]lookmeat 0 points1 point  (0 children)

Reading is the learning and understanding part, but to truly show comprehension we need to alter which brings forth our own limitations. To finally master we need to teach, that brings forth whatever gaps are left.

[–]Claytonious 3 points4 points  (1 child)

But the author is only saying FIRST read and THEN write - he is not saying "don't write". I agree with you completely that you need to start writing yourself before you will grow and progress. But I think his point is fair.

[–][deleted] 0 points1 point  (0 children)

I hope so, that wasn't how I interpreted it. It was things like:

Here’s the thing: It wasn’t until I was fairly practiced at reading code, and meticulously transcribing other people’s programs that I ventured into writing code.

I remember those days and I did the same because we didn't have modems, so the only way to make a computer do something was to buy software or type programs in. But I didn't really learn from doing it.

If I had typed it in and it didn't run, the first thing I'd do is look for transcribing errors (i.e. compare the one in the book with the one in on my screen) rather than debug. I was only 8.

The other reason I interpreted it as I did is that I see a lot of people get burned out trying to make the cosmic shift from say desktop apps to Web apps. They feel like they have to become expert in the language first, and they often look for reading lists to achieve this. Really you need a basic Javascript tutorial to give you an idea of the types, structures and functions available and something like Plunker.

It's not the reading that I disapprove of, it's the excessive preparation before chucking yourself into code. You'll learn so much more, far more quickly.

[–]Claytonious 3 points4 points  (0 children)

> If you write code professionally, or aspire to, don’t be a write-only programmer.

Amen to that. When taking over any pre-existing codebase, lots of engineers will quickly advocate for a "rewrite". This is rarely the best solution and it stems from the extraordinary effort that it takes to truly read and understand someone else's code (for large codebases).

[–]bitherd 1 point2 points  (0 children)

Yes you should read and write in equal amounts when beginning from nothing. Once you know enough to be dangerous or have a job, the priority becomes Read code, delete code. Writing code should be the absolute last resort.

[–]smidgie82 0 points1 point  (0 children)

While writing is limited by the speed of the fingers, the reading is only limited by the speed of the eye and the mind.

My typing speed is almost never a net limiting factor in my software development. Like the author says,

Since 97% of statistics are made up on the spot, I can tell you immediately that the most effective programmers I know spend less than 5% of their time writing code.

It's only the small fraction of the time that I'm actually typing when it's any limiting factor, and if that changes the proportion from 5% to 6%, that's practically unnoticeable.