How to be a better programmer in 6 minutes

http://www.secretgeek.net/6min_program.asp

by Anon84 • 17 years ago

122 44 17 years ago

bprater• 17 years ago

All very good tips. I prefer a smaller font when hacking because I like to be able to scan more of the codebase, but I can see how it could force a person to tighten up the scope of their methods/functions.

olavk• 17 years ago

One good font-related tip: Make comments stand out (dark, bold) rather than fade into the background. Forces me to write better comments, and prevents comment from getting out of sync with the code.

jaxn• 17 years ago

The article inspired me to start tweaking my TextMate settings. I found that making hard coded strings stand out is not helpful to me (I write a fair number of queries).

But I got to tweaking and realized that making comments stand out is amazingly helpful. I completely agree that it makes me want to write more comments and makes commented out code a glaring problem.

LogicHoleFlaw• 17 years ago

An alternative to using a larger font is to use a smaller screen. I've been having a blast writing little stuff on my netbook in bed.

ktharavaad• 17 years ago

One thing that really helped me when I code is to switch to a real "coding font".

Wile the default monospace font on OSX (monaco) is fine, I find that my eyes adjusts better to the "proggy clean" fonts (avaiable for free here: http://www.proggyfonts.com/ ).

With good coding fonts, you are able fit more into the screen, distinguish between 1 and l, 0 and o more easily..etc. Here's a discussion on programming fonts a while back on HN (http://news.ycombinator.com/item?id=255257)

scott_s2• 17 years ago

I thought Monaco was atrocious until I anti-aliased it. It's like an entirely different font - one that I prefer over all others now.

GHFigs• 17 years ago

In a sense, it is an entirely different font, as Monaco includes both the original bitmap style for and the later outline style. When you turn on anti-aliasing, it overrides the use of the bitmap style when it would otherwise be used.

To see just how different they are, open up a window where you can toggle AA on and off (e.g. a Terminal window), and compare Monaco at 9pt-12pt each way.

fp• 17 years ago

Who can do numbers 3, 5 and 8 in six minutes? I guess they will make you a Better Programmer (tm), but will consume slightly more time. Or does the article claim to make me a Better Programmer by just letting me know how to become a Better Programmer?

On the positive side: I like the idea of automatic uglification of "bad" code.

Jebdm• 17 years ago

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

Um...

RossM• 17 years ago

Lock the doors kids.

scott_s2• 17 years ago

I'm writing a translator that generates C code. I'll pass on the "make hard-coded strings look ugly" part.

Niten• 17 years ago

I'm supposed to master an obscure language element, read through the source code of an open source project, refactor a method, run a static analysis tool, and do all the rest--all within six minutes?

I do like the idea for making hard-coded strings stand out, however.

nikron2• 17 years ago

Maybe he meant incrementally increase your coding abilities, you know, master a new keyword in 6 minutes, read the source code of an open source project in 6 minutes, run a static analysis tool in 6 minutes, ..., and write a compiler in 6 minutes.

nostrademons3• 17 years ago

I sense a new online tutorial coming on..."Six minute compilers."

leohorie• 17 years ago

I think the six minutes refer only to the amount of time it takes to read the article.

If anything, it did remind me to refactor some longish functions I had in a class I was working on.

tolmasky• 17 years ago

Bigger text size is also good for not going blind. I've been coding with bigger text for a few months now, fewer headaches too.

ewiethoff• 17 years ago

A bigger font is better for your upper back, too. Take a look around you and notice how many of your fellow developers--or anyone working with text at a computer--slouch forward every few seconds to peer at the monitor. Then notice yourself doing it. Bye, bye, chiropractor.

jamongkad• 17 years ago

But how big is too big? I originally coded in Monospace 10. I tried to go 14 but I just found it unpleasantly big. What fonts can you recommend?

paddy_m• 17 years ago

or get a monitor arm and lean back. I got one of these http://www.lcdarms.com/products/LCD_Radial_Arms/iLift.html . It has been really nice. I almost have my monitor positioned about like the light at a dentist's office.

joshuaxls• 17 years ago

I agree. For years I coded in tiny, non-anti-aliased fonts. Recently I switched to an anti-aliased font at a larger size and the difference is definitely real and positive. Less headaches, easier readability, more distance between my eyes and the screen. Also, make your fonts brighter but maintain a medium level of contrast with the background.

I heavily disagree though that larger fonts cause you to write shorter methods. That's kind of ridiculous.

rrival• 17 years ago

Hadn't even thought to do this and loving it so far today.

notaddicted• 17 years ago

Use a bigger font size.

I am a violator here. I have emacs set to 6x10 on a 25" monitor, the result is 104 lines on a screen. And I like it.

nikron2• 17 years ago

Yeah, I fail at this too, but I use my console for coding. So, increasing the font size of my console hurts me when I'm using the shell, so I don't feel like increasing the font size. It also limits the amount of code you can see; really you should just cap your functions at some arbitrary length 25-50.

nwinter• 17 years ago

I use the default font size, but rotated my screen, so I get 111 lines. I would hate to go back.

zenocon• 17 years ago

It seems a bit odd to me that one would need to reduce the screen real estate in order to force one to write smaller, more succinct functions/methods. I think you either do this because of the right reasons, or you don't do it -- and trying to trick yourself into it just seems goofy.

jrockway3• 17 years ago

The next step is to cut off your hands. That way you won't do any unnecessary typing.

paul2• 17 years ago

Why would I not "hard code" strings? These suggestions don't seem that great to me.

How about learning to type with your feet, or only using the mouse, or maybe code blindfolded? (or all three!)

Somehow, people seem to have gotten the notion that doing things the hard way is somehow better or morally superior or something. It's not.

nostrademons3• 17 years ago

It's often good to try things the hard way and then go back to doing it the easy way once you've mastered that. The easy way seems so much easier once you've done otherwise.

The "ugly strings" suggestion is bizarre, though. If he means "avoid hardcoded strings so you can localize your program", then you still need keys into your message catalog, which are usually...strings! And if he means "define constants for strings", you still need to define their values, which are also...strings!

paul2• 17 years ago

Putting strings in a separate "message" file is a really annoying way to localize code. It's both hard to read, and hard to write. See GNU gettext for a more reasonable approach: http://en.wikipedia.org/wiki/Gettext

I agree that doing things the hard way can be an interesting exercise though, which is why coding blindfolded is just as good of a suggestion as these others.

anamax2• 17 years ago

The reason for "ugly strings" is that the value for named constants can be changed at a single location.

If a given constant appears in multiple locations, you're likely to screw up when you need to change its value. (Nope - global search and replace doesn't help - it will change semantically unrelated constants that happen to have the exact same value. Consider 0.)

