A terrible terrible coder? That's a really insulting negative tone. Maybe he is not the best but he is clearly not terrible. Out of all the programmers in the world my guess would be that he is easily in the top 1-5% even if he leaves messy code behind.
No, he really is terrible. I'm dead serious. I am responsible for working with his crap all the time, and I probably know more about the technical workings of Minecraft than even he does.
Sorry to break it to you, but this is the reaction of most people working on others code. It all looks like a bunch of crap held together with duct tape and string when you are the one trying to maintain it or make it do something that wasn't thought about when it was designed.
You're right that reading code is harder than writing, but I think your statement is too extreme - it implies crap code does not really exist or everything is crap. However, we all know that only 90% of everything is crap.
Personally I maintained various codebases (not written by me) and some of them were really terrible, utter mess, while some others were pretty nice to work with, even if I had to refactor sometimes. If programmers thought about code design at least for a while before writing it, and then the code is well-organized (= good separation of concerns, no global state, no copy-paste, complex parts isolated from the simple parts) - it doesn't matter that much that they didn't think of a new feature you're now adding to it.
Can you give a couple of concrete examples of why he's so terrible? Or at least the areas in which he is not strong. Because it's clear to me that Minecraft was a fun and stable experience from the end users perspective, at least when I bought it (which was probably a good 18 months after the initial launch).
I'll put this out there that I'm more in the "I'm a maintainer" group, so my lens when looking at code is very much in the "how can I maintain this" sense.
There were a few articles written up about a year ago [1] from interviews with Notch. He does stuff like direct variable access instead of using setters/getters because it "gets in the way" which when it comes to encapsulation and separation of concern, etc. it throws off some red flags.
I've looked at some of his (at least I believe they were his) projects when attempting to learn a game library (libGDX) and was kinda grossed out by the code. You can say that it's because it was from a Ludum Dare perhaps, but you have to think that he kinda does this all the time. So what would be different from his production stuff.
Pretty much don't look at him as a programming idol, he's simply too cowboy for that. That's fine, cowboys have built tons of stuff, but if you are trying to learn something you may want to avoid their stuff cause it's probably running against the grain in a bad way.
> instead of using setters/getters because it "gets in the way"
In my opinion it genuinely does get in the way. I want to add a member variable to an object - in many languages (JS, C#, Python for example) you can just declare it and move along, knowing that you can switch it to a property later if you need special handling.
In Java, however, for future maintenance I have to write a `public int getPaula()`, `public void setPaula(int brillant)`. This not only violates YAGNI, it slows things down in the physical "I have to type more" sense.
While it would seem that getters and setters vs public fields are very similar, there's a catch at least in the C# world - if you have a raw public field and later decide to change it to a property, that breaks your public interface and you have to rebuild stuff against your library.
Thankfully C# makes declaring getters and setters easy from the start, so it's not an issue to use them:
public int SomeField { get; private set; }
That gives you a public property called SomeField which can be retrieved, but which can only be set privately by the class. I'd hate having to write GetBlah and SetBlah; it's damn ugly.
get/set can be added with a single click in most IDEs and all the references to the private variable are fixed for you. However, having a public getter and public setter for a private field is not really that much safer than a public variable. It is still shared, mutable state and anyone holding a reference to the object can mess with its state.
There's a pattern to your complaints, which is that they are most impacting to long-term external contribution.
That's the area where architecture is driven by philosophy. It's whether or not you _choose_ to study the problem, search for best practices, and work out contingencies during the design phase, or go forward with a simplistic, unknown solution and study it by driving trucks over it[0]. With most exploratory programming - of which games are a prime example - you want to drive trucks because your design is likely to be reworked many times regardless.
As well, independent creation not driven by clients and markets has to be done entirely selfishly. When taking this to heart, one naturally moves towards an exploratory style, because selfish, truck-driving code will satisfy your urges more quickly.
Not being familiar with his programming abilities or style at all, if we took all of the code ever written, is Notch's code at the very bottom of the pile? That is what I take terrible to mean.
According to some links posted elsewhere in this discussion, Notch admits himself that he is not the world's best programmer, but can we honestly say his code is bad enough that we can consider him one of the world's worst programmers?
Or are you really trying to say his code is average to good, with some mistakes made along the way?
