8 ms·

The primary emphasis of this article seems to be: "Stop playing with code and start reading books". Reading a book is a great way to get a lot of theoretical kn

by taurath 11y ago

The primary emphasis of this article seems to be: "Stop playing with code and start reading books". Reading a book is a great way to get a lot of theoretical knowledge but mapping it to a real problem or solution is what causes the knowledge to stick. Programmers have to balance theory and usage to do well. You can't learn to be an artist by studying everything about paintbrushes first. Certainly you could, but it won't help you understand the motions to paint. At the same time randomly using any brush that can barely work probably won't get you the results you want. I hope the author someday realizes that almost everything is a continuum. Lamenting that "programmers of today" don't read enough books doesn't really tell you much - only that he wishes the people he see's would think more about theory.

hartator 11y ago
I would say the balance should be a 10:1 where 10 is learning (books, articles, HN, docs, playing around...) and 1 is actually doing the work.
peruvian 11y ago
A lot of newbies get stuck in what I call a "tutorial loop": They finish some mediocre/hand-holding tutorial, but they don't feel like they can write anything yet, so they go to another one, and another one, etc. They never end up building anything because they preoccupied with being "ready" before doing anything. I say, stop reading tutorials, hit up the documentation/IRC, and build something. Won't be easy but that's how you learn!
- sdrothrock 11y ago
  I encounter the same thing when people try to learn to study Japanese -- they keep dancing around it by reading about how other people learned/studied, weighing the pros/cons of various approaches and textbooks, etc. I call it "analysis paralysis."
  - tetraodonpuffer 11y ago
    I think it is paradoxically a lot harder now to start than it used to be, way back you had basic on your computer (if you started when I did) or maybe turbo pascal (some years later), and that was it, you wanted something you started to write. Now say you want to put together a web application, you're going to google and immediately you'll get a billion stack options with very opinionated people in each camp, it's hard to choose what to do. Having some guidance to start is good, otherwise you end up like I did in my teens, where the second program I started writing was a text adventure game where every room was a separate block of code with if/equals text parsing where I eventually ran out of memory due (64k wasn't much) if I had found that article talking about text parsers and data structures it would have saved me a lot of time :) Nowadays though it's hard to get only some guidance if you want to start on something, and so analysis-paralysis is a significant risk.
    - vectorjohn 11y ago
      I've been a full time developer for 8 or so years now, and I can say, the most complex personal projects I ever finished were when I started in BASIC, before I knew what an array was. That is partly due to lack of motivation to work outside of work, but partly due to analysis paralysis when I try starting a new project. I get pretty far in, and then realize all the things I should consider and scaffolding I need to build, etc, that I lose interest. So in other words, I agree.
      - seivan 11y ago
        Yep. The more you learn, the more you realised how little you knew. It's pretty bad actually. Not sure how to get out of it.
        sdrothrock 11y ago
        I'd noticed this for a while before I found out what it's actually called. Maybe this will interest you, too. :) https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
- seivan 11y ago
  It goes by another name as well https://en.wikipedia.org/wiki/Analysis_paralysis https://en.wikipedia.org/wiki/Analysis_paralysis
- iNerdier 11y ago
  This is slightly painful reading. As someone on the periphery of coding I've been stuck in that loop for years that are rapidly approaching a decade. I think more than just doing these things it's vitally important to have people around you that you can ask questions to. While I'm sure there are some autodidacts who can make do with an IRC channel and google I've only ever had things stick when there's a real life person in the room I can keep on asking dumb questions to.
bronxbomber92 11y ago
I completely disagree with your summarization. The emphasis is on understanding both the problem domain and, more importantly, the codebase. Understanding the problem domain may come from reading books, but it may come from asking senior members of your team, too. Understanding the code base will not come from an appreciation of the theoretical, however. Modifying code whose interactions you don't have a solid understand of is a recipe for disaster, but occurs all too often.
Retric 11y ago
The problem with 'just coding something' is your stuck with tiny problems and lessons related to those tiny problems. IMO, once you get past the basic, I can program tick tack toe by hand, you need to take a year or two and learn from other peoples mistakes. Otherwise, most self taut programmers have a world of bad habits that only really bite them when part of a team. The only real exception to that is when you have someone on hand to read your code and offer real advice. Don't use a for loop here use a foreach. Functions should mean something, don't just cut a program up and stick the top half in one function and the bottom half in another. etc etc. PS: Number one thing to look for in a first job is a company that does real code reviews by competent people.
- jqm 11y ago
  Basically I agree but there is an additional way one starts to learn about best practices.... Having to maintain/extend a project you've written (poorly) for an indefinite amount of time. Next time around you are a lot more careful and start searching out best practices. Rinse and repeat.
  - TeMPOraL 11y ago
    Moreover, being aware of the pain points lets you actually understand what various popular tools are about. You can then start incorporating them into your projects because you know what problems they're solving. It's easier to understand the value of, say, Docker if you had to develop your project on three different machines and went through setting up the environment and dependencies on each of them.
