
Coding Skill and the Decline of Stagnation - ekosz
http://notch.tumblr.com/post/15782716917/coding-skill-and-the-decline-of-stagnation
======
noonespecial
There are two truths I try to keep in mind whenever I start feeling either
extreme:

1\. There are people who are so much better at programming than me, that I
could work my entire life and never be as good as they are right now.

2\. There are people who are so much worse at programming than me, that they
could work their entire lives and never be as good as I am right now.

Its a continuum, a hill. Feel the gradient, walk uphill.

~~~
stephth
I empathize with not wanting to become cocky, but I feel like you're lying to
yourself. I could see them as truths if we were talking about triathlon, but
something intellectual and logical as programming? If you are able to reach
the point where you find yourself enjoying programming, then I think there's
good chances that it's only a matter of time - and rightly focused effort -
until you are able to produce work of any level of quality, including the
current level of the best programmer, and beyond. What sort of limitations
make you think otherwise?

~~~
eliben
Project this onto math, and we all could be Ramanujan or Galois with the right
investment of time, right? Of course not. People differ in level of
intelligence, and this is a fact. Some programmers are just brilliant people -
had they chosen math they would probably be professors churning out papers.
Some others just don't have the mental skills required.

This isn't about race or gender or whatever - just innate difference between
individuals.

~~~
ceol
_> People differ in level of intelligence, and this is a fact._

Define intelligence.

~~~
easp
Which seems to underscore his point.

~~~
ceol
"Intelligence" isn't some stat you train to make your spells do more damage.
It's a complex mix of what you've learned, how you learn, and who's teaching
you. "Intelligence" is just as hard to define as "consciousness".

------
jiggy2011
Does anybody know if Notch is self taught? I thought he had a CS Degree from
somewhere?

I can fluctuate between thinking I am a fairly competent developer to thinking
that I am possibly the worst programmer there is. I'm not sure which is a
better attitude to have, hopefully I am somewhere in the middle.

I think the issue with reading some of the discussion on HN is that you get
people talking in detail about things like functional programming languages ,
systems with huge scalability , hardcore math problems and the finer points of
memory management in the Linux kernel that you feel it is obvious that you
should understand this stuff.

I have been trying to do some more book reading to improve, of course the
issue is that whenever you read any book recommendation threads of HN there is
always at least 30 or so recommendations of some pretty thick books and no
chance I'd have time to read them all.

There is also a difference between having deep knowledge of the tools and
libraries that you are using right now and having a deeper understanding of
theory for example learning git vs learning graph theory etc.

~~~
Dove
_Does anybody know if Notch is self taught? I thought he had a CS Degree from
somewhere?_

I can't say with any degree of authority, but based on what I've read of his
code, I'd guess he's self-taught.

My bigoted preconception is that when it comes to abstraction in code, people
with CS degrees err on the side of doing too much, creating extremely
elaborate object frameworks that close down options as much as they help reuse
code. Self-taught folks, on the other hand, err on the side of doing too
little, relying on cut and paste, util packages, and promiscuous sharing of
data.

When it comes to algorithm design, people with CS degrees tend to pull in
libraries of esoteric things, sometimes overengineered for the purpose at
hand. Self-taught folks tend to write something from scratch that almost, but
not quite, does the job right.

Based on what I've read from decompiled Minecraft, I'd guess Notch is self-
taught. The abstraction is just _barely_ enough to get the job done, and the
algorithms are decidedly homebrew. That's neither praise nor criticism, just a
comment on style.

~~~
humbledrone
> My bigoted preconception [...]

Well, I would have called you on this, but I guess I don't have to.

> The abstraction is just barely enough to get the job done [...]

Or, in other words, the perfect amount...

~~~
Dove
_Or, in other words, the perfect amount..._

Philosophically, I agree. I view premature abstraction in the same light as
premature optimization. I believe both abstraction and optimization are
incarnations of your understanding of the problem. You want them in important
places, not necessarily everywhere, and hence you want them late enough in the
engineering process that you understand which places are important.

