Going Beyond Code to Become a Better Programmer(blog.fogcreek.com)
blog.fogcreek.com
Going Beyond Code to Become a Better Programmer
http://blog.fogcreek.com/going-beyond-code-to-become-a-better-programmer-interview-with-pete-goodliffe/
25 comments
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".
> 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"
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"
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".
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".
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)
(ok, you can use a fake smtp server, but it makes tests more complex, imo)
Why can't you mock the function? Mocks aren't specific to classes.
If you're passing an object in, you can just as easily pass in a function.
Though I was explicitly referring to the case where the code is literally rewriting static functions into objects without using any actual OO features - just adding extra noise.
Though I was explicitly referring to the case where the code is literally rewriting static functions into objects without using any actual OO features - just adding extra noise.
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.
This code does tend toward smaller more compact expression, but you're chasing the simplicity more than the literal absolute size.
usually when you do this size goes up. the number of files goes up.
> Sometimes making code more concise really makes it more obscure.
Absolutely. A clever one-liner may make sense to you _now_, but try coming back to it after a few years when you've moved on to another language/paradigm and can't remember the subtleties of what you've written. I believe "Write Less Code" should be taken to mean "Write modular, reusable code that reduces boilerplate and emphasizes the underlying business logic". Clarity should be the key driver here. Shorter code helps, but it's only a means to an end, rather than the end itself.
Absolutely. A clever one-liner may make sense to you _now_, but try coming back to it after a few years when you've moved on to another language/paradigm and can't remember the subtleties of what you've written. I believe "Write Less Code" should be taken to mean "Write modular, reusable code that reduces boilerplate and emphasizes the underlying business logic". Clarity should be the key driver here. Shorter code helps, but it's only a means to an end, rather than the end itself.
[deleted]
Sure, if you quote the heading it's easy to pick apart, but read the contents of that section. He mentions "working smarter, not harder" and "no unnecessary logic" which are both hard to disagree with. Certainly we don't want a bunch of inlined calls and hard-to-mentally-parse-operations but that's not what he's advocating. In the very next section he describes code as being a means of communicating with the computer and humans.
So what's the distinction between simply making a passable program and working smarter, without unnecessary logic? It's hard to understand or even believe unless you've seen it happen. Even if you understand and believe, the magnitude of how powerful it is can easily be underestimated.
Take prime factors for example; how would you program it? Most people would probably expect they'll need some kind of primes against which they can factor a given number. You might create the list of primes or have a data source somewhere, and iterate over it looking for prime factors. The result could easily grow into a (small, but) considerable program.
If you practice TDD and "fake it till you make it", testing the next-dumbest case you can wind your way to very elegant algorithms through refactoring against tests. That sounds easy but in reality it often feels silly to test this one other simple edge case or to test every failure case (1..2..3..) and that makes it hard feel worth doing. It's also difficult to look at known-working code and see the other possibilities for how the same result could be accomplished for all cases with a different methodology.
If you haven't yet, check out Bob Martin's primes kata: http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata (The slides have a lot to be desired but the only video I could find was on vimeo with a lengthy intro and no apparent way to fast-forward)
Chances are we'd rather maintain the simple 3-line algorithm rather than the one with the data source and unnecessary complexity. That doesn't mean shorter is always better, but in many of the problems we face everyday there are elegant solutions hiding in the details. The simpler solutions inherently have less to maintain, for better or worse.
So what's the distinction between simply making a passable program and working smarter, without unnecessary logic? It's hard to understand or even believe unless you've seen it happen. Even if you understand and believe, the magnitude of how powerful it is can easily be underestimated.
Take prime factors for example; how would you program it? Most people would probably expect they'll need some kind of primes against which they can factor a given number. You might create the list of primes or have a data source somewhere, and iterate over it looking for prime factors. The result could easily grow into a (small, but) considerable program.
If you practice TDD and "fake it till you make it", testing the next-dumbest case you can wind your way to very elegant algorithms through refactoring against tests. That sounds easy but in reality it often feels silly to test this one other simple edge case or to test every failure case (1..2..3..) and that makes it hard feel worth doing. It's also difficult to look at known-working code and see the other possibilities for how the same result could be accomplished for all cases with a different methodology.
If you haven't yet, check out Bob Martin's primes kata: http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactorsKata (The slides have a lot to be desired but the only video I could find was on vimeo with a lengthy intro and no apparent way to fast-forward)
Chances are we'd rather maintain the simple 3-line algorithm rather than the one with the data source and unnecessary complexity. That doesn't mean shorter is always better, but in many of the problems we face everyday there are elegant solutions hiding in the details. The simpler solutions inherently have less to maintain, for better or worse.
"Write less code" is kinda vague but for me it means 'do other stuff than just simple coding'.
I take pen and paper or whiteboard and spend considerable time to model the problem in pseudocode and graphs (not UML, the horror, just lines and boxes) before I start banging code.
For trivial adapter code etc. this approach is pointless but the larger and more complex the component, the more it pays off.
It can also mean to employ existing libraries where it makes sense, and to utilize code generators for tasks they are suited for (e.g. writing tests with lots of combunatorial excess or implementing interfaces on top of an FFI).
I take pen and paper or whiteboard and spend considerable time to model the problem in pseudocode and graphs (not UML, the horror, just lines and boxes) before I start banging code.
For trivial adapter code etc. this approach is pointless but the larger and more complex the component, the more it pays off.
It can also mean to employ existing libraries where it makes sense, and to utilize code generators for tasks they are suited for (e.g. writing tests with lots of combunatorial excess or implementing interfaces on top of an FFI).
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.
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.
I agree with everything he says, but not much actionable information in the interview.
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
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.
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.
Sorry, but the sound quality is really poor.
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.
> 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.
> 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.
Disappointed with the sound quality !!!!
These interviews are great.
FogBugz search algo is not :)
FogBugz search algo is not :)
FogBugz period not so much.
Still blows my mind that this is the same company that built Trello....
Still blows my mind that this is the same company that built Trello....
> 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.