6 May
2017
6 May
'17
8:40 p.m.
On Sat, May 06, 2017 at 09:18:57AM +0000, Michael Kj??rling wrote:
On 5 May 2017 22:33 -0700, from scj(a)yaccman.com (Steve
Johnson):
When I run engineering teams the point I make is if you wrote the code
more than 6 months ago it might as well be someone else's code. So
write it in a way that someone else can debug / extend it.
I also made the point that "clever" sucks. At least most of the time.
All "clever" means is "hard to understand". The brief joy one gets
from clever code is stomped on by the frustration one gets from having
to fix it.
When they wouldn't listen to that I'd say "I'm the dumbest guy here,
right?
And I'm the boss. And I debug could. The path to a big bonus does not
go through clever code". That seemed to work.
Personally, I find code that is clean, straightforward, obvious to be
beautiful. The clever stuff usually strikes an odd note, not a good
one.
--lm
For me, a lot of what
I learned was from Stan Brown at the Labs, who read piles of my
(atrocious) FORTRAN code and repeatedly pointed out that when you
wrote a program, you were not just communicating with the computer,
but also other humans (including yourself) who would read (and perhaps
modify) the code in the future...
I would actually take that one step further: When you are writing
code, you are _first and foremost_ communicating with whatever human
will need to read or modify the code later. That human might be you, a
colleague, or the violent psychopath who knows both where you live and
where your little kids go to school (might as well be you).