- cloverich 11y ago
  My suggestion is that people who are learning, especially if self-taught, should dive into other peoples source code as soon as possible. Build something of medium complexity, then choose a couple of either the simplest or most useful libraries you used, and start reading the source.
overgard 11y ago
Playing with code is a great way to learn things! I mean, yeah, don't check in your experiments, but the notion that you're going to gain more from reading a book compared to actual usage... I don't know, it probably depends on the person, but either way is a totally viable way to learn things.
quietplatypus 11y ago
Also, it's like, "What books?" Programming any nontrivial piece of software not covered in a tutorial is not going to be in a book. Or it should be? But there are cooking recipes where as long as you have the tools and ingredients, you can follow the steps and learn/generalize from that and you're cookin'. Same for just about any non-joke topic on wikihow. Call me when there's a book on exactly (I mean not just talking in useless generalities) how to build and maintain a particular modern machine learning / robotics control / operating system. There just isn't, because a) they are that complex and b) our culture discourages actual education when it comes to programming. Hell, even auto mechanics, maintenance programmers of the physical realm, get Haynes manuals for all the vehicles they might plausibly work on, which is a goldmine of material for knowledge development. Right now, it's just so much more efficient to actually run the damn code and let the computer collect your data. I feel like software engineers of the future should write down everything they know about the programs they are working on, or at least all the steps of development and maintenance, so it's easier to get their internal theory.
qb45 11y ago
> The primary emphasis of this article seems to be: "Stop playing with code and start reading books". It's more like "Start reading books about the code you play with". Personally, I've always hated when people copy-paste some code without bothering to understand it and I think this is also what the author rants about. By "bothering to understand" I mean read the code author's comments or docs, then read the code and make sure it looks like it actually does what's advertised, modify things you don't like/need, play a bit with things you totally can't understand. Test it before plugging into something bigger and having to debug it then. Or, to use OP,s analogy: Got an appliance? RTFM before you waste few hours using it suboptimally or it cuts your fingers.

by taurath 11y ago

hartator 11y ago

I would say the balance should be a 10:1 where 10 is learning (books, articles, HN, docs, playing around...) and 1 is actually doing the work.

peruvian 11y ago

A lot of newbies get stuck in what I call a "tutorial loop": They finish some mediocre/hand-holding tutorial, but they don't feel like they can write anything yet, so they go to another one, and another one, etc. They never end up building anything because they preoccupied with being "ready" before doing anything. I say, stop reading tutorials, hit up the documentation/IRC, and build something. Won't be easy but that's how you learn!

sdrothrock 11y ago
I encounter the same thing when people try to learn to study Japanese -- they keep dancing around it by reading about how other people learned/studied, weighing the pros/cons of various approaches and textbooks, etc. I call it "analysis paralysis."
- tetraodonpuffer 11y ago
  I think it is paradoxically a lot harder now to start than it used to be, way back you had basic on your computer (if you started when I did) or maybe turbo pascal (some years later), and that was it, you wanted something you started to write. Now say you want to put together a web application, you're going to google and immediately you'll get a billion stack options with very opinionated people in each camp, it's hard to choose what to do. Having some guidance to start is good, otherwise you end up like I did in my teens, where the second program I started writing was a text adventure game where every room was a separate block of code with if/equals text parsing where I eventually ran out of memory due (64k wasn't much) if I had found that article talking about text parsers and data structures it would have saved me a lot of time :) Nowadays though it's hard to get only some guidance if you want to start on something, and so analysis-paralysis is a significant risk.
  - vectorjohn 11y ago
    I've been a full time developer for 8 or so years now, and I can say, the most complex personal projects I ever finished were when I started in BASIC, before I knew what an array was. That is partly due to lack of motivation to work outside of work, but partly due to analysis paralysis when I try starting a new project. I get pretty far in, and then realize all the things I should consider and scaffolding I need to build, etc, that I lose interest. So in other words, I agree.
    - seivan 11y ago
      Yep. The more you learn, the more you realised how little you knew. It's pretty bad actually. Not sure how to get out of it.
      - sdrothrock 11y ago
        I'd noticed this for a while before I found out what it's actually called. Maybe this will interest you, too. :) https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
