Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding Skill and the Decline of Stagnation

notch.tumblr.com

Post reply on HN
Print view View original

171–180 of 206 posts

Re: Coding Skill and the Decline of Stagnation

#171

Post by dextorious »

cunac wrote: post #131
groby_b wrote: post #102

Earlier quoted context omitted.

Sigh. If I had a dollar for every "your compiler should optimize away X", I'd be retired. Should doesn't mean does. Plus, no, often I can't afford a function invokation. Because it's yet another cache miss. If all of those things don't matter (or you work on a large enough team that the benefits of abstraction are worth it), yes, add getters/setters everywhere. For the rest of us, we might have actual _reasons_ why w…

one good reason would be because setters and getters are way easier to mock out than direct access to member variable And we all want to have code tested , don't we ? :-)

No, I most certainly don't.

Re: Coding Skill and the Decline of Stagnation

#172

Post by dextorious »

jarrett wrote: post #13
pigs wrote: post #11

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

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

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

Easy is an understatement. It's 2-3 clicks away in Eclipse.

Re: Coding Skill and the Decline of Stagnation

#173

Post by Deestan »

angersock wrote: post #41
Deestan wrote: 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 your fingers protest at the additional "get" in your function names, go and buy yourself a real IDE.

If you can't see how abstraction layers affect performance, go buy yourself a real education. This isn't about premature optimization, it's about not applying premature generalization.

Sometimes it immediately makes sense to add accessors. In that case I add them right away.

Sometimes there is no apparent need for accessors, so I don't add them yet. They're easy to add (you argue so vehemently yourself), why would there be a problem adding them as needed?

A blanket rule of "just add them, always" is just a crutch for mediocre developers who aren't capable or willing to actively think about what they're working on.

Re: Coding Skill and the Decline of Stagnation

#174

Post by jond3k »

jiggy2011 wrote: post #62
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 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…

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

Re: Coding Skill and the Decline of Stagnation

#175

Post by gbog »

SoftwareMaven wrote: post #137
stephth wrote: post #127

Earlier quoted context omitted.

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

In my experience, it's the capacity for holding abstraction in mind that determines how far up the hill a person can go. I don't think there is ever a time where you can't move uphill, but the effort required to move increases more the closer you get to saturating that capacity.

I see what you mean. This is about very complex structures and interactions.

But in fact, I believe with enough time you can get used to any level complexity and find your way through it. It is a bit like a big city: however complex it is (intertwined roads, subways, highways, etc.), if you live there long enough, you will get a precise mental model. Same with software projects: after some time, abstraction will not be those foreign short lived unstable concretions that you hold in your head and that vanish away if someone says hello. They will be good old friends and the sole invocation of their name will instantly call a lot of solid knowledge to the bar.

So in this line, I'd say clever guys are just faster and more agile (maybe both are the same thing). Above a certain level of tolerance to abstract thinking, anyone can understand and work on big complex projects, given enough time.

There is another difference between good and great developers, though. It is the "best path-finding skill". For instance, given enough time, I would probably be able to write a Python script solving most sudokus, but I fear I wouldn't find as elegant and straightforward a path as Norvig's. http://norvig.com/sudoku.html

Re: Coding Skill and the Decline of Stagnation

#176

Post by extension »

goblin89 wrote: post #167
extension wrote: post #161

Earlier quoted context omitted.

But what happens if you incorrectly predict that an abstraction will be needed? Then you made a mistake and hopefully learned something. I didn't say architecting software was easy or without risk, just that you can't avoid doing it by following simplistic rules. The best way to create abstractions is from concrete examples. Write something once. Then, once you actually find yourself writing it twice, abstract it out…

I think the point was that the source code doesn't make the game better or worse. A nightmare of hacks is fine as long as the product is great. IMO writing such code is sometimes even better, especially for a solo developer. If you aim to write beautiful code, it might eventually outweigh everything else, while giving a false impression that you're doing the right thing. Your goal is the product, not code. I'd argue…

Of course source code makes the game better or worse. The game is made of code. The code makes the game what it is.

If you write good code, your product will work better and be done sooner. This is the definition of good code. If you write bad code, your product may be overbudget, buggy, inadequate, and so on. This is the definition of bad code.

There is no dichotomy between the product and the code. To suggest that you can make better software by neglecting the code is absurd.

Re: Coding Skill and the Decline of Stagnation

#177

Post by CognitiveLens »

gbog wrote: post #175
SoftwareMaven wrote: post #137

Earlier quoted context omitted.

In my experience, it's the capacity for holding abstraction in mind that determines how far up the hill a person can go. I don't think there is ever a time where you can't move uphill, but the effort required to move increases more the closer you get to saturating that capacity.

I see what you mean. This is about very complex structures and interactions. But in fact, I believe with enough time you can get used to any level complexity and find your way through it. It is a bit like a big city: however complex it is (intertwined roads, subways, highways, etc.), if you live there long enough, you will get a precise mental model. Same with software projects: after some time, abstraction will not…

> with enough time you can get used to any level [of] complexity

For some people, for certain skills, "enough time" > lifetime.

Re: Coding Skill and the Decline of Stagnation

#178

Post by botj »

noonespecial wrote: post #115

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, wa…

I agree with the spirit of this comment. It's a freaking huge world and you can go broad or go deep but most people can't do both.

As an aside, why do we beat ourselves up so much over this sh*t? We're the most self deprecating group of professionals I've ever met..

Re: Coding Skill and the Decline of Stagnation

#179

Post by [deleted] »

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…

[deleted]

Re: Coding Skill and the Decline of Stagnation

#180

Post by dunstad »

jgw wrote: post #12
jdost wrote: post #9

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.

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

How did you learn programming on a ship in the middle of the Atlantic?
Post reply on HN