Coding Skill and the Decline of Stagnation • Hacker News Board

Re: Coding Skill and the Decline of Stagnation

#111

Post by jiggy2011 » Sat, Jan 14, 2012, 12:45 AM UTC

Dove wrote: post #105

humbledrone wrote: post #70

Earlier quoted context omitted.

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

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…

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.

Re: Coding Skill and the Decline of Stagnation

#112

Post by Dove » Sat, Jan 14, 2012, 12:59 AM UTC

plorkyeran wrote: post #104

bjornsing wrote: post #97

Earlier quoted context omitted.

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

The compiler can't really change things like the class hierarchy, and a lot of the more interesting optimizations are done at runtime.

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.

Re: Coding Skill and the Decline of Stagnation

#113

Post by X-Istence » Sat, Jan 14, 2012, 1:07 AM UTC

switz wrote: post #5

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

It came out of left field, completely unwarranted and unexpected and made me laugh for minutes. My room mates were looking at me funny.

Not many people would throw a non-sequitor out there that nonchalantly and have it work so well.

Re: Coding Skill and the Decline of Stagnation

#114

Post by ken » Sat, Jan 14, 2012, 1:11 AM UTC

jiggy2011 wrote: post #47

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…

That's an interesting dichotomy. I have a CS degree from a well-respected school, but as far as programming goes, I would say I'm at least 90% self-taught. I guess I assumed that all programmers are essentially self-taught, regardless of educational background.

Re: Coding Skill and the Decline of Stagnation

#115

Post by noonespecial » Sat, Jan 14, 2012, 1:23 AM UTC

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.

Re: Coding Skill and the Decline of Stagnation

#116

Post by sbov » Sat, Jan 14, 2012, 1:26 AM UTC

jiggy2011 wrote: post #111

Dove wrote: post #105

Earlier quoted context omitted.

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…

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 ab…

Premature abstractions can have similar issues: unless you have more than 2 cases you don't necessarily know what your abstraction should look like. As the cases pile up you find yourself increasingly shoehorning implementations into abstractions that don't quite abstract correctly.

Re: Coding Skill and the Decline of Stagnation

#117

Post by devs1010 » Sat, Jan 14, 2012, 1:46 AM UTC

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.

Re: Coding Skill and the Decline of Stagnation

#118

Post by Dove » Sat, Jan 14, 2012, 1:57 AM UTC

jiggy2011 wrote: post #111

Dove wrote: post #105

Earlier quoted context omitted.

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…

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 ab…

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.

Re: Coding Skill and the Decline of Stagnation

#119

Post by Dove » Sat, Jan 14, 2012, 2:12 AM UTC

mattdeboard wrote: post #107

Dove wrote: post #57

Earlier quoted context omitted.

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…

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

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

Re: Coding Skill and the Decline of Stagnation

#120

Post by doyoulikeworms » Sat, Jan 14, 2012, 2:26 AM UTC

jiggy2011 wrote: post #87

nostrademons wrote: post #71

Earlier quoted context omitted.

"Does anybody know if Notch is self taught? I thought he had a CS Degree from somewhere?" The two are not mutually exclusive. I was talking with a friend recently who's working on her Ph.D, observing that everyone who thought I was so smart in college is now better educated, officially, than me. She was like "You're basically self-taught, but with a piece of paper that says you were willing to stick around in college…

This is interesting, when I studied CS at university I'd say there were 2 different types of people that got high marks. There were people who were self taught , either before they started CS or once they learned some programming at university they identified other areas outside the course that interested them and they could apply their new programming skills. These people typically got jobs in the software industry…

> They got equally high marks because they were good at passing exams.

I don't understand how this makes sense, unless being "good at passing exams" means "cheating". Can anybody explain? I hear this said so often, and I usually chalk it up to the speaker rationalizing his own poor scores.

My CS exams were always hard, and the only way to "get good" at passing them was to learn the material.