
Golden rules for becoming a better programmer - piess
http://www.codeshare.co.uk/blog/10-golden-rules-for-becoming-a-better-programmer/
======
dozzie
Ten low-level, generic advices. Too low level to do any good in larger
picture, and too generic to be applicable in real life as-is. The only
exception is not interrupting people when they are in the middle of work.

There are several high-level advices that are similarly generic: break up your
program to subsystems of clearly defined interface and purpose, make the
subsystems composable by not loading them with too many purposes, don't mix
high-level and low-level purposes or operations in the same interface, avoid
putting dependencies on other modules or services unless necessary, and know
which operation belongs to which module. _Those_ make good programmer, not
minutiae about creating identifiers.

~~~
50CNT
I like to generalize it to "Understand and consistently apply the concepts and
good practices of your chosen field".

This requires you to find out what good practices are, understanding why they
are good practices and then working on making them a habit so they reliably
show up in your work.

The issue I have with the article myself is that it over-promises in the title
and under-delivers in the body.

The rules are drawn at random from things that make good sense, with no
attention to order in level, area, or importance. DRY is a pattern, not
commenting code is an anti-pattern, and not interrupting co-workers is
workplace etiquette. Some rules are obvious to the intermediate [DRY, no magic
numbers], whilst others are confusing to the beginner [eliminating
dependencies to make code easier to test]. This makes the list useful for
neither.

Calling this "golden rules" seems dishonest. "My rules for becoming a better
programmer" would be a more accurate, albeit more boring title.

~~~
samizdatum
Yeah, this article reads like someone was forced by their employer to write a
blog post. If it was for self-promotion you'd think they'd put a bit more
effort into it. Would be better if retitled to "10 things that just so
happened to pop into my head".

------
jlg23
11\. Know when to break any of the first 10 rules.

12\. Never listen to anybody who tells you "You shouldn't need comments if
your code is clear enough to read." \- the next one reading your code
(probably you, 10 years later) will love you for documenting the WHY just as
much as s/he'll hate you for having to rely on documentation that explains the
WHAT.

~~~
MaybiusStrip
I like how Robert C. Martin puts it: before you write a comment, ask yourself
whether you can write the code in a way that makes the comment unnecessary. If
you cannot, then it is better to leave the comment than none at all.

~~~
mannykannot
Fair enough, so long as you understand that programming languages are not
expressive enough, in general, to clearly explain purpose and rationale. In
these matters, providing a hint through identifier naming is not an adequate
substitute for a clear explanation in a human language.

------
bluesnowmonkey
Some of these could serve as philosophical starting points but are a bit too
dogmatic for "rules".

1\. DRY

I like the Rule of Three better, and even that is flexible. It's important to
find an underlying abstraction and not just extract common chunks of code
because they happen to be similar.

4\. No literals

Eh, not really. Most of the time I'd rather just see the value and not have to
follow a reference to the definition of a constant.

5\. Avoid dependencies

Yeah, probably true for application level settings like he describes, but
don't go crazy with it. The goal is to have clean readable code and tests. Its
just a headache when everything is a FooImpl of a FooInterface, for instance,
and not really a win for testability.

~~~
davnicwil
> 4\. No literals

Generally I agree with you here, but I _think_ what the post is getting at is
more the one case where you do want a variable in place of a literal - when
passing the literal into a function where its purpose isn't immediately
obvious. Passing the literal behind a more meaningful variable name can
provide cleaner, self-documenting code in cases where, for example, modifying
the function isn't possible and writing an adaptor would be overkill.

~~~
akkartik
The second-most egregious pattern I see at work:

    
    
      const char* kEmpty = "";
    

Makes me want to poke my eyes out with a stick everytime I see _kEmpty_ used..

(The most egregious thing is spaces inside parens. But that's just a personal
preference. In general I tend to be quite _laissez-faire_ about tolerating
different styles, and consider style guides to be a pox because they tend to
give the subliminal message that your code is done when it complies with the
style guide.)

~~~
davnicwil
I'm 100% with you, the variable name _kEmpty_ here is completely tautological
- it just describes the literal in a different, clunkier way, and doesn't add
any information. Kind of similar to something like _nameOfSteve = "steve"_

The case where it's useful is where instead you'd call the variable referring
to a constant something like _dollarCurrencyCode = "USD"_, where you have to
use an api which takes a currency code but you will always pass "USD". To the
uninitiated reader, what purpose does the literal "USD" serve - what does it
_mean_? It's not clear, because they don't know the api, and may not intuit
currency codes. Putting it behind the _dollarCurrencyCode_ variable name makes
it a lot clearer on first glance. If they care to know what the
dollarCurrencyCode is 'under the hood', they can then look, but this is a
lower level detail of the underlying api and doesn't help with understanding.

------
Paul_S
The boy scout rule does not apply to programming. Please don't do this.

Found a bug? Fix it and add a test for it. Don't "tidy up" what you consider a
"mess".

~~~
bluejekyll
I couldn't agree more. This a sure path to disaster and unhappiness. Fixing
code requires understanding what it is doing in all except the most basic
examples.

Unless you have a firm set of tests, or strict API constraints defined, don't
ever follow this rule. It will only lead to a sad tail of how you created this
huge bug that deleted all the customers data because you though this Boolean
wasn't used anymore, so you removed it. It makes for a funny story, but a
really bad couple of weeks.

