7 ms·

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 o

by Dove 15y ago

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.

jiggy2011 15y ago
I think that's because university teaches abstractions and pretty much nothing else. A project that is done in the average CS class will be presented as a way to teach a design pattern rather than teaching how to solve a problem. Also the marking scheme will tend to favour a broken solution that is an attempt at an elegant abstraction rather than a more basic abstraction that is well tested and works. There is a certain danger in being educated, for example a self educated programmer might have a problem and just implement a O(n^2) solution and move on whereas a college educated programmer might spend excessive time trying to work out a way to do it in O(log N).
- jquery 15y ago
  > I think that's because university teaches abstractions and pretty much nothing else. Maybe my CS degree was unique (I don't think it was), but at the 400 level we had specialization choices including security, graphics, web development, databases, operating systems, embedded, software engineering, etc. > A project that is done in the average CS class will be presented as a way to teach a design pattern rather than teaching how to solve a problem. Design patterns != algorithms. My professors actually spent precious little time teaching me how to program, most of that was self-taught. What they taught me to do was how to solve problems, and that education has been very useful. If your CS professors are spending most of their time teaching you design patterns, you should ask for a refund. The only CS class that taught me design patterns was my 400-level software engineering course.
  - jiggy2011 15y ago
    That's not quite what I meant, most CS classes cover many other things than design patterns. The problem is more that in an undergrad degree you are unlikely to need to do any large scale (by industry standards) project. So the way that they teach you good design is largely forced and the most academic way to do that is through a "design patterns" type class where the project that you are building is small enough not to require design patterns in the first place. This will then educate people that you should really always look for patterns to apply and ways to abstract things since you will be artificially marked up at college for building abstractions and will look for them in every problem you have. On the other hand someone who is more taught by experience will start by writing awful code like putting their whole program into 1 or 2 functions , they will then experience pain points because of this and realise certain re-occuring problems and either come up with their own solutions to them or read "gang of 4" , this will teach them design patterns the natural way.
    - ds206 15y ago
      On the other hand someone who is more taught by experience will start by writing awful code like putting their whole program into 1 or 2 functions , they will then experience pain points because of this and realise certain re-occuring problems and either come up with their own solutions to them or read "gang of 4" , this will teach them design patterns the natural way. This is exactly how I taught myself. The transition from unorganized to organized (patterns) happened for me pretty naturally. For me, it was learn how to organize, or quit. Now-a-days, patterns are everywhere (and probably have been, but I didn't get it until I got it :)
  - teyc 15y ago
    +1 reminds me of j2ee pet shop. Beautiful abstractions; low as a dog.
- ryaf 15y ago
  Your assumption that self taught programmers (ie one that did not get a "formal" education) do not understand fundamentals is utter bullshit. You could reverse your statements and they both still work. I've worked with people that have a masters in CS and in general it matters about 1% of the time. A programmer today has a wealth of information they can pull from that does not require a single ounce of formal education. It takes dedication to the craft not bucket loads of money.
  - jiggy2011 15y ago
    I don't think I made that assumption in that post at all. My point was more that a formal CS education is likely to give you a different perspective on programming vs being self taught. I would imagine most self taught programmers focus on results oriented learning, when I first learned to program before doing any formal CS my approach was "I want to do X , what is the minimum set of stuff I need to learn in order to do that good enough", after learning more formal CS and being forced to consider things like abstraction and efficiency for their own sake I would always focus more on them in every program I write. Not suggesting that you can't be completely self taught and learn everything you could from an academic education (you can) but you are less likely to spend a month learning a bunch of design patterns and algorithms unless they directly apply to something you need to do right now. You are more likely to just start hacking away at something then think "oh, this code is a mess how can I fix that?" rather than reading the entire gang of 4 book to start off with.
    - ilaksh 15y ago
      I guess its obvious, but I am (mainly) a self-taught programmer, and I think that you really don't know what you are talking about. When I was around seven years old, we had a Tandy Color Computer 2. I wore out the book that came with that, playing with BASIC. We also had a Vic 20, a TI-99a and an Ohio Scientific, and eventually an IBM AT compatible. For years, I spent a lot of time playing with short BASIC programs. Eventually, maybe around seventh grade, I got a book called Turbo Pascal Disk Tutor (or something like that). I loved that book and I spent many months studying the book and doing the exercises. I was very serious about learning object-oriented programming. Over the next couple of years I experimented with a simple wireframe 3D CAD-like program. I became very familiar with abstraction, polymorphism and other object-oriented concepts before I entered the 9th grade. Anyway, I'm not going to list every single program I ever wrote or design pattern or programming language or concept I taught myself, but the point is, I did read books and learn a lot of things that are actually apparently missing from many undergrad and even graduate CS-like programs. A guy at Stanford just recently came out with a Rails course partly about software engineering, which apparently is practically revolutionary. There is more contemporary software engineering baked into Rails than what probably more than half of CS or even SE graduates in the last five or ten years ever saw in their courses. And ever since I dropped out of college (only took like two CS-related courses while I was there), I have been extremely motivated to learn as much about CS and software engineering as I can, mainly because of attitudes like yours.
- jond3k 15y ago
  >There is a certain danger in being educated, for example a self educated programmer might have a problem and just implement a O(n^2) solution and move on whereas a college educated programmer might spend excessive time trying to work out a way to do it in O(log N) The CS graduate will have covered big O classifications but if they immediately focus on this form of optimization it's probably because they have spent years reading blogs that tell them this is the nature of tests at places like Google. If every CS grad automatically thought this way by virtue of their education there would be no reason to test for it in interviews simply because a CS degree is often a minimum requirement for the kind of job where you'll be asked these questions. It's only a priority if you make it one and those self-taught guys can probably self-teach themselves big O.
humbledrone 15y ago
> 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...
- deleted 15y ago
  [deleted]
- deleted 15y ago
  [deleted]
- dustingetz 15y ago
  > > The abstraction is just barely enough to get the job done > Or, in other words, the perfect amount... ... until your first hire
  - dminor 15y ago
    You shouldn't optimize a personal project for your first hire. Do the simplest thing that works, and then abstract/iterate.
  - humbledrone 15y ago
    In my experience as a person who has been hired before, I can say that I would absolutely prefer well-factored, but rather concrete code over towering abstractions. Sure, if something is a general feature, it should be abstract. There's nothing more frustrating, though, than wading through layers of abstractions, only to find that hidden behind them is a singular concrete implementation.
- Dove 15y ago
  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.
bjornsing 15y ago
> 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 How can you tell from decompiled optimized code? Not saying you can't, just interested. Haven't read much decompiled.
- plorkyeran 15y ago
  The compiler can't really change things like the class hierarchy, and a lot of the more interesting optimizations are done at runtime.
  - Dove 15y ago
    Right. If you're coming from a C background, you'd be amazed how much information from the source is preserved in a Java .class file. To my knowledge, C++ turns into a binary blob, and a lot of magic can happen along the way. But Java turns into a slightly more machine-readable version of Java. A lot of the structure in the code is actually directly meaningful to the JVM. All the details of the object -- its variable names and types, its methods and their signatures, the class hierarchy, even sometimes the line number in the original source code -- is still there. The preservation is so complete that it has been said all Java programs are essentially open source (the sort of thing people would normally say about, say, Javascript). Now, last time I played with Minecraft, it had been run through an obfuscator as well, so some of that doesn't apply. In particular, the variable and method names have been reduced to gibberish, and I don't know what sort of monkey business might have occured around inlining constants. But macro structure doesn't change. In Java, given the way .class files work, it really can't change. And that's where a lot of the abstraction in a project lives. The class hierarchy is still there. Use of interfaces is still there. How you organize data, how you manufacture objects, which function calls which function, it's all still there. Even little things, like whether your functions return objects, enumerations, or magic numbers, is unchanged. Even in decompiled code, even right at the start, you can blur your eyes, and at a glance you'll see either a lot of little functions or a few big ones, a lot of little classes or a few big ones, a lot of inheritance relationships through abstract classes or a few simple ones.
mattdeboard 15y ago
I'd kinda like this kind of evaluation on the code I write for work.
- Dove 15y ago
  I once spent about nine months creating a largish program, and then moved on to another job. I spent about a day educating the fellow who would be carrying on the maintenance. I barely knew him. About a year later, we met again. I still didn't know him, but he sure felt that he knew me. I remember he greeted me with, "I love your sense of humor", and "If you really want to know someone, you should work on their code for a year." No doubt he knew me as a programmer much better than I know myself. Talk to someone who's maintained your code. :)
