51–60 of 95 posts
Write code with testing it in mind. Testing is often introduced far too late in the programming learning process, if at all.
It's not something I did per se, but one former employer had mandatory pre-checkin code review. This is a controversial practice but in my experience, only with people who haven't really tried it. Not only does this help find bugs, it will force you to write code that isn't embarrassing. You will end up communicating much more with colleagues; before, during, and after the code review process. I believe it will clean…
It stops lazy check ins and it means at least 2 people know what code has gone in recently.
Refactor.
It might be enough to get a hack done to get some functionality working but if you never revisit it you wont learn what you did wrong or what you could have done better. Refactoring your solutions trying to improve efficiency, or usability (of the code), the process of examining your previous work and discovering how it could be made better will greatly benefit your learning process. Some times you may realize right away after finishing a piece of code how you could have done it better. Other times, its not until months or years later when you've learned and experienced more that upon revisiting the code you realize how you could improve it.
It's one thing to learn about programming techniques and designs, but it's refactoring your old attempts with those new techniques and designs that leads to understanding and empowerment.
One was to write a book about programming. Your programs literally have to be exemplary. It was interesting how much work that took.
I usually don't upvote pg's comments, because he could say "I like turtles." and get 1,000 upvotes, but pg's advice here is gold. You should do this. You don't even need a publisher, you could approach your topic like Zed Shaw did with "Learn Python The Hard Way". Or you could do a series of blog posts. You WILL get feedback and this will improve your skills.
I've made way more money from my "Slicehost vs Linode" article than I have from my portion of "Tcl and the Tk Toolkit, 2nd edition", even though the latter required a ton of hard work.
Earlier quoted context omitted.
I usually don't upvote pg's comments, because he could say "I like turtles." and get 1,000 upvotes, but pg's advice here is gold. You should do this. You don't even need a publisher, you could approach your topic like Zed Shaw did with "Learn Python The Hard Way". Or you could do a series of blog posts. You WILL get feedback and this will improve your skills.
If you're only focusing on the 'writing really good code' aspect, sure. But in the wider world, writing a book can be a spectacularly bad way to invest your time. I've made way more money from my "Slicehost vs Linode" article than I have from my portion of "Tcl and the Tk Toolkit, 2nd edition", even though the latter required a ton of hard work.
I wrote a framework. Instead of thinking, "How do I want this program to work?" I had to think, "How do I want every program to work?" Instead of organizing this data, I had to organize any data. Instead of worrying about what my customer needed, I had to worry about what to put in my toolbox before I called on that customer. Instead of handling the current outlying case, I had to learn to anticipate possible outlyin…
What do you think about YAGNI?
http://bit.ly/cpbljR (YAGNI Wikipedia article -- apparently HN doesn't like apostrophes in urls.)
I learned programming on a machine (ZX Spectrum+) which performed syntax checking as I typed. On the other hand, run-time errors often led to crash, making me loose my programs (system had no hard-disk!). Without me realizing then, it taught me how to write bug-free programs (since penalty for bugs used to be so high). Yet, with PC-based code editors, my programs have a lot of syntax errors.
I realized this when I met someone who could write five thousand lines of code without compiling even once and yet with less than two syntax errors!! This person was trained by writing programs on paper, and penalty for even syntax errors was set too high.
My lesson has been to dislike test-driven development. I like to certify my programs as correct by looking at them. When bugs are found during testing, my brain ends up getting trained automatically not to repeat those bugs without requiring tests to discover those bugs.
This is not something I did, but something that happened. Nevertheless, this was a valuable lesson for me: I learned programming on a machine (ZX Spectrum+) which performed syntax checking as I typed. On the other hand, run-time errors often led to crash, making me loose my programs (system had no hard-disk!). Without me realizing then, it taught me how to write bug-free programs (since penalty for bugs used to be so…