Live data from Hacker News

Coding Skill and the Decline of Stagnation

notch.tumblr.com

61–70 of 206 posts

Re: Coding Skill and the Decline of Stagnation

#61
post #51

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…

There is much knowledge than you can learn. Try to focus your learning on what help you solve your clients problems. You'll become an expert only in a thing or two, and you'll be able to talk about it like the people here on HN. Also the smart comment writer is not a representative of the average HN visitor/population. There are always people who are expert in their niches.

This is true, However at some point I want to move my career in a different direction and most of what I learn on the job is industry specific and the industry itself is not something that hugely interests me (although I have not decided for sure what I want to do). So I am trying to learn as much fundamental stuff as possible.

The issue is deciding how much one should know about something before you confidently put it on your resume.

For example I would say that I am an OK Java programmer but I avoid using enterprise frameworks which are commonly used in many companies so there are many parts of the language which I am not familiar with simply because I have never had cause to use them, for example I do almost all of my persistence using a database and ORM so I almost never have to use Java's concurrency locking features in the wild as I do all my locking in the DB.

The same with functional programming, there is no reason to learn it for my job but I get a feeling it will become more important as time moves on so I should know something about it.

There is allot of stuff on HN with people saying that everyone should have implemented a toy compiler at somepoint and if you haven't then your not a serious programmer , or perhaps it is a Toy OS etc etc.

Re: Coding Skill and the Decline of Stagnation

#62
post #57

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…

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

Re: Coding Skill and the Decline of Stagnation

#63
post #43

Earlier quoted context omitted.

Joshua Bloch in Effective Java argues that the java bean is an anti-pattern and should be avoided.

Cool story, bro. (Mime aside, do we get to hear what the argument was?)

The crux of the argument (and most of the book for that matter) is that you want to avoid mutability whenever possible. Adding setters for every field by default means mutability is the default mode for your application. Adding getters for every field by default means you lose any advantages of encapsulation. At one time, Java Beans were a heavily marketed pattern by Sun. Joshua Bloch came along and said "hey, this is a bad pattern" (and maybe others, but he's the one I always think of).

Re: Coding Skill and the Decline of Stagnation

#64
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 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 cert…

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

Re: Coding Skill and the Decline of Stagnation

#65
post #60

Earlier quoted context omitted.

What, is there some kind of run on parens in your neck of the woods? Running such a lean startup you can't afford a function invocation? This isn't premature abstraction or architecture astronautics--this is just good practice. If you are in a language like Java or C, your compiler should optimize away the call if it doesn't do something clever. If you are in Ruby, this is so easy to do that it doesn't even need ment…

Running such a lean startup you can't afford a function invocation? This actually isn't as wildly hypothetical a situation as one might guess. At least in the Android world, "Avoid getters and setters" is on the short list of performance suggestions. http://developer.android.com/guide/practices/design/performa...

Avoid internal getters and setters. This is a different issue vs. object to object getters and setters.

Re: Coding Skill and the Decline of Stagnation

#66
post #60

Earlier quoted context omitted.

What, is there some kind of run on parens in your neck of the woods? Running such a lean startup you can't afford a function invocation? This isn't premature abstraction or architecture astronautics--this is just good practice. If you are in a language like Java or C, your compiler should optimize away the call if it doesn't do something clever. If you are in Ruby, this is so easy to do that it doesn't even need ment…

Running such a lean startup you can't afford a function invocation? This actually isn't as wildly hypothetical a situation as one might guess. At least in the Android world, "Avoid getters and setters" is on the short list of performance suggestions. http://developer.android.com/guide/practices/design/performa...

Ok, but in the general case (Sun/Oracle JDK) I'm pretty sure that there's almost no overhead for using an accessor anymore. That wasn't true of early JDKs though.

Re: Coding Skill and the Decline of Stagnation

#67
post #38

Earlier quoted context omitted.

> Oh, and for good measure--everytime you force yourself to use an accessor, you are providing the opportunity for somebody down the line to add debug and validation code. So add it then . Don't pre-generalize everything just in case.

What, is there some kind of run on parens in your neck of the woods? Running such a lean startup you can't afford a function invocation? This isn't premature abstraction or architecture astronautics--this is just good practice. If you are in a language like Java or C, your compiler should optimize away the call if it doesn't do something clever. If you are in Ruby, this is so easy to do that it doesn't even need ment…

If you are in Ruby, you don't get a choice about accessors: "@foo" and "@bar" are private member variables. You have to create accessors for them. Like you said, though, the accessor / property generation command is easy: "attr_accessor :foo, :bar"

Even if the (Java, or otherwise) IDE can generate piles of crap code, I still hate reading piles of crap code, though. Sometimes I just want a "struct" :-)

Now back to my Java work...

Re: Coding Skill and the Decline of Stagnation

#68
post #43

Earlier quoted context omitted.

The getter/setter stuff in java is a huge waste of space and time. However, at least in the enterprise space, all of the tooling and frameworks assume your code follows the java bean naming conventions. For this reason alone I always make sure all my classes follow the pattern and whenever I train new developers I make sure they get a large amount of experience building out bean definitions and understand how much ti…

Joshua Bloch in Effective Java argues that the java bean is an anti-pattern and should be avoided.

Oh thank God somebody in authority is calling this bean bull_hit what it is.

After reading the Eiffel book and thinking about things like programming by contract and class invariants, the bean pattern which constructs empty, initially useless (or at least unreliable) objects seemed like a huge step back.

Re: Coding Skill and the Decline of Stagnation

#69
post #63

Earlier quoted context omitted.

Cool story, bro. (Mime aside, do we get to hear what the argument was?)

The crux of the argument (and most of the book for that matter) is that you want to avoid mutability whenever possible. Adding setters for every field by default means mutability is the default mode for your application. Adding getters for every field by default means you lose any advantages of encapsulation. At one time, Java Beans were a heavily marketed pattern by Sun. Joshua Bloch came along and said "hey, this i…

Why does everything have a getter/setter by default? That is a pretty horrible anti-pattern, is it something to do with being able to serialise the state (including internal state) of the whole object?

Re: Coding Skill and the Decline of Stagnation

#70
post #57

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…

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…

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

Post reply on HN