

Going Beyond Code to Become a Better Programmer - GarethX
http://blog.fogcreek.com/going-beyond-code-to-become-a-better-programmer-interview-with-pete-goodliffe/

======
koevet
> What are some resources you can recommend for those seeking to become better
> programmers?

> The biggest thing for me, and that I have done personally and continue to
> do, is to sit at the feet of great coders. I have learned the most in my
> career when I have been around excellent people who I can learn off of.

I find hard to meet passionate developers from which I can learn from.

Likely, this is due to my career choices (I'm a consultant for large
corporations). The last time I worked with a brilliant developer was ages ago.
Most of the people I work with in these contracts, are 8-5 drones who are
stuck with Java 6 and they are afraid of every new bit of technology (to be
fair, it's hard to even tests certain technologies for them). Anyway, this is
one of the biggest regrets of my professional life.

------
hyperchase
These are pretty good tips, and I would add one. This was the tipping point
for me, when I started to notice that I was becoming an actual, honest to God,
better programmer..when I stopped thinking of the work I was doing in terms of
what design patterns and cool new tech I could use to finish a story and
started thinking in terms of "how is the work that I'm doing bringing value to
the business, and what can I do to maximize that value at a relatively low
cost".

------
naringas
> Write Less Code

One has got to be careful with this...

Sometimes making code more concise really makes it more obscure. I suppose
it's possible err on both sides, you don't want to be too verbose either. I
think the point is to write readable, maintainable code.

"explicit is better than implicit"

~~~
MichaelGG
I'm pretty sure he's referring to things like unneeded patterns, extra
abstraction. I'd add stuff like "one type per file" (totally breaks down if
you don't have large types). Or pointless use of classes/instances, when
you're just providing functions. For example, if you create a "SendEmail"
function, then needlessly put it in an object. If the object isn't carrying
any state, and if you're just replacing "EmailThing.SendEmail" with "var x =
new EmailThing(); x.SendEmail" \-- that's pointless extra code and can be
removed.

As I've gotten more experienced, I do less "ceremony" and more "write code
that does stuff". It hasn't seem to hurt, and I end up with less code to
maintain.

Explicit is not always better than implicit. If you're being explicit about
obvious facts, that's pointless verbosity. Type inference is a good thing;
take advantage of it. Implicit's only an issue when there's complicated or
hidden rules at play. For instance with automatic conversion operators that do
"magic".

~~~
koevet
How do you test the code that needs to send an email, if your "SendEmail"
function is not in a separate class that can be mocked?

(ok, you can use a fake smtp server, but it makes tests more complex, imo)

~~~
spinningarrow
Why can't you mock the function? Mocks aren't specific to classes.

------
EliRivers
I read his previous book, "Code Craft", when it came out back in 2006 (I
think). I preferred it to the heavyweight of the day, McConnell's "Code
Complete". "Code Complete" was more like a reference book, but "Code Craft"
was something that flowed well from cover to cover (to be fair, they are
clearly meant to be different kinds of book; "Code Complete" _is_ structured
more as a reference book); much more readable as a book. Definitely worth a
read, especially if you've got a couple of years practical code monkey
experience under your belt and want to improve rather than just spending the
next decade getting the same year's experience over and over.

It was also from No Starch, and at risk of repeating myself across threads,
it's just nice paper and a good binding and I swear it does smell good.

Anyway, if anyone's got "Code Craft" and this one, I'd be interested in what
the differences are.

------
welder
I agree with everything he says, but not much actionable information in the
interview.

------
pacaro
It's hard not to agree with the advice, I like to think of his observations
about humility in terms of not being so ego attached, both in terms of how
much I know, and in terms of ownership

------
matt_s
I identify with the part about commenting to yourself in the code, at least to
yourself 2 years from now. Obviously the comments should be for anyone but it
is a good work practice to comment on why you did something or how a piece of
code relates to the overall program.

Chances are if you wrote it, you'll be fixing bugs for it so help yourself
out. You won't have the context you currently have when you open that code up
in a couple years, so put some context in the comments.

------
lukasm
Sorry, but the sound quality is really poor.

~~~
GarethX
Yeah, sorry about that. It was truly one of those days - we had all kinds of
problems with the connection and software, I was just pleased to get something
out of it at all (note how the sky darkens in the background!). Hopefully the
transcript will help you.

~~~
codemac
Yes! Transcripts are awesome, thank you for providing one!

~~~
mreams
Seconded, transcripts are really helpful!

------
amelius
> What are some resources you can recommend for those seeking to become better
> programmers?

> The biggest thing for me, and that I have done personally and continue to
> do, is to sit at the feet of great coders. I have learned the most in my
> career when I have been around excellent people who I can learn off of.

I can see this would help, but what kind of advice is that really? Since he is
the author of this book, he is the one who should be teaching us something;
not telling us we should look for advice elsewhere.

------
panjaro
Disappointed with the sound quality !!!!

------
michaelb123
These interviews are great.

FogBugz search algo is not :)

~~~
vailripper
FogBugz period not so much.

Still blows my mind that this is the same company that built Trello....

