I don’t have the time or want to read the page, but I’m sure I’m already as good as him.
Three virtues of a great programmer
11–20 of 141 posts
Re: Three virtues of a great programmer
#12I would say that the character arc of Perl, and the profession generally, leads me to this observation: laziness and impatience are virtues. Be careful with hubris.
I'd say wisdom should be the third, but that in turn often leads to hubris.
Re: Three virtues of a great programmer
#13If you're not familiar with Larry Wall's style this might seem a bit off putting. The first time I ever saw him speak was the 1997 first annual O'Reilly Perl conference. I remember thinking, "This guy is a jerk" while also thinking "I love this guy"
Is there any publicly available talk of Larry Wall that might evoke it today?
Re: Three virtues of a great programmer
#14So I've always substituted arrogance for hubris: the belief that you better understand, and can better address, the requirements than any off-the-shelf library/program/ecosystem.
Re: Three virtues of a great programmer
#15Re: Three virtues of a great programmer
#16Re: Three virtues of a great programmer
#17Re: Three virtues of a great programmer
#18The really great coders I've worked with live and breathe the work, and come 5pm on a weekday they just continue on coding only this time for fun at home themselves.
Re: Three virtues of a great programmer
#19Re: Three virtues of a great programmer
#20I would also like to add one more thing: hesitation. From my own experience, in my programming career, the most time my team wasted was on redoing something from scratch. Why redo it? Because the previous design was not comprehensive enough to meet subsequent requirements. If everyone could spend more time researching and discussing the plan before starting, and get things right in one go, in my view, this is much mo…
You will never get it "right" the first time as much as you can avoid doing it "very wrong".
The key is to have enough experience and taste to appropriately break down problems into pieces that encapsulate the volatility of the various domains.
Then you can refactor easier which should be the real goal.
Prune and tend to the garden.