8 ways to be a better programmer in 6 minutes.
Remember how Justice Gray started that little fad about becoming a better developer in 6 months?
Well, that was a while ago and most of you failed. Badly.
So here's a simpler challenge, some ways to be a better programmer in 6 minutes.
You've got 6 minutes, right?
Go for it!
- Use a bigger font size.
This is ridiculously easy -- but it works.
Go to your favourite IDE, and crank the font-size up. I switched from 10pt to 14 pt. The difference is that a lot less code fits on the screen at once.
The effect is: you're forced to write shorter methods. And that's a
(Scott Hanselman recommends that one)
- Make hard-coded strings look ugly.
I learnt this from Joe Cooney.
Go to your favourite IDE, and set it so that literal strings stand right out -- for example a yellow background with a red font. Make 'em ugly. Damn ugly. This will encourage you to perform less hard coding, and to notice when you are embedding strings in your text.
- Pick an 'obscure' keyword and master it
Do you fail to
yield?. Is there a keyword you never use?
Every keyword has a purpose. Learn to master those mystery keywords and your powers will become extraordinary.
Here are lists for a few .net languages: C#, VB.net, F#.
- Increase code-coverage by 1%
Don't kill yourself striving for 100% coverage of code with automated unit tests. But take a few minutes to increase your coverage by 1%.
Most likely, that means going from 0% to 1%. And that's the biggest improvement of all.
Find a particularly ghoulish regular expression. Or a critical piece of business logic. These things can't be trusted without tests.
- Read the code from an open source project
Sometimes, when I'm looking at the code of a complete stranger, I get that same, weird feeling I get when I'm creeping through my neighbour's house. Picking up their stuff, looking through their fridge.
Learn to overcome the creepy sensation, and bring on the learn.
Maybe start with Hanselman's Weekly Source Code series.
- Run a static analysis tool against your code
Use fxcop, or StyleCop, clone detective, ndepend, the code metrics feature of VS 2008, or any other static analysis tool of your choice.
Uncover your greatest weakness. Even a cursory glance at the output will leave you distraught at just how much room you've got for improvement.
- Pick an ugly method to refactor
You know the method. That method you're particularly ashamed of. That one that's long and ugly and horrible. And it's crucial to the whole application.
You don't have to polish it from a turd to a diamond, but just neaten it up a little. Rename a variable. Hoist part of it out into a separate method. Start simple. The momentum will increase. Watch out.
- Stop reading, start writing.
And don't just write. Write a compiler!
This ol' msdn article is a good place to start. Joel Pobar will get you writing your own language compiler in but a handful of minutes.
That's all I've come up with for now. But what've you got?
What are some 6 minute activities that helped you be a better programmer?
This article has been kindly translated to Serbo-Croatian language by 'Web Geeks'
'hacka' on Sun, 08 Feb 2009 10:12:44 GMT, sez:
stop using .net
'lb' on Sun, 08 Feb 2009 10:14:27 GMT, sez:
i'd be happier with 'don't exclusively use .net'
'Don2' on Sun, 08 Feb 2009 10:26:20 GMT, sez:
The bigger font-size idea is excellent. Done.
Now I am better, and I can get on with my life.
'just honest' on Sun, 08 Feb 2009 10:35:21 GMT, sez:
Maybe if I turned up to work sober once in a while.
'nagoff' on Sun, 08 Feb 2009 12:04:28 GMT, sez:
How about 'remove some (all?) warnings'? - unless you're already a good little boy who keeps his compile warning free. In that case, how about switching doxygen or what-have-you to its whiniest setting and fix a few of those warnings?
'Michael' on Sun, 08 Feb 2009 14:40:49 GMT, sez:
Learn a design pattern and try it out the next time an appropriate opportunity arises.
'Stephan Schmidt' on Sun, 08 Feb 2009 17:24:02 GMT, sez:
Nice, made me think. New them all but nice collecting them together in this way.
Programming is hard - http://blog.codemonkeyism.com
'nagoff' on Sun, 08 Feb 2009 17:59:07 GMT, sez:
I missed an obvious one that only occurred to me later - chat to a customer.
'jm' on Sun, 08 Feb 2009 18:00:49 GMT, sez:
Read an open source project in six minutes? What are you supposed to get out of it in that short of a time? When reading someone else's code, for any reasonably large project anyway, it's going to take me longer than that to even get the lay of the land straight.
'dccrowley' on Sun, 08 Feb 2009 19:07:17 GMT, sez:
stop creeping through your neighbours stuff :p
'David H' on Sun, 08 Feb 2009 19:41:03 GMT, sez:
nice one. you truly are a 'man of the people' ;) maybe i could make my font size really really small, that way i'd want to write less code because reading it would give me headaches like crazy.
'Ted' on Sun, 08 Feb 2009 21:10:13 GMT, sez:
I don't mean to be rude at all, but what "hacka" says it's true.
1. Stop using .NET
2. Learn UNIX tools and its philosophy
3. Learn languages from different paradigms (so you don't jump the wagon too fast after reading too much of Uncle Bob, Joel or Jeff).
I don't know how one can be a better/productive programmer in .NET environment. Especially when MS keeps shoving newer libraries and or tools to a developer's mouth every year.
'joel' on Sun, 08 Feb 2009 21:19:03 GMT, sez:
I fail to see how not using .net will make you a better programmer. You can write good and bad programs in .net, just like any other framework. Learning different syntax for the same keyword does not make one a better programmer.
'OJ' on Sun, 08 Feb 2009 21:47:48 GMT, sez:
I agree with Joel. The chosen framework and language are just the tools. You can write shit code using ANYTHING.
Take Picasso's paintbrush and canvas and I'll bet you can't produce an image any better than a 4 year old.
Don't blame the tools, blame your lack of understanding thereof along with your ability to utilise them.
Ted and hacka, you're missing the point completely. Look past your (most likely unfounded) issues with .NET and see if you can understand the meaning of the post.
'hakr2' on Sun, 08 Feb 2009 22:37:35 GMT, sez:
I'm going to take a wild guess here and say that you live with your mom and program in PHP which you really think it's "da shit".
'Barius' on Sun, 08 Feb 2009 22:50:42 GMT, sez:
Just another wild guess, but you're a 45 yo bald programmer who's still writing Excel macros for 20 yo accountants making twice as much as you. Am I right, I'm right, right?
I'm with you, the right tool for the right job. If you're going to program for the Windows platform, you can't beat .NET, though Java has it's benefits.
If any programmer learns to be better from reading this, they must have been pretty lousy in the first place. Seriously, adjust the font size to make it harder to write long methods?? If someone is that dumb they need to find a new line of work.
'Steve' on Sun, 08 Feb 2009 23:10:16 GMT, sez:
Not using .net shows that you are a truly unique individual who doesn't adhere to groupthink or go along with whatever is the meme of the day.
Don't blindly follow what Uncle Bob, Joel, or Jeff happen to be spouting off about; think for yourself! Well, unless you start thinking about using .net, of course.
'Joel' on Sun, 08 Feb 2009 23:55:29 GMT, sez:
I wasn't going to bother to respond again to this but I think I will. You guys are way off if you think being a good programmer is language specific. Being a good programmer is
a) knowing design patterns
b) knowing architecture
c) having been a bad programmer (everyone was at some point and if you think that you weren't, then you just either haven't been programming long enough to know any better or you can't be bothered to continue to read and learn new things). Even if you are a good programmer, you should realize that whatever you did probably could have been done better but you have to limit yourself based on time constraints
d) being aware of technologies, tools (ie code coverage & static analysis, etc mentioned in this article), and resources to get new ideas from
e) knowing how to test and unit test
f) domain analysis
--the list goes on but I can tell that whether you program in java, c#, c++ will be at the very bottom. Seriously, I'm not trying to offend anyone and you can say I've full of it if you want...but if you think language is even remotely important to mention, you are probably young and new to the field. Don't take offense. It is good because it shows that you are keen and have probably read about advantages and disadvantages of different languages but try to think about what really matters and what does not. Gotta learn a lot of stuff outside of school to stay on top in this field
'Nidonocu' on Mon, 09 Feb 2009 02:03:31 GMT, sez:
Wow, look at how a few fun and interesting tips that can apply to any programmer on any platform went and got derailed by a technology religion discussion started by a troll. Seriously, all of you grow up.
Some fun things in here I'm already trying out! Building a toy compiler looks like fun. :)
'lb' on Mon, 09 Feb 2009 03:58:13 GMT, sez:
"remove some (all?) warnings"
"Learn a design pattern and try it out the next time an appropriate opportunity arises"
"Learn languages from different paradigms"
be aware "that whatever you did probably could have been done better "
'SJS' on Mon, 09 Feb 2009 08:12:35 GMT, sez:
Changing the font size probably has more to do with making the code readable than it does with short methods. If you can't read random, unseen-before-code, aloud easily (i.e., without peering at the screen), your problem might be that you're making changes without looking at the code.
Some of the workarounds to avoid hard-coded strings are worse than the hard-coded strings. You want to look AT the hard-coded strings, because the worst sort are those strings that refer to resources outside of your program. There's no option for "find strings that look like filesystem paths and color them this way", so you end up trying to un-hard-code ALL constant strings.
Many of the comments mention design patterns, but seem to get the intent wrong. Knowing design patterns doesn't help you write better code -- in fact, I argue that for a lot of programmers, it results in worse code. Instead of sketching out a solution, saying "oh, that's basically design pattern X, which has these tradeoffs", they start with "I wonder which design patterns I can apply here?"
The most important thing about a design pattern is the name -- a label you can use when discussing code with other programmers. The second most important thing is the list of tradeoffs/downsides. Every design pattern has a cost -- in complexity, in performance, in memory footprint, etc. -- that should be taken into consideration.
Better to learn about anti-patterns. Learn to recognize when code sucks, how it sucks, and why it sucks.
Use a good version-control system. Practice with a second one, to avoid that this-is-the-only-way thinking.
Use a profiler on your code, even if you're not worried about performance. If you're surprised about where your code is spending its time, you might be surprised where the bugs will be coming from as well.
Finally, work with someone else, preferably someone smarter than you. Being stuck in your own little world breeds delusions and blind spots. Talking to other people keeps you grounded.
'directhex' on Mon, 09 Feb 2009 08:16:54 GMT, sez:
'snagy' on Mon, 09 Feb 2009 09:37:39 GMT, sez:
Increasing your font is ok, but you have to do this with all your dev tools. Better to refactor. Its easier to just lower your resolution, and everything will appear bigger! No need to fine tune every piece of software. Alternatively you could also buy a smaller monitor and keep the resolution the same (if it supports it).
So obviously the best solution is to write your code on your phone. You also have less keys to choose so you may need to use VB instead of C#.
'Greg' on Mon, 09 Feb 2009 10:17:39 GMT, sez:
Good tips, thanks.
'Aycan Gulez' on Mon, 09 Feb 2009 11:58:37 GMT, sez:
Two tips that don't require any change in your code NOW, but will subtly force you to change your coding habits for the better LATER.
1. Don't use a debugger.
2. Use a profiler.
'cammerman' on Mon, 09 Feb 2009 12:08:14 GMT, sez:
FYI: Code Metrics is NOT included in VS 2008 Professional. It's only available in Team System and Team Suite. So, if you only have Pro, you are out of luck, since FxCop as a separate add-in doesn't seem to be under active development anymore.
'Gary' on Mon, 09 Feb 2009 13:12:20 GMT, sez:
Thinking that a great programmer writes code that an average or below-average programmer can understand. Developing code is not a IQ test for the reader.
'Nick' on Mon, 09 Feb 2009 14:24:06 GMT, sez:
One thing that can make you dramatically more productive is to try REBOL:
'Joshep' on Mon, 09 Feb 2009 14:57:31 GMT, sez:
What about "Stop being Microsoft's bitch"?
'Joel' on Mon, 09 Feb 2009 15:08:38 GMT, sez:
Good one Gary. That is a subtle but important tip.
'JB' on Mon, 09 Feb 2009 15:30:18 GMT, sez:
Bullshit. It takes years to become a good programmer.
'bob' on Mon, 09 Feb 2009 15:34:16 GMT, sez:
Write a compiler in six minutes? What on god's earth are you talking about? Writing a compiler is a great way of potentially increasing one's programming skills but six minutes? As someone on reddit put it "get off the internet".
'elves' on Mon, 09 Feb 2009 15:40:14 GMT, sez:
A great discussion. I agree with so much of this.
I'll make a couple of points (before I'm flamed I'm 59 and wrote my first program when I was 18). Language does matter because some are tied to domains. So .NET may be forced on you, even though you'd rather write in Erlang (YAWS).
Keep writing code. I've seen so many career 'progressions' in my career that have led people away from coding. Just don't go there. So what if you're a bald 45 year old excel macro writer. Go with the flow and keep learning new languages. Eventually things turn around and you'll be in demand again.
'Terry' on Mon, 09 Feb 2009 17:04:13 GMT, sez:
It's funny how folks like Hacka and Ted believe that programming is all about the programming language when in fact its not, its all about how you design software and if you are aware of best practices.
Just because you code in a 1975 text user interface environment doesn't mean that your software is worth a damn.
'WulfVette' on Mon, 09 Feb 2009 18:04:55 GMT, sez:
WOW thats how a FREAK does it.
'OJ' on Mon, 09 Feb 2009 22:00:01 GMT, sez:
Hrm, number of comments has increased, quality of comments (and hence indicactive level of intelligence) has decreased...
.. someone's linked this article on Reddit ;)
'lb' on Mon, 09 Feb 2009 23:40:21 GMT, sez:
@OJ, right you are,
some rather cruel commentary at reddit
and more at hacker news:
The lesson for me is that the title was absolute dynamite as link bait -- but far too bombastic for the article itself.
This is a jeff atwood trick of course ;-)
Still, I'm glad I didn't go with a more accurate title, because it would've taken more than 6 minutes just to read the title:
"7 ways to possibly improve your .net programming technique, albeit only slightly - plus a link to an article about writing compilers"
Also -- I find it difficult to indicate what is and isn't sarcasm, in such a way that it's not disruptive to the regular readers, but still clear to first time visitors.
Putting smileys everywhere would just look dumb. Putting <sarcasm> tags around parts is horrid. A big 'Warning: sarcasm ahead' banner would destroy the point.
Luckily, I have a specially prepared page that I show whenever too many new people visit at once: it just says "Website too busy." ;-)
'yogee' on Tue, 10 Feb 2009 02:11:18 GMT, sez:
I write killer code. Literally, people have shot them reading my code. Isn't that cooler than being good programmer?
'Daniel' on Tue, 10 Feb 2009 12:22:17 GMT, sez:
'.net4ever' on Tue, 10 Feb 2009 13:33:52 GMT, sez:
write code that works
'mike' on Tue, 10 Feb 2009 13:43:51 GMT, sez:
Does "get a clue" fit in here anywhere? How about "learn to read well enough that you understand parody"? Anyone who posted a comment debating the font size suggestion is assigned one month's worth of reading The Onion. Come back when you can get the difference between them and your local news source. (And the difference is not that they use a different font than the newspapers.)
'Ryan' on Tue, 10 Feb 2009 18:27:16 GMT, sez:
Here's a totally obvious one...use your own app!
I'm a QA guy and it seems blatantly obvious to me that if a programmer used his own app they would experience all the errors and anguish a customer would experience. In most cases, it wouldn't be enough to get a developer to fix it. They would just turn their head and look the other way. But a GOOD developer would then improve his app.
'Kurt' on Tue, 10 Feb 2009 20:14:10 GMT, sez:
This guy has some interesting suggestions as well:
How to be a better developer?
'hDog' on Tue, 10 Feb 2009 20:29:31 GMT, sez:
Hey - i've previously seen that suggestion about making strings stand out:
Make strings stand out
Most typographic errors in the code are caught by the compiler. Embedded strings, unlike code, are not parsed but you can be sure your endusers will notice your typos! Highlighting the strings as shown is guaranteed to help you pick up your mistakes sooner!
-> -> Fonts and colours
-> -> -> Display items
-> -> -> -> String
-> -> -> -> -> Foreground: White
-> -> -> -> -> Background: Purple
Guess where that is from??
SecretGeek, circa 2003!
'Raj Chaudhuri' on Thu, 12 Feb 2009 15:39:55 GMT, sez:
Watch people use your app. Listen when they bitch about it. And then make it better.
Keep doing this.
Languages, paradigms, operating systems, toolsets, design patterns, antipatterns, UNIX, Windows, Java, .NET...they're all unimportant in comparison.
'Robz' on Fri, 13 Feb 2009 01:35:06 GMT, sez:
Sleeping once in awhile is a good idea. ;D
Learn a new Resharper skill. Read a blog post @ secretgeek.net. Think about the bigger picture. Take a look at some of the newer ways people are testing code. Try to take a good method and do it a different way.
'd00d' on Fri, 13 Feb 2009 09:04:25 GMT, sez:
you could also buy a bigger monitor and increase your resolution. that way all your routines will look smaller, no need to recode anything
'ant' on Sun, 15 Feb 2009 23:19:28 GMT, sez:
You don't _need_ to increase the font size, just teach the editor to highlight lines over (80|100|$whatever) chars long. 16pt Droid Sans Mono is wayyyyy nicer to look at for hours a day, though.
(oh and hey guys, before you bash someone's choice of programming language, let's see some evidence that you can do better with yours.)
'Shiva' on Sat, 28 Feb 2009 22:06:05 GMT, sez:
I LOVE #2. "Make Hardcoded strings look Ugly".
It is one of my Pet Peeves. I "snap" when I see a hardcoded value that could've (and should've) been avoided...
'George' on Tue, 07 Apr 2009 11:38:03 GMT, sez:
Wait, you creep into your neightbour's house?!
'Ashish Sheth' on Tue, 05 May 2009 10:56:24 GMT, sez:
nice article. Keep it up.
'Giorgio Sironi' on Wed, 06 May 2009 14:40:31 GMT, sez:
The concept of changing font size, color and so on to stimulate a good practice is similar to something I blogged two days ago:
'James E. Ervin' on Fri, 15 May 2009 17:32:40 GMT, sez:
I don't come from the .net world, but the Java world and I think that there is another 6 (or so) minute task that would help you and it also comes from your ide. Develop a useful set of enabled warnings! Warnings are static analysis tools built in and free.
Pare down the list to eliminate those warnings you are never ever going to touch, turn on all the rest, and goto town. Eliminate the warnings and watch your code improve!
'wtetzner' on Mon, 29 Jun 2009 20:02:14 GMT, sez:
@Joel "if you think language is even remotely important to mention, you are probably young and new to the field"
Languages really do matter, because languages are how we describe programs, and how you describe your programs is what determines how good of a programmer you are.
Now, I agree that, for the most part, whether you use Java, C#, or C++ isn't the most important thing. However, if you use, say, Haskell or OCaml, or maybe Common Lisp or Clojure, the way in which you express your programs is different, and hence the tests you use to determine the "goodness" of a programmer are different.
Sure, readability is important to all programs, but if you try to get more specific than that, you have to look at the abilities of the language used.
For example, someone mentioned learning a design pattern and using in the next applicable situation. This isn't bad advice, but in many higher-level languages, using Java design patterns would be pointless, as the language has features that allow these patterns to be abstracted away.
So languages do matter. In a situation where the programmer has a choice of which langauge to use, the langauge the programmer chose is an indicator of the programmer's abilities.
Of course, not everyone has a choice of which language to use on certain projects, but knowing languages besides that specific language makes you a better programmer, and even if you can't use better programming languages, you will have a better understanding of not only the abilities of the language you have to use, but of its limitations as well.
Comments disabled due to one particularly annoying spam guy.