How to make programming hard for yourself
Reg Braithwaite post about How to make programming hard for yourself. He makes several interesting comments that ring true with me. I've worked with several people who meet the "people that consider my hard problems to be recreational diversions" comment, and though they are phenomenally smart and can indeed tackle the hardest of the hard problems, (I feel that) they find it hard to produce code that is of a high quality consistently. Then, there are those people, who are naturally smart enough to tackle the hard problems yet are also able to produce good quality code on a day-to-day basis. There would only be about 5-10% of developers who fall into this bucket, and getting the chance to work with them is mind blowing. There is nothing better for your career development than to be thrown in the deep end with a bunch of people that know more about everything than you do. Indeed Dave Hoover's Be The Worst apprenticeship pattern embodies this idea. I'm currently working on a project with several people that fall into this category. There's nothing like a dose of reality to keep an ego in check!
On a similar note, Damien Katz shows us the Signs You're a Crappy Programmer (and don't know it). I don't agree with all of these, the 20 lines of code one especially. We spoke about this at work today, and while they're all "magic" numbers, they really force you to think hard about your design. I heard a podcast by David Heinemeier Hansson once that talked about how being under constraints you may not like forces you to be creative (he was referring to Rails). I think length is one of those occasions.
posted by Tom Adams @ 1:56 pm
2 comments
2 Comments:
I do agree with the "methods over 20 lines" comment.
I find that developers (such as yourself) who insist in breaking everything into 5 line methods write some of the most unreadable code.
How far down the stack do I need to travel to see what you're trying to accomplish? How mind-bending can it get?
I think 5 lines is a bit over the top (too small). There are some things that need more than that. The point is not the number, pick any number (hence my magic number comment), but the things working within that guideline bring out. There's nothing wrong with a method being longer, so long as the code is clear and expresses its intent clearly. If something is not readable, it needs to be cleaned up.
When I was first exposed to smaller methods I found them quite difficult to understand, however I now find them much easier to read than large methods. There's certainly a point where the a greater number of small things is not better than a lesser number of large things. It's finding the balance that counts, and this is usually a team thing.
Post a Comment
<< Home