6 ms·

Practicing Programming

70 points by krat0sprakhar 14y ago

Cieplak 14y ago
Practicing Programming (2005)
- alpb 14y ago
  What's that?
  - krat0sprakhar 14y ago
    The essay was posted in 2005 by Steve Yegge.
    - packetslave 14y ago
      Was there something in the article that you feel is no longer relevant today? If not, who cares when it was posted?
jhspaybar 14y ago
This is some great stuff. Even though it's old it doesn't really matter. The same concepts still apply, and the ways to practice that he brings up are invaluable. As a programmer I often wonder how to improve, or if the things I'm doing actually help. Typically my only measure is encountering a problem in the wild, and being able to recall that one thing I read and typed up a few months back. To see how other successful programmers approach the problem of personal growth so as not to become stagnant in their fields is useful, especially to someone like me who is just starting their careers. Despite having gone through college pursuing a degree in CS, the learning I did on my own is some of the most valuable and now I have even more ways to keep learning independently!
- gizmo686 14y ago
  My solution to personal growth in programming is essentially, when I see a problem and know (or suspect) the existence of a tool better suited to answer it than what I would use, I learn the new tool. Granted I cannot always do that because of time. And in big projects the tools I have been using are the best solution because they are used everywhere else in the project, and I still want/need my work to be understandable by others without needing to learn a thousand different tools.
manish_gill 14y ago
I have a related question. When I try to do 'interview questions', I usually get stumped (I'm not really into math). In all the project Euler type problems that I've attempted, I find myself continuously using the Brute-force approach, only to find someone's very clever (and in hindsight, obvious) method to do the same. Or usually, I'll google the problem to find how someone else approached it, and only after I've studied it, or just 'took a peek', will I attempt my own solution. Now, I've studied Algorithms and data structures, and it's not that I'm bad at algorithms. I can understand well defined (aka classic) algorithms just fine, but I find it really hard to find (or create!) patterns in numbers and to manipulate them in order to solve a complex problem. Any suggestions on how can I improve myself?
- priestc 14y ago
  Stop trying so hard. Writing algorithms is a lot like writing poetry, you just have to let it come to you. Whenever I come across a problem that the answer doesn't immediately jump out at me, I stop what I'm doing and do something else. A few hours later, maybe a few days later, the solution will jump out at me.
- yummyfajitas 14y ago
  Practice. More specifically, divide your practice problems into two categories before you start working on them. Category A - don't peek. Category B - do peek, and try to learn from others. Category A will ultimately be where the real learning occurs.
- 3pt14159 14y ago
  When attempting a problem that has an obvious brute force solution ask yourself why the brute force solution is wasteful. "It is wasteful because if I've already compared element A and element B, and I've already compared element B and element C then in some cases I shouldn't need to compare element C and element A." Is the type of thinking you should be having. This will lead you towards the right data structures and algorithms. Also, understanding sets and set theory really helps too.
- gizmo686 14y ago
  1) Start with a brute force solution, and then look for optimizations. A good way to do this is have it print out (or display in some form) each of its guesses. You will almost allways see it do something stupid, at which point you found an optimization. 2) Write downs as many observations about the problem as you can; if possible, write them down in mathematical notation. See what you can find by combining observations. 3) If you have some sense of what a solution might look like, write it down and see where it goes; don't wait until you think you have the entire answer. 4) When you look at other people algorithms, as soon as you see them do something you didn't, put there paper to the side, do what they did, and see where you can take it on your own. 5) If what you are doing looks related to a subject you are not fammilar with, research that subject. 6) Similarly, if you can reduce a problem (or sub-problem) to another one, but you have no idea how to solve the new one, research to see if people have already solved your new one. 7) If you every see a sequence of numbers, go here: http://oeis.org/ http://oeis.org/ 7b) If the only description in oeis is a link to the Project Euler problem you are solving, then this technique is probably to cheety. 8) Invent to variables/functions 9) Math notation is there to help you, make up your own if it expresses the problem more cleanly. 10) Never right a false statement on your work paper unless it is clearly indicated by words like "assume" or "not". 10b) If you see a statement on one of your papers, assume that it is true even if you forgot why.
pycassa 14y ago
sorry off topic.. but can some one please explain this "It's(American football) more like playing chess than playing soccer."
- RegEx 14y ago
  American football can be viewed as a chess match between the opposing coaches, with the players having the job of executing the coaches' strategies as perfectly as possible. Each play, both on offense and defense, is designed and planned. Here's an example play chart[0]. Soccer, on the other hand, is relatively continuous. The closest thing to an American football play would be how the teams prepare for Set plays such as corner kicks and free kicks, or their overall formation. It's not viewed as a series of "moves" like American Football. [0]: http://www.wheelbarrowsoftware.com/images/fpd/fs5.jpg http://www.wheelbarrowsoftware.com/images/fpd/fs5.jpg