That said, within the comfort zone, there are high and low levels of
abstraction. For example, in a project the size of Minecraft, I would expect
CS major code to contain an ObjectFactoryFacadeCollection or two. Minecraft
has nothing of the sort. It sticks almost exclusively to the
Mob::HostileMob::Zombie inheritance we all grew up with. This is not bad or
good[1], it's simply a reflection of the low-abstraction style of attacking
problems that I associate with self-taught programmers.

On the other hand, its Magic Number to Constant ratio is downright scandalous
. . . ;) Though it's possible that some of that is an artifact of the
compilation/decompilation process.

[1] I'm lying, in this case it's a good thing.

~~~
jiggy2011
_Philosophically, I agree. I view premature abstraction in the same light as
premature optimization._

It's usually easier to optimize later since optimisations are often just
taking sections of code independantly and making them quicker. There is the
whole 90/10 rule (or whatever it's called) that says it's better to highly
optimise a few sections of bottleneck code rather than the whole thing.

Trying to retrofit an abstraction to a piece of code is almost always a
horrible experience frought with mess and compromise.

~~~
Dove
_Trying to retrofit an abstraction to a piece of code is almost always a
horrible experience frought with mess and compromise._

Yes, and unless the problem is trivial or your experience in the domain is
such that your foresight borders on the clairvoyant, this is guaranteed to
happen. No matter how much (or little) design you do up front.

The key is to recognize the right time to stop and refactor, so as to keep the
pain that comes with learning the problem space to a minimum.

------
pigs
"I still stubbornly believe the whole “private members accessed via accessors”
thing in java is bullcrap for internal projects. It adds piles of useless
boilerplate code for absolutely no gain when you can just right click a field
and chose “add setter/getter” if you NEED an accessor in the future."

Is this a controversial stance? It seems like common sense, unless I'm
misunderstanding something.

EDIT: To clarify: I assume he's saying "don't add accessors by default for all
private members unless you need to, because you can always go back and add it
if you really need it", which is common sense for any project, external or
internal. I'm pretty sure he's not saying "don't add accessors, just use
public members", which is controversial, IMO, even for internal projects.

~~~
jarrett
Controversial might be too strong a word, but there is a counterargument to be
made.

Suppose you have a member named "x." Someday, you might want to stop storing
x, and instead make it a calculated value. At which point you'll need a
method. Or, when setting x, you may someday want to increment a counter, or
transform the input data, or take some other action. Again, you'll need a
method.

Yes, it's very easy to add an accessor later. But then you'll most likely have
to edit every line of code that accessed the now-defunct member variable. Your
IDE may make this easy, but I'd still prefer not to have to do it.

That's not to say writing accessors is _always_ the best choice. I'm just
saying there _can_ be good reasons to do it. Like all things in software
engineering, there's no one-size-fits-all rule about this. Notch is right
about the bloat accessors create, so you have to weight the advantages and
disadvantages yourself in each case.

~~~
Sufrostico
IMHO most software 'service life' it's not long enough to justify the
annoyance of the accessors.

Most software are outdated after a couple of years.

But I still think that accessors are a must if you know that the software will
be immortal (like Internet banking applications)

~~~
figglesonrails
That's a pretty brutal stance. :|

I can't say I know the average shelf life of a software component in various
languages, but I can say that at least things like Java have managed to
justify their use of accessors by that metric. Maybe the focus should be on
writing less throwaway code than deciding whether to "invest" a few extra
minutes or not on accessors.

------
jb55
When watching Notch code I noticed a lot of code smelly habits, relying on
inheritance over composition is one example. But my god his level of
productivity and ability to get shit done is lightyears ahead of your average
programmer, and you got to respect that more than anything.

~~~
kenjackson
Show me someone who doesn't have code smelly habits and I'll show you a book
author or a pedantic blogger -- not a production coder.

~~~
mjwalshe
Amen Borther "forgive me father I used 5 GOTOs last week"

------
switz
I died laughing when I read, "Point is, SOPA sucks."

~~~
djtriptych
As did I. Wish more authors rewarded you like that for reading to the end

~~~
sb1752
Haha that was awesome

------
jasonallen
Interesting post. A couple of observations:

1\. I think programming is a multi-disciplinary task. Notch is obviously among
the best at "writing a lot of working code". He's pointing out that he could
improve in software design. I've work with many folks who are obviously strong
in one area but weaker in others.

2\. I think his coding sloppiness comes through in minecraft: it's an
incredible game, but I've stopped playing at times due to frustration with
crashes and corruption.

...oh, and 3. My guess is that the "large US based game developer" was Valve.

~~~
hythloday
Just guesswork, but I'd imagine it was EA, who have a subsidiary (DICE) in
Stockholm, where Notch lives. Valve (as far as I know) don't have any
Scandinavian subsidiaries.

------
seanalltogether
"I had to work on programming more carefully and think things through before
diving in, or I’d have a hard time working in a large group." This pretty
accurately describes what I went through before joining a larger organization.
However sometimes larger companies train you into a mentality of working fast
and letting QA sort it out, which isn't always the best thing.

~~~
wvenable
After watching notch code a bit, I'd say that the way he dives in and works
has been very successful for him. It's a different style but I don't think
it's bad in of itself. I might definitely be bad when working in large groups,
but that is not the only way to work.

I personally don't think working in a _large_ group is particularly rewarding
for a programmer.

~~~
jiggy2011
It's easier to "dive in" when it's a short term project that you are working
on alone and it's in a problem domain that you are familiar with (in notch's
case games programming).

