5 ms·

Those that are complaining about this article: Care to share the experiences that made you a better programmer? Can you link to blog posts yourself or others ma

Those that are complaining about this article: Care to share the experiences that made you a better programmer? Can you link to blog posts yourself or others made that we may find useful?

pacaro 10y ago
I like this question! I think that working in constrained environments early in my career gave me lasting instincts both for efficiency and maintainability/sustainability. I wrote a lot of code on Win16, GeoOS, Epoc32, and a variety of embedded systems. Debugging tools aren't good, the dev-test-repeat cycle can be arbitrarily long, so you learn to avoid a certain sloppiness. I've been having fun with PICO-8 on a Pocket CHIP, it has some similar constraints, the keyboard is awful and the screen is small, so there are similar incentives, and the added bonus that making a cute game is fairly accessible.
- pacaro 10y ago
  Also, pre-internet I learned from books. I lived in a provincial town, so I would go to London, buy a book and then devour it, but if I didn't understand something, I had to either keep plugging away until I did understand it, or wait possibly weeks til my next opportunity to find another explanation. Keeping looking at blogs until you find an explanation that makes sense is an amazing resource for getting shit done, but doesn't encourage deep understanding when you really need to internalize something
- deleted 10y ago
  [deleted]
- thr0waway1239 10y ago
  Reminded me of this story about Donald Knuth: https://www.quora.com/How-would-Donald-Knuth-fare-as-a-competitor-on-TopCoder-today/answer/Michael-Hayter?srid=zo6v https://www.quora.com/How-would-Donald-Knuth-fare-as-a-compe...
couchand 10y ago
Reading every article I could find on Ward's Wiki [0]. Apologies about the current format, though some things have improved, I much prefered the simple old interface. [0]: http://wiki.c2.com/ http://wiki.c2.com/
chubot 10y ago
I've been doing the following for several years, and I think it's a good low commitment way of learning, i.e. there's a lot of bang for the buck. 1. Make a ~/git/scratch repository. 2. Whenever you see a code snippet in an interesting blog post, don't just read it. Copy it into a subdir of ~/git/scratch and run it. Write shell scripts to automate the process of running it. Prove to yourself on your computer that it works. The first few times, it may be a little onerous. But eventually you will fall into a groove and it will take 60 seconds or less each time. I don't promise to understand it on the first pass. Just the act of downloading it and running it gets it into your brain. Half the time you end up hacking on it anyway, and other times, you don't understand it, but when you see something related later, the light bulb will go off in your head -- "that's similar to something in my ~/git/scratch repo". And then you can go from there. I don't know why but having a running code snippet really makes it feel "ready at hand" and you will learn faster. It somehow primes your subconscious. I feel like there are a lot of people who read Hacker News a bit passively, without retention. Here's a good blog post along those lines, with code: http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/ http://journal.stuffwithstuff.com/2013/12/08/babys-first-gar... ----- A much bigger commitment, but with correspondingly bigger benefits: I found helpful was to reimplement like 10 different things I use in maybe 500 - 1000 lines of Python. I like the new "500 lines or less" book [1] -- I was doing this 10 years ago! Once you implement some class of program, you have a very good idea of how the "real" libraries you use are implemented. That helps you build better systems and write better code. Examples: A template language, a pattern matching language, test framework, protobuf serialization, a PEG parsing language, Unix tools like grep/sed/xargs, an event loop library based on Tornado, a package manager, static website generator and related tools, a web server, a web proxy, web framework, etc. In addition to writing something from scratch, I also find tiny code on the Internet and play around with it, like tinypy, OCamlLisp, femtolisp, xv6, etc. [1] http://aosabook.org/en/index.html http://aosabook.org/en/index.html
- gbersac 10y ago
  I'll take a look at the "500 lines or less" book.
collyw 10y ago
Not complaining about the article, but here are my thoughts. Write and maintain your own code for a significant amount of time. When you see bugs repeating themselves you have no one to blame but yourself. If you come back to code that you have written a few months later and you can't make sense of it fairly quickly, its probably time to refactor that part. Think about the design up front and the implications of doing things that way or another way.
- henrik_w 10y ago
  Very good advice! Also, supporting the code you write in production. Getting woken up to debug your own code really makes you write code that is well tested (as well as possible )and easy to debug.