- cpeterso 15y ago
  Code reviews are a great way to get feedback on your work. Like open-source, knowing your code will be seen by co-workers is a strong personal incentive to produce better work. If your work does not do reviews now, you can still ask a co-worker to look over you code changes. Many people would be flattered that you would ask for their programming wisdom. ;)
ilaksh 15y ago
>The abstraction is just barely enough to get the job done, and the algorithms are decidedly homebrew. Wow.. actually your comment is EXTREMELY critical and very dishonest in the end claiming that its not a criticism. I'm just curious, what software have you written, and how many millions of users does it have?
fbru02 15y ago
Can you point to resources/books where I can read more about design as is taught in CS degrees? I'm curious on their problem solving strategies compared to mine.

by Dove 15y ago

jiggy2011 15y ago

I think that's because university teaches abstractions and pretty much nothing else. A project that is done in the average CS class will be presented as a way to teach a design pattern rather than teaching how to solve a problem. Also the marking scheme will tend to favour a broken solution that is an attempt at an elegant abstraction rather than a more basic abstraction that is well tested and works. There is a certain danger in being educated, for example a self educated programmer might have a problem and just implement a O(n^2) solution and move on whereas a college educated programmer might spend excessive time trying to work out a way to do it in O(log N).

jquery 15y ago
> I think that's because university teaches abstractions and pretty much nothing else. Maybe my CS degree was unique (I don't think it was), but at the 400 level we had specialization choices including security, graphics, web development, databases, operating systems, embedded, software engineering, etc. > A project that is done in the average CS class will be presented as a way to teach a design pattern rather than teaching how to solve a problem. Design patterns != algorithms. My professors actually spent precious little time teaching me how to program, most of that was self-taught. What they taught me to do was how to solve problems, and that education has been very useful. If your CS professors are spending most of their time teaching you design patterns, you should ask for a refund. The only CS class that taught me design patterns was my 400-level software engineering course.
- jiggy2011 15y ago
  That's not quite what I meant, most CS classes cover many other things than design patterns. The problem is more that in an undergrad degree you are unlikely to need to do any large scale (by industry standards) project. So the way that they teach you good design is largely forced and the most academic way to do that is through a "design patterns" type class where the project that you are building is small enough not to require design patterns in the first place. This will then educate people that you should really always look for patterns to apply and ways to abstract things since you will be artificially marked up at college for building abstractions and will look for them in every problem you have. On the other hand someone who is more taught by experience will start by writing awful code like putting their whole program into 1 or 2 functions , they will then experience pain points because of this and realise certain re-occuring problems and either come up with their own solutions to them or read "gang of 4" , this will teach them design patterns the natural way.
  - ds206 15y ago
    On the other hand someone who is more taught by experience will start by writing awful code like putting their whole program into 1 or 2 functions , they will then experience pain points because of this and realise certain re-occuring problems and either come up with their own solutions to them or read "gang of 4" , this will teach them design patterns the natural way. This is exactly how I taught myself. The transition from unorganized to organized (patterns) happened for me pretty naturally. For me, it was learn how to organize, or quit. Now-a-days, patterns are everywhere (and probably have been, but I didn't get it until I got it :)
- teyc 15y ago
  +1 reminds me of j2ee pet shop. Beautiful abstractions; low as a dog.
ryaf 15y ago
Your assumption that self taught programmers (ie one that did not get a "formal" education) do not understand fundamentals is utter bullshit. You could reverse your statements and they both still work. I've worked with people that have a masters in CS and in general it matters about 1% of the time. A programmer today has a wealth of information they can pull from that does not require a single ounce of formal education. It takes dedication to the craft not bucket loads of money.
- jiggy2011 15y ago
  I don't think I made that assumption in that post at all. My point was more that a formal CS education is likely to give you a different perspective on programming vs being self taught. I would imagine most self taught programmers focus on results oriented learning, when I first learned to program before doing any formal CS my approach was "I want to do X , what is the minimum set of stuff I need to learn in order to do that good enough", after learning more formal CS and being forced to consider things like abstraction and efficiency for their own sake I would always focus more on them in every program I write. Not suggesting that you can't be completely self taught and learn everything you could from an academic education (you can) but you are less likely to spend a month learning a bunch of design patterns and algorithms unless they directly apply to something you need to do right now. You are more likely to just start hacking away at something then think "oh, this code is a mess how can I fix that?" rather than reading the entire gang of 4 book to start off with.
  - ilaksh 15y ago
    I guess its obvious, but I am (mainly) a self-taught programmer, and I think that you really don't know what you are talking about. When I was around seven years old, we had a Tandy Color Computer 2. I wore out the book that came with that, playing with BASIC. We also had a Vic 20, a TI-99a and an Ohio Scientific, and eventually an IBM AT compatible. For years, I spent a lot of time playing with short BASIC programs. Eventually, maybe around seventh grade, I got a book called Turbo Pascal Disk Tutor (or something like that). I loved that book and I spent many months studying the book and doing the exercises. I was very serious about learning object-oriented programming. Over the next couple of years I experimented with a simple wireframe 3D CAD-like program. I became very familiar with abstraction, polymorphism and other object-oriented concepts before I entered the 9th grade. Anyway, I'm not going to list every single program I ever wrote or design pattern or programming language or concept I taught myself, but the point is, I did read books and learn a lot of things that are actually apparently missing from many undergrad and even graduate CS-like programs. A guy at Stanford just recently came out with a Rails course partly about software engineering, which apparently is practically revolutionary. There is more contemporary software engineering baked into Rails than what probably more than half of CS or even SE graduates in the last five or ten years ever saw in their courses. And ever since I dropped out of college (only took like two CS-related courses while I was there), I have been extremely motivated to learn as much about CS and software engineering as I can, mainly because of attitudes like yours.
jond3k 15y ago
>There is a certain danger in being educated, for example a self educated programmer might have a problem and just implement a O(n^2) solution and move on whereas a college educated programmer might spend excessive time trying to work out a way to do it in O(log N) The CS graduate will have covered big O classifications but if they immediately focus on this form of optimization it's probably because they have spent years reading blogs that tell them this is the nature of tests at places like Google. If every CS grad automatically thought this way by virtue of their education there would be no reason to test for it in interviews simply because a CS degree is often a minimum requirement for the kind of job where you'll be asked these questions. It's only a priority if you make it one and those self-taught guys can probably self-teach themselves big O.

humbledrone 15y ago

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

deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
dustingetz 15y ago
> > The abstraction is just barely enough to get the job done > Or, in other words, the perfect amount... ... until your first hire
- dminor 15y ago
  You shouldn't optimize a personal project for your first hire. Do the simplest thing that works, and then abstract/iterate.
- humbledrone 15y ago
  In my experience as a person who has been hired before, I can say that I would absolutely prefer well-factored, but rather concrete code over towering abstractions. Sure, if something is a general feature, it should be abstract. There's nothing more frustrating, though, than wading through layers of abstractions, only to find that hidden behind them is a singular concrete implementation.
Dove 15y ago
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.

bjornsing 15y ago

> 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 How can you tell from decompiled optimized code? Not saying you can't, just interested. Haven't read much decompiled.

plorkyeran 15y ago
The compiler can't really change things like the class hierarchy, and a lot of the more interesting optimizations are done at runtime.
- Dove 15y ago
  Right. If you're coming from a C background, you'd be amazed how much information from the source is preserved in a Java .class file. To my knowledge, C++ turns into a binary blob, and a lot of magic can happen along the way. But Java turns into a slightly more machine-readable version of Java. A lot of the structure in the code is actually directly meaningful to the JVM. All the details of the object -- its variable names and types, its methods and their signatures, the class hierarchy, even sometimes the line number in the original source code -- is still there. The preservation is so complete that it has been said all Java programs are essentially open source (the sort of thing people would normally say about, say, Javascript). Now, last time I played with Minecraft, it had been run through an obfuscator as well, so some of that doesn't apply. In particular, the variable and method names have been reduced to gibberish, and I don't know what sort of monkey business might have occured around inlining constants. But macro structure doesn't change. In Java, given the way .class files work, it really can't change. And that's where a lot of the abstraction in a project lives. The class hierarchy is still there. Use of interfaces is still there. How you organize data, how you manufacture objects, which function calls which function, it's all still there. Even little things, like whether your functions return objects, enumerations, or magic numbers, is unchanged. Even in decompiled code, even right at the start, you can blur your eyes, and at a glance you'll see either a lot of little functions or a few big ones, a lot of little classes or a few big ones, a lot of inheritance relationships through abstract classes or a few simple ones.

mattdeboard 15y ago

I'd kinda like this kind of evaluation on the code I write for work.

Dove 15y ago
I once spent about nine months creating a largish program, and then moved on to another job. I spent about a day educating the fellow who would be carrying on the maintenance. I barely knew him. About a year later, we met again. I still didn't know him, but he sure felt that he knew me. I remember he greeted me with, "I love your sense of humor", and "If you really want to know someone, you should work on their code for a year." No doubt he knew me as a programmer much better than I know myself. Talk to someone who's maintained your code. :)
cpeterso 15y ago
Code reviews are a great way to get feedback on your work. Like open-source, knowing your code will be seen by co-workers is a strong personal incentive to produce better work. If your work does not do reviews now, you can still ask a co-worker to look over you code changes. Many people would be flattered that you would ask for their programming wisdom. ;)

ilaksh 15y ago

>The abstraction is just barely enough to get the job done, and the algorithms are decidedly homebrew. Wow.. actually your comment is EXTREMELY critical and very dishonest in the end claiming that its not a criticism. I'm just curious, what software have you written, and how many millions of users does it have?

fbru02 15y ago

Can you point to resources/books where I can read more about design as is taught in CS degrees? I'm curious on their problem solving strategies compared to mine.