I'm at the point know where I can build an E-Commerce site in an MVC framework
and implement Client & Admin Logins , Stock management , product search and a
shopping cart without having to engage my brain because the structure to me is
fairly obvious.

On the other hand if I had to design a game I would have to think long and
hard about how the different components would fit together and even then I
would most likely get it wrong somewhere.

------
whimsy
I think there's something to be said for starting out with this sort of
confidence, especially when you're self-taught. That sort of confidence can
provide some incredible motivation. If we realized how much it work it would
take to become well and truly good at things like coding, would we start down
the path with such fervor?

Point is, SOPA sucks.

~~~
bobfunk
As a self-taught programmer I started out with completely the opposite level
of confidence, and considered myself a really lousy programmer.

I always assumed there were all these "real", "professional" programmers out
there that really knew what they're doing, pick crystal clear abstractions,
had profound knowledge of security implications, database optimization, data
structure usage, good use of object orientation, introduced no memory leaks,
knew just what algorithm to pick and wrote great, clear and understandable
code.

I still kinda think I suck, but at least now I know that I'm not alone :)

------
alexwolfe
Have the confidence to know you can do anything.

Have the humility to know you can always get better.

The moment you believe your the best at anything it becomes very dangerous
because you have no reason to improve, your the best. Generally speaking there
are very few people that are the best at anything (In fact only one for each
thing). Most likely there is plenty of room for growth.

I'm glad the author used the negative comment as motivation to get better.

------
nubela
""" But. I still stubbornly believe the whole “private members accessed via
accessors” thing in java is bullcrap for internal projects. It adds piles of
useless boilerplate code for absolutely no gain when you can just right click
a field and chose “add setter/getter” if you NEED an accessor in the future.
"""

YES.

------
richardk
It's comforting to see that other people fluctuate between thinking they're
awesome and thinking they're awful.

Experience has taught me this:

Never build your self-esteem on comparison with another

And by that I mean, you should never judge your own programming abilities
based on other peoples' apparent abilities. If you're programming new stuff
regularly, enjoying it and listening to what other programmers have to say,
then the chances are you're getting better at it, and that's enough.

~~~
olifante
I want to agree, but it's hard to fight against ingrained human instincts. The
need for social validation is very powerful. I would say instead:

If you have to build your self-esteem by comparing to others, do it by looking
at what you've created, not what you know.

------
bbwharris
There is no "Gospel" when it comes to programming. There is a lot of code out
there that isn't pretty, but it works and brings money into businesses.

I think we can all agree that Notch didn't make any mistakes. Minecraft is a
huge success.

They are called "best practices", not "the only practices". But good for Notch
to want to be like everyone else.

~~~
hello_moto
Best Practices are like patterns, solutions to common problems. Sometime there
are problems that require uncommon solution. They are rare, but they exist.

I just hope people don't disagree with Best Practices just because they want
to show their displease with the authoritative...

~~~
itmag
_Best Practices are like patterns, solutions to common problems. Sometime
there are problems that require uncommon solution. They are rare, but they
exist._

