Tuesday, December 17, 2013
Sunday, September 1, 2013
The Myth of the Genius Programmer
I've listed a few interesting note from my point of view
don't hide code, balance between spinning the wheel being lost and asking the person next to you every question that come into your head.
bus factor: having many people know the code in case the only person is hit by the bus, whether that bus comes in a form of a real bus or getting married, sick...
nobody sits down for thousands line of code before they compile...
u want other people see what u doing. you don't learn
"publish or perish"
give construct criticism.
when failure comes, be ready for it. Document and learn.
fail faster so learn faster
practice
don't try to be genious
collaborate early and often
brain crack: to roll out the idea
learn to be small fish, or looking around for big fish
http://www.youtube.com/watch?v=0SARbwvhupQ
Labels:
programming
Wednesday, August 28, 2013
“abandon all hope, ye who enter here.”
haha..this is a cool comment
... ...
I might mention that there is a dark side to using complex algorithms in software systems. The algorithms may not be understandable by others (or even the original author, after a long passage of time). I had incorporated some sophisticated regular expression pattern matching technology into AWK. Although it is documented in the Red Dragon book, Brian Kernighan once took took a look at the pattern-matching module that I had written and his only addition to that module was putting a comment in ancient Italian: “abandon all hope, ye who enter here.” As a consequence, neither Kernighan or Weinberger would touch that part of the code. I was the one that always had to make the bug fixes to that module!
can someone become a better programmer?
Al: My number one suggestion is to think before you program. Then I would advocate
writing lots of code, having experts critique your code, reading good code written by
others, and participating in code reviews. If you’re really brave, you could try to teach students to write good code.
I have certainly found that in every book that I have written with programs in it, the programs have gotten more efficient and shorter with the writing of the book. During the year we wrote the AWK book, many of the programs in it became 50% shorter. This is because we learned how to use the abstractions in AWK even more effectively than we initially had thought.
Subscribe to:
Posts (Atom)