7 ms·

Going Beyond Code to Become a Better Programmer

159 points by GarethX 11y ago

lukasm 11y ago
Sorry, but the sound quality is really poor.
- GarethX 11y ago
  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 11y ago
    Yes! Transcripts are awesome, thank you for providing one!
    - mreams 11y ago
      Seconded, transcripts are really helpful!
welder 11y ago
I agree with everything he says, but not much actionable information in the interview.
michaelb123 11y ago
These interviews are great. FogBugz search algo is not :)
- vailripper 11y ago
  FogBugz period not so much. Still blows my mind that this is the same company that built Trello....
naringas 11y ago
> 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"
- ColinDabritz 11y ago
  I think perhaps a better phrasing is 'write simpler code', code that expresses what it needs to as directly as possible, without unnecessary complexity. This code does tend toward smaller more compact expression, but you're chasing the simplicity more than the literal absolute size.
  - x5n1 11y ago
    usually when you do this size goes up. the number of files goes up.
- MichaelGG 11y ago
  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 11y ago
    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)
pacaro 11y ago
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
koevet 11y ago
> 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.
EliRivers 11y ago
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.
amelius 11y ago
> 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.
hyperchase 11y ago
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".
panjaro 11y ago
Disappointed with the sound quality !!!!
matt_s 11y ago
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.

159 points by GarethX 11y ago

lukasm 11y ago

Sorry, but the sound quality is really poor.

GarethX 11y ago
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 11y ago
  Yes! Transcripts are awesome, thank you for providing one!
  - mreams 11y ago
    Seconded, transcripts are really helpful!

welder 11y ago

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

michaelb123 11y ago

These interviews are great. FogBugz search algo is not :)

vailripper 11y ago
FogBugz period not so much. Still blows my mind that this is the same company that built Trello....

naringas 11y ago

> 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"

ColinDabritz 11y ago
I think perhaps a better phrasing is 'write simpler code', code that expresses what it needs to as directly as possible, without unnecessary complexity. This code does tend toward smaller more compact expression, but you're chasing the simplicity more than the literal absolute size.
- x5n1 11y ago
  usually when you do this size goes up. the number of files goes up.
MichaelGG 11y ago
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 11y ago
  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)

pacaro 11y ago

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

koevet 11y ago

> 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.

EliRivers 11y ago

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.

amelius 11y ago

hyperchase 11y ago

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".

panjaro 11y ago

Disappointed with the sound quality !!!!

matt_s 11y ago

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.