seivan 11y ago
It goes by another name as well https://en.wikipedia.org/wiki/Analysis_paralysis https://en.wikipedia.org/wiki/Analysis_paralysis
iNerdier 11y ago
This is slightly painful reading. As someone on the periphery of coding I've been stuck in that loop for years that are rapidly approaching a decade. I think more than just doing these things it's vitally important to have people around you that you can ask questions to. While I'm sure there are some autodidacts who can make do with an IRC channel and google I've only ever had things stick when there's a real life person in the room I can keep on asking dumb questions to.

bronxbomber92 11y ago

I completely disagree with your summarization. The emphasis is on understanding both the problem domain and, more importantly, the codebase. Understanding the problem domain may come from reading books, but it may come from asking senior members of your team, too. Understanding the code base will not come from an appreciation of the theoretical, however. Modifying code whose interactions you don't have a solid understand of is a recipe for disaster, but occurs all too often.

Retric 11y ago

The problem with 'just coding something' is your stuck with tiny problems and lessons related to those tiny problems. IMO, once you get past the basic, I can program tick tack toe by hand, you need to take a year or two and learn from other peoples mistakes. Otherwise, most self taut programmers have a world of bad habits that only really bite them when part of a team. The only real exception to that is when you have someone on hand to read your code and offer real advice. Don't use a for loop here use a foreach. Functions should mean something, don't just cut a program up and stick the top half in one function and the bottom half in another. etc etc. PS: Number one thing to look for in a first job is a company that does real code reviews by competent people.

jqm 11y ago
Basically I agree but there is an additional way one starts to learn about best practices.... Having to maintain/extend a project you've written (poorly) for an indefinite amount of time. Next time around you are a lot more careful and start searching out best practices. Rinse and repeat.
- TeMPOraL 11y ago
  Moreover, being aware of the pain points lets you actually understand what various popular tools are about. You can then start incorporating them into your projects because you know what problems they're solving. It's easier to understand the value of, say, Docker if you had to develop your project on three different machines and went through setting up the environment and dependencies on each of them.
cloverich 11y ago
My suggestion is that people who are learning, especially if self-taught, should dive into other peoples source code as soon as possible. Build something of medium complexity, then choose a couple of either the simplest or most useful libraries you used, and start reading the source.

overgard 11y ago

Playing with code is a great way to learn things! I mean, yeah, don't check in your experiments, but the notion that you're going to gain more from reading a book compared to actual usage... I don't know, it probably depends on the person, but either way is a totally viable way to learn things.

quietplatypus 11y ago

Also, it's like, "What books?" Programming any nontrivial piece of software not covered in a tutorial is not going to be in a book. Or it should be? But there are cooking recipes where as long as you have the tools and ingredients, you can follow the steps and learn/generalize from that and you're cookin'. Same for just about any non-joke topic on wikihow. Call me when there's a book on exactly (I mean not just talking in useless generalities) how to build and maintain a particular modern machine learning / robotics control / operating system. There just isn't, because a) they are that complex and b) our culture discourages actual education when it comes to programming. Hell, even auto mechanics, maintenance programmers of the physical realm, get Haynes manuals for all the vehicles they might plausibly work on, which is a goldmine of material for knowledge development. Right now, it's just so much more efficient to actually run the damn code and let the computer collect your data. I feel like software engineers of the future should write down everything they know about the programs they are working on, or at least all the steps of development and maintenance, so it's easier to get their internal theory.

qb45 11y ago

> The primary emphasis of this article seems to be: "Stop playing with code and start reading books". It's more like "Start reading books about the code you play with". Personally, I've always hated when people copy-paste some code without bothering to understand it and I think this is also what the author rants about. By "bothering to understand" I mean read the code author's comments or docs, then read the code and make sure it looks like it actually does what's advertised, modify things you don't like/need, play a bit with things you totally can't understand. Test it before plugging into something bigger and having to debug it then. Or, to use OP,s analogy: Got an appliance? RTFM before you waste few hours using it suboptimally or it cuts your fingers.