This is very interesting, and mirrors some thought I've been having myself.

I would like to see someone create a list of examples of uncommon design
patterns, and list cases in which they might be warranted.

------
jdost
I think the biggest thing he emphasized is the fact that you can never be "The
Best Programmer" because there is always something to learn and ways to grow.
That is probably one of the keys to a good developer, they know that there is
still plenty for them to learn.

~~~
jgw
Yeah. A couple of times, I've met people who have "dabbled" in programming -
maybe done it for a year or two professionally - and said they left the
profession because they's pretty much learned everything there was to know
about programming. I'm always impressed with their capacity to absorb so much,
since I started programming when I was 8 (on a ship, in the middle of the
Atlantic, without a computer) and I'm now 37 and estimate I know about 5% of
all there is to know about programming (an estimate that continually drops as
I learn more).

They must be _really_ good. :)

~~~
dunstad
How did you learn programming on a ship in the middle of the Atlantic?

~~~
jgw
My Mum had bought me a book called the Usborne Guide to BASIC Programming, as
my Dad has just bought an Osborne 1 computer for his new consulting business.
So on our way across the Atlantic on a Polish vessel from Montreal to Dover, I
was enthusiastically learning about programming while the machine sat,
frustratingly, in the cargo hold, inaccessible to my eager mitts.

I still have the Osborne 1. I last powered her up in 2005, when Adam Osborne
passed away.

------
nardsurfer
"Point is, SOPA sucks." haha, nice

~~~
bdg
Instantly made me think of "Carthago delenda est"

<http://en.wikipedia.org/wiki/Carthago_delenda_est>

------
devs1010
I think that the languages and platforms used shape the way one thinks about
programming more than anything and that being exposed to different ecosystems
is important. For example, working in a team of experienced developers that
uses Java will probably rid one of most "cowboy coder" tendencies and instill
a tendency for reflection on architectural patterns, etc, however it can also
lead to over-engineering, "architectural astronauts", etc so then going to a
more dynamic platform like Ruby on Rails (or at least using their
methodologies in projects) helps balance this out. Programming is constantly
evolving and it can be hard to figure out which patterns and processes to
follow but one thing I feel is important is working in teams as it provides a
good way to gauge yourself against others and help expose your own weaknesses.

------
jseims
There are many dimensions to "how good you are as a programmer".

How you approach a 1000 line project is different from a 100,000 line project.

The best practices for a good solo developer are different from a team
developer.

And most importantly, the internal elegance of your code is independent from
how useful / cool your product is.

------
methodin
Reiterates the fact that the more you realize you are a terrible programmer,
the better you are. Very awesome of someone with his stature to flat out admit
the fact that he has flaws. Kudos!

------
chj
I have a Master Degree in CS but programming mostly is self taught by reading
other people's code, good code and ugly code. I know about design patterns
only enough to avoid them like shit. It is just easier to hide shit under a
shinning cover. There is a saying for writers : "every word tells". My
principle is "every line counts". However, this is almost impossible in a team
environment, so I still think that best code is one man job.

------
frederico
loved reading the last comment: point is SOPA sucks.

------
gambler
I honestly don't see what about this post is Hacker News worthy. Is it just
the fact that the post was written by the Minecraft developer? Or it it the
(somewhat questionable) display of humility?

It's sort of like posting a long list of your accomplishments and then saying
"but I don't consider myself special, and I have much more to learn". If the
sentiment was true, you probably wouldn't say it, and almost certainly
wouldn't say it this particular way.

~~~
ohashi
There is definitely a star power associated with someone like Notch which
automatically gets more views. Same goes for a lot of the people you see get
submitted here and voted up.

Is that the only reason? Probably not, but when someone famous says something
it will get a lot more attention than if a nobody says it. Cet par.

------
leon_
> I am a decent programmer.

He's a decent comedian it seems.

~~~
Smudge
Ouch, but probably true for many self-proclaimed "programmers." His success
goes to prove that mastery of skill isn't everything.

------
kenrik
If (There will always be someone better or worse than you.)

Than { Does it really matter? :Bool }

Return: Nope.

~~~
insertnickname
Then

