

How to be a better programmer in 6 minutes - Anon84
http://www.secretgeek.net/6min_program.asp

======
Bjoern
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
_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._

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.

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

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

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

------
Jebdm
"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
Lock the doors kids.

------
tolmasky
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
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
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?

~~~
gnaritas
I use 14, I find it quite comfortable.

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

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

~~~
nostrademons
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!

~~~
anamax
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.)

~~~
nostrademons
Two cases:

1.) The string in question has an observable effect on the application's
behavior, eg. a filename or text that appears in the UI.

2.) The string in question is used as a programmatic key; its actual value
matters to you for readability's sake, but the user doesn't know or care what
its value is.

For #1, you should be using some sort of localizable message catalog (eg.
gettext or Java property bundles) or config file and not hardcoding it as a
constant. Almost all of these use strings as the message key; in gettext's
case, they just happen to be fairly human-readable strings. Converting them to
a constant merely goes from one suboptimal solution to another.

For #2, the particular string used is part of the internal API of the program.
Coding it as a constant buys you a little in that you can get the compiler to
check it for you and make sure you didn't make any typos. The difference is
really the old static vs. dynamic language debate. In any case, changing the
string value here should be considered a program refactoring and done the same
way you would do any other refactoring.

~~~
anamax
> not hardcoding it as a constant.

The bits have to be somewhere. The question is whether they appear one place
per "meaning" or they're at every use.

Normalization is not just for databases.

> In any case, changing the string value here should be considered a program
> refactoring and done the same way you would do any other refactoring.

Which refactoring tools can distinguish "obj" (used as a prefix for object
file temp names) from "obj" (used as a prefix for orange bear jumpsuit part
numbers), let alone 0 from 0?

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

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

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

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

~~~
jrockway
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.)

~~~
gnaritas
You're kidding right? It's pretty simple to write small methods from the
start, trivial in fact. If you think small methods come from lot's of cutting
up of larger methods then you're doing it wrong. Writing well factored code
isn't some magic trick that requires doing it wrong first and then refactoring
to get it right.

Your sarcasm is misplaced and presumes bad code always comes before good code,
it doesn't.

~~~
jrockway
I'm saying that it's easy to always _try_ to do something, it's not always
easy to _succeed_ the first time.

You should always make it easy for yourself to fix mistakes, even if you
shouldn't have made them in the first place.

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

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

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

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

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

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

------
jff
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/>

------
greml1n
I am going to master the goto keyword.