Bjoern• 17 years ago

Why a article with such a provocative headline (and so little content) makes the top here at HN is a riddle for me. Might have something to do with the fact that the HN Rules have been floating around too, namely alot of new people around. (Sorry for digressing.)

Coming back to the article I want to mention some points. (Maybe some things are biased..)

Ref. 1.) While a bigger font size is good for your eyes (hope you guys don't stare to long in one session on the screen) it is bad to understand the bigger picture in my opinion. Sure you are "forced" to write good code, but that is a standard mantra which you should follow anyway. People who like TDD (BDD) aso. have embraced this deeply. Doesn't that huge font size rather reduce your productivity? Please consider this: http://www.codinghorror.com/blog/archives/000012.html

"Its better to have more screen space, not less."

Ref. 2.) Making a syntax element like hard coded strings so much stand out is contra productive in my opinion. It would be much smarter to focus on emphasizing the important aspects of your code rather than over-highlighting strings. No? I mean sure, everybody has a different taste and style, but where is the harm in hard coding certain strings? Firstly its fast, secondly this is a typical flame of how far can we eliminate certain things from our code? (instead of embedding SQL use ActiveRecord, etc.) If you want to go so far great, start by embracing e.g. gettext, and put everything is a DB. Oh wait, why is my code so slow?

Ref. 3.) I fully agree, though why does this whole article sound like a sales story for .net ? "Here are lists for a few .net languages: C#, VB.net, F#."

Ref. 4.) Basically I agree but "Ghoulish regular expressions"? If you define it by "ghoulish", how about rewriting it to make it more clear anyway? Increase tests by 1%? Uh, well I think with proper input verification you can eliminate alot of problems. I mean its great to work with unittests but a good advice would probably have been, hey please work with unittests its has shown to make code better but if you are too lazy at least use assertions?

Ref. 5.) Interesting advice, good idea though but if you look at code from "an open source project" than it might make you scream and run away. I think this advice is maybe better: http://norvig.com/21-days.html This is btw. the perfect article to outline why this whole "How to manage x in y <time unit>." is stupid.

Ref. 6.) Good advice. ".. distraught at just how much room you've got for improvement." Hm, depends on what my goal is.

Ref. 7.) Interesting advice, though wouldn't a "cruicial to your application method" be rather well programmed? Often it is probably better to refactor the whole function because if its so long that you have problems just writing it from scratch again, then there is too much code in it in the first place.

Ref. 8.) "And don't just write. Write a compiler!" WTH. Please Mr. Justice Gray, could I remind you that the article title is "8 ways to be a better programmer in 6 minutes." ? I mean the whole idea of this article is rubbish, (see peter norvig link) but compiler, 6 minutes, what?

While I generally agree than understanding "a" compiler and what it does. (Scanning, lexing, parsing etc.) Then also implementing one, is very good for your education but it should rather be in your next article of "how to be a better .net programmer in x years."

General comment:

I really like HN, the quality coming from reddit is great, but posts like this are a waste of time. (At least in my opinion.)

Anon84• 17 years ago

Well... nature works by killing what's bad (extinction) and not simply duplicating what's good (say, cloning). Removing errors improves the final product, copying what seems to be better at a given point in time limits the possibilities and eventually leads to disaster.

zmimon• 17 years ago

> Use a bigger font size.

>...

>The effect is: you're forced to write shorter methods. And that's a Good Thing.

I find the opposite is true - I need to see more lines to appreciate exactly how goddamn awful that 200 line function is. And when I go to refactor it I need to be able to see as much as possible of it on the screen to start extracting bits out and make it shorter without losing context.

gnaritas3• 17 years ago

He was talking about writing short methods to begin with, not fixing the already borked ones.

jrockway3• 17 years ago

Yeah, great advice. Programmers should also stop writing bugs, too. How hard is it to GET IT RIGHT THE FIRST TIME?! All this bug hunting (and fixing) is a time waster.

(Sarcasm alert.)

ojbyrne• 17 years ago

It'll take me more than 6 minutes just to switch to an IDE.

greml1n• 17 years ago

I am going to master the goto keyword.

jff• 17 years ago

8. Stop reading, start writing.

No. How about "8. Stop writing, start thinking." Plan a little bit before you start smashing out code.

Also, regarding number 5, go read the Plan 9 source for insight into clean style and tight code: http://csplan9.rit.edu/magic/webls?dir=/sys/

How to be a better programmer in 6 minutes

Related Stories