Those that are complaining about this article: Care to share the experiences that made you a better programmer? Can you link to blog posts yourself or others made that we may find useful?

pacaro 10y ago

I like this question! I think that working in constrained environments early in my career gave me lasting instincts both for efficiency and maintainability/sustainability. I wrote a lot of code on Win16, GeoOS, Epoc32, and a variety of embedded systems. Debugging tools aren't good, the dev-test-repeat cycle can be arbitrarily long, so you learn to avoid a certain sloppiness. I've been having fun with PICO-8 on a Pocket CHIP, it has some similar constraints, the keyboard is awful and the screen is small, so there are similar incentives, and the added bonus that making a cute game is fairly accessible.

pacaro 10y ago
Also, pre-internet I learned from books. I lived in a provincial town, so I would go to London, buy a book and then devour it, but if I didn't understand something, I had to either keep plugging away until I did understand it, or wait possibly weeks til my next opportunity to find another explanation. Keeping looking at blogs until you find an explanation that makes sense is an amazing resource for getting shit done, but doesn't encourage deep understanding when you really need to internalize something
deleted 10y ago
[deleted]
thr0waway1239 10y ago
Reminded me of this story about Donald Knuth: https://www.quora.com/How-would-Donald-Knuth-fare-as-a-competitor-on-TopCoder-today/answer/Michael-Hayter?srid=zo6v https://www.quora.com/How-would-Donald-Knuth-fare-as-a-compe...

couchand 10y ago

Reading every article I could find on Ward's Wiki [0]. Apologies about the current format, though some things have improved, I much prefered the simple old interface. [0]: http://wiki.c2.com/ http://wiki.c2.com/

chubot 10y ago

I've been doing the following for several years, and I think it's a good low commitment way of learning, i.e. there's a lot of bang for the buck. 1. Make a ~/git/scratch repository. 2. Whenever you see a code snippet in an interesting blog post, don't just read it. Copy it into a subdir of ~/git/scratch and run it. Write shell scripts to automate the process of running it. Prove to yourself on your computer that it works. The first few times, it may be a little onerous. But eventually you will fall into a groove and it will take 60 seconds or less each time. I don't promise to understand it on the first pass. Just the act of downloading it and running it gets it into your brain. Half the time you end up hacking on it anyway, and other times, you don't understand it, but when you see something related later, the light bulb will go off in your head -- "that's similar to something in my ~/git/scratch repo". And then you can go from there. I don't know why but having a running code snippet really makes it feel "ready at hand" and you will learn faster. It somehow primes your subconscious. I feel like there are a lot of people who read Hacker News a bit passively, without retention. Here's a good blog post along those lines, with code: http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/ http://journal.stuffwithstuff.com/2013/12/08/babys-first-gar... ----- A much bigger commitment, but with correspondingly bigger benefits: I found helpful was to reimplement like 10 different things I use in maybe 500 - 1000 lines of Python. I like the new "500 lines or less" book [1] -- I was doing this 10 years ago! Once you implement some class of program, you have a very good idea of how the "real" libraries you use are implemented. That helps you build better systems and write better code. Examples: A template language, a pattern matching language, test framework, protobuf serialization, a PEG parsing language, Unix tools like grep/sed/xargs, an event loop library based on Tornado, a package manager, static website generator and related tools, a web server, a web proxy, web framework, etc. In addition to writing something from scratch, I also find tiny code on the Internet and play around with it, like tinypy, OCamlLisp, femtolisp, xv6, etc. [1] http://aosabook.org/en/index.html http://aosabook.org/en/index.html

gbersac 10y ago
I'll take a look at the "500 lines or less" book.

collyw 10y ago

Not complaining about the article, but here are my thoughts. Write and maintain your own code for a significant amount of time. When you see bugs repeating themselves you have no one to blame but yourself. If you come back to code that you have written a few months later and you can't make sense of it fairly quickly, its probably time to refactor that part. Think about the design up front and the implications of doing things that way or another way.

henrik_w 10y ago
Very good advice! Also, supporting the code you write in production. Getting woken up to debug your own code really makes you write code that is well tested (as well as possible )and easy to debug.