jdefr89 14y ago
Although I appreciate what the article has to say (indeed its true); I think we are having an issue with the reverse with regards to the SMARTS/SKILLS/JOBS sections. Most new computer scientist/engineers these days DON'T KNOW FUNDAMENTALS WELL. You may say people who code in Assembly (or are learning it) are foolish; that couldn't be farther from the truth. Keeping up to date with your low-level computing knowledge forms a base to work on any other abstraction layer up the chain. The core concepts important in older skills will still be important 1000 years down the road. With the older generation fading out I fear we will lose a lot of the fundamental, gritty knowledge that all other programming is based on. You don't see many new-age programmers learning about low-level details like memory, and i/o. Yet, in years to come if we need to make changes and possibly rebuild some things from close to the hardware we may end up in the dark. Without the people who handled a lot of the hardcore stuff, we may potentially lose knowledge when todays younger generation steps up to the plate. So basically my argument is that any serious hacker should be able to conceptualize a fully working machine from the logic gates to the software. Understanding the primitive components of a computer system helps you everywhere else and will most likely never be knowledge that becomes obsolete.
- derleth 14y ago
  Fundamentals are algorithm design and complexity analysis, not the accidental complexities of some specific piece of hardware nobody will be using in twenty years. On the flip side, there will always be teenagers. There will always be people attracted to assembly language for the same reasons I was: A love of complexity and half-formed (and mostly mistaken) ideas about what programming really is.
  - spec_laconic 14y ago
    I completely agree. As I get older, I find the abstractions to be much more interesting; how does one express a lambda in assembly? Functional programming in general? The simplicity of Python and the beauty of Lisp / Scheme / f# keep me going as a programmer. I wonder, as assembly languages become more complex and malformed with the introduction of ARM and all of the headaches of custom architectures, if there won't be more people moving to the higher level, just for sanity's sake.
alexeiz 14y ago
Great article. The programming practice "drills" come a little short though. You'd be better off reading the article and then deciding for yourself the way you should practice. My favorite ways of practicing and keeping my programming skills up-to-date is to do micro-projects taking about 2 or 3 days. It can be some challenging algorithmic problem, or solving a problem in a new language I want to get familiar with, or using a new library to do some interesting tasks, or trying a new build tool on one of my old projects. It's fun, it doesn't take long to get bored or tired and you learn something new.

70 points by krat0sprakhar 14y ago

Cieplak 14y ago

Practicing Programming (2005)

alpb 14y ago
What's that?
- krat0sprakhar 14y ago
  The essay was posted in 2005 by Steve Yegge.
  - packetslave 14y ago
    Was there something in the article that you feel is no longer relevant today? If not, who cares when it was posted?

jhspaybar 14y ago

This is some great stuff. Even though it's old it doesn't really matter. The same concepts still apply, and the ways to practice that he brings up are invaluable. As a programmer I often wonder how to improve, or if the things I'm doing actually help. Typically my only measure is encountering a problem in the wild, and being able to recall that one thing I read and typed up a few months back. To see how other successful programmers approach the problem of personal growth so as not to become stagnant in their fields is useful, especially to someone like me who is just starting their careers. Despite having gone through college pursuing a degree in CS, the learning I did on my own is some of the most valuable and now I have even more ways to keep learning independently!

gizmo686 14y ago
My solution to personal growth in programming is essentially, when I see a problem and know (or suspect) the existence of a tool better suited to answer it than what I would use, I learn the new tool. Granted I cannot always do that because of time. And in big projects the tools I have been using are the best solution because they are used everywhere else in the project, and I still want/need my work to be understandable by others without needing to learn a thousand different tools.

manish_gill 14y ago