~~~
mywittyname
Worst case, as you said, but the best case is...nothing. You're literally
spending a bunch of time doing a high risk activity to produce nothing of
value. It might be easier to read, but if the original developer is long gone,
then it's likely nobody will look at it again for years (unless you broke
something and the next guy rolls back your changes in VCS).

Taking on a foolish refactoring project is a rite of passage for developers.

------
markatkinson
This is the type of article that spawns the best and most informative
comments. As a rather isolated programmer being able to browse through the HN
comment section and read everyone's different perspective of "rules for
becoming a better programmer", I find is infinitely more constructive than
reading blog posts. It also somehow feels more credible... So thanks I
suppose.

------
pfarnsworth
Disagree _strongly_ with the "boy-scout rule". If it's a bug, then fix it, but
if it's messy code, then _leave it_! There's no reason to touch something that
may be working fine and for you to create subtle bugs.

~~~
deciplex
If you have the _option_ of leaving it alone, then you probably should,
however if you've already got to work on the messy part anyway, and if the
code is messy to the point of being difficult to read, then you might be
_reducing_ the chance of introducing new bugs if the first thing you do is
refactor the lot such that you don't cringe just looking at it.

I'm talking about cleaning up _the code_ though, not the _logic_ \- refactor
really isn't even the right word. Poor choices for variable names, misleading
or just plain wrong comments, inconsistent use of whitespace, etc etc.

And even this you should only do if you really think it's necessary, since it
will make it very difficult to use diff to suss out what your _actual_ changes
to the area were after you're done. Still, there is a time and a place for it.

~~~
emilisto
If you use your VCS right the diff issue doesn't have to be a problem. Do the
tidying up in the upstream branch, or at least as a separate commit that can
precedes your actual logic changes.

------
fao_
I would add: Also research tools/concepts that you can't understand yet, and
read programming books above your level.

Because after enough time your brain will have collected enough information to
understand them ( _I call it the 'click' \-- that moment where everything
clicks and becomes clearer_), and you will become a better programmer because
of it.

~~~
LoSboccacc
Agreed. Everyone loves gof design patterns, but the real gems for
practitioners start a couple level below in abstraction: code complete
basically shortcuts you five years of experience and Fowler refactoring +
patterns of ea ground yourself in making what it's needed and not what it's
dreamed

------
j45
It's been my experience that clever architecture tends to beat clever coding
and tactics.

I don't think I started to have an idea of what being a better programmer was,
until I had a relationship with multiple code bases that I had started or
built and were 5-7 years old.

What came from it?

\- idea of being kind to your future self,

\- coding in a way that the next person could quickly pick up on it vs
building a tribute to my own cleverness

\- not prematurely optimizing

\- refactoring being expected

\- learning to solve all sorts of small and not-small problems

\- being open to the idea that few problems haven't been thought about or
solved already

------
jrapdx3
The article's advice is rather generic, though it did bring up some
interesting responses. The rule about comments in code elicited a minor
controversy, but I tend to agree with the sentiment that adding comments is
more worthwhile than not.

The program logic may be clear to the author but there's a good chance it
won't be to others using it, especially when 6 months later I'm one of those
"others". At that point it's usually easier to determine if a comment really
clarifies things and if not remove or modify it.

I'm surprised not much said here about rule 10. Giving feedback to team
members is an essential part of teamwork, e.g., certainly it can't work if
problems with code aren't expressed. However I think what the author is
getting at is the fine line between "criticism" and "critique", the latter
meaning communication re: mistakes, etc., in a constructive, generous and
objective way.

Without due care in expression, teams risk degenerating into factions arguing
over who's "right", who's to blame, and there progress grinds to a halt. It's
always obvious when other teams are in this state, but frequently we don't see
it in ourselves or happening in our own group. Mastering the art of critique,
including self-critique, is hard, but an amazingly valuable skill to learn.

------
mark-r
I have 2 rules:

1\. Practice, practice, practice. This goes for any endeavor in life, not just
programming - the more you do it, the better you get.

2\. Never settle for your first attempt, always be thinking of ways to
improve. Sometimes I'll come up with ways to redo something years after the
opportunity to do so has passed, just because it's still on my mind. Hopefully
when a similar situation presents itself the better method will be my first
choice.

------
the_cat_kittles
a golden rule for golden rules: show concrete examples if you really want to
communicate what you mean

~~~
markatkinson
Agreed, this blog post is very buzzfeedesque and must have taken an hour or
less to bang out... surprised its that high up on the feed.

------
agentgt
11\. Take occasional breaks. Yes its sometimes a good idea to get out of the
zone.

I can't tell you how many times I have written a 500 or so lines of code and
realized after taking a break I was going down the wrong path or was thinking
about the problem incorrectly.

------
LoSboccacc
Like Spencers' ten commanments except with calls to unspecified external
practices, less funny and ultimately not really actually for programmers

------
piess
You shouldn't need many comments if your code is clearly written and named.
Just a summary above each method.

~~~
bluesnowmonkey
Nope. In my career I've never seen this mythical code that doesn't need
comments. Tell me about preconditions, postconditions, performance
characteristics, quirks, absolutely anything and everything that could affect
the caller.

~~~
joshka
I've often seen assertions like this that all / most code requires comments. I
hold a personal view that it's actually the opposite, but can't seem to get
anyone above to bite and show me useful real code provides a counterpoint to
my view.

Can you point to an open source repo somewhere that demonstrates your point
that comments are preferable to writing clear code without comments?

I'm sure you can point to repos where poorly written code requires comments in
order to be properly explained. This is not really what I'm after, as I'd
contend it's likely that writing the code better would be more useful to that
project.