I have a related question. When I try to do 'interview questions', I usually get stumped (I'm not really into math). In all the project Euler type problems that I've attempted, I find myself continuously using the Brute-force approach, only to find someone's very clever (and in hindsight, obvious) method to do the same. Or usually, I'll google the problem to find how someone else approached it, and only after I've studied it, or just 'took a peek', will I attempt my own solution. Now, I've studied Algorithms and data structures, and it's not that I'm bad at algorithms. I can understand well defined (aka classic) algorithms just fine, but I find it really hard to find (or create!) patterns in numbers and to manipulate them in order to solve a complex problem. Any suggestions on how can I improve myself?

priestc 14y ago
Stop trying so hard. Writing algorithms is a lot like writing poetry, you just have to let it come to you. Whenever I come across a problem that the answer doesn't immediately jump out at me, I stop what I'm doing and do something else. A few hours later, maybe a few days later, the solution will jump out at me.
yummyfajitas 14y ago
Practice. More specifically, divide your practice problems into two categories before you start working on them. Category A - don't peek. Category B - do peek, and try to learn from others. Category A will ultimately be where the real learning occurs.
3pt14159 14y ago
When attempting a problem that has an obvious brute force solution ask yourself why the brute force solution is wasteful. "It is wasteful because if I've already compared element A and element B, and I've already compared element B and element C then in some cases I shouldn't need to compare element C and element A." Is the type of thinking you should be having. This will lead you towards the right data structures and algorithms. Also, understanding sets and set theory really helps too.
gizmo686 14y ago
1) Start with a brute force solution, and then look for optimizations. A good way to do this is have it print out (or display in some form) each of its guesses. You will almost allways see it do something stupid, at which point you found an optimization. 2) Write downs as many observations about the problem as you can; if possible, write them down in mathematical notation. See what you can find by combining observations. 3) If you have some sense of what a solution might look like, write it down and see where it goes; don't wait until you think you have the entire answer. 4) When you look at other people algorithms, as soon as you see them do something you didn't, put there paper to the side, do what they did, and see where you can take it on your own. 5) If what you are doing looks related to a subject you are not fammilar with, research that subject. 6) Similarly, if you can reduce a problem (or sub-problem) to another one, but you have no idea how to solve the new one, research to see if people have already solved your new one. 7) If you every see a sequence of numbers, go here: http://oeis.org/ http://oeis.org/ 7b) If the only description in oeis is a link to the Project Euler problem you are solving, then this technique is probably to cheety. 8) Invent to variables/functions 9) Math notation is there to help you, make up your own if it expresses the problem more cleanly. 10) Never right a false statement on your work paper unless it is clearly indicated by words like "assume" or "not". 10b) If you see a statement on one of your papers, assume that it is true even if you forgot why.

pycassa 14y ago

sorry off topic.. but can some one please explain this "It's(American football) more like playing chess than playing soccer."

RegEx 14y ago
American football can be viewed as a chess match between the opposing coaches, with the players having the job of executing the coaches' strategies as perfectly as possible. Each play, both on offense and defense, is designed and planned. Here's an example play chart[0]. Soccer, on the other hand, is relatively continuous. The closest thing to an American football play would be how the teams prepare for Set plays such as corner kicks and free kicks, or their overall formation. It's not viewed as a series of "moves" like American Football. [0]: http://www.wheelbarrowsoftware.com/images/fpd/fs5.jpg http://www.wheelbarrowsoftware.com/images/fpd/fs5.jpg

jdefr89 14y ago

Although I appreciate what the article has to say (indeed its true); I think we are having an issue with the reverse with regards to the SMARTS/SKILLS/JOBS sections. Most new computer scientist/engineers these days DON'T KNOW FUNDAMENTALS WELL. You may say people who code in Assembly (or are learning it) are foolish; that couldn't be farther from the truth. Keeping up to date with your low-level computing knowledge forms a base to work on any other abstraction layer up the chain. The core concepts important in older skills will still be important 1000 years down the road. With the older generation fading out I fear we will lose a lot of the fundamental, gritty knowledge that all other programming is based on. You don't see many new-age programmers learning about low-level details like memory, and i/o. Yet, in years to come if we need to make changes and possibly rebuild some things from close to the hardware we may end up in the dark. Without the people who handled a lot of the hardcore stuff, we may potentially lose knowledge when todays younger generation steps up to the plate. So basically my argument is that any serious hacker should be able to conceptualize a fully working machine from the logic gates to the software. Understanding the primitive components of a computer system helps you everywhere else and will most likely never be knowledge that becomes obsolete.

derleth 14y ago
Fundamentals are algorithm design and complexity analysis, not the accidental complexities of some specific piece of hardware nobody will be using in twenty years. On the flip side, there will always be teenagers. There will always be people attracted to assembly language for the same reasons I was: A love of complexity and half-formed (and mostly mistaken) ideas about what programming really is.
- spec_laconic 14y ago
  I completely agree. As I get older, I find the abstractions to be much more interesting; how does one express a lambda in assembly? Functional programming in general? The simplicity of Python and the beauty of Lisp / Scheme / f# keep me going as a programmer. I wonder, as assembly languages become more complex and malformed with the introduction of ARM and all of the headaches of custom architectures, if there won't be more people moving to the higher level, just for sanity's sake.

alexeiz 14y ago

Great article. The programming practice "drills" come a little short though. You'd be better off reading the article and then deciding for yourself the way you should practice. My favorite ways of practicing and keeping my programming skills up-to-date is to do micro-projects taking about 2 or 3 days. It can be some challenging algorithmic problem, or solving a problem in a new language I want to get familiar with, or using a new library to do some interesting tasks, or trying a new build tool on one of my old projects. It's fun, it doesn't take long to get bored or tired and you learn something new.