Coding Skill and the Decline of Stagnation • Hacker News Board

Re: Coding Skill and the Decline of Stagnation

#191

Post by akg » Sat, Jan 14, 2012, 6:38 PM UTC

Sufrostico wrote: post #28

jarrett wrote: post #13

Earlier quoted context omitted.

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…

IMHO most software 'service life' it's not long enough to justify the annoyance of the accessors. Most software are outdated after a couple of years. But I still think that accessors are a must if you know that the software will be immortal (like Internet banking applications)

I think most companies have tons of legacy code that is stilly lying around and in production use. When I was at Dreamworks Animation, we were still using tools written back in the 1980s to create animated features; albeit we kept improving on it whenever it didn't fit the bill.

Re: Coding Skill and the Decline of Stagnation

#192

Post by eurohacker » Sat, Jan 14, 2012, 6:53 PM UTC

ceol wrote: post #188

eliben wrote: post #142

Earlier quoted context omitted.

Project this onto math, and we all could be Ramanujan or Galois with the right investment of time, right? Of course not. People differ in level of intelligence, and this is a fact. Some programmers are just brilliant people - had they chosen math they would probably be professors churning out papers. Some others just don't have the mental skills required. This isn't about race or gender or whatever - just innate diff…

> People differ in level of intelligence, and this is a fact. Define intelligence.

intelligence - ability to recognize patterns in everyday life and adopting correspondingly

Re: Coding Skill and the Decline of Stagnation

#193

Post by alexwolfe » Sat, Jan 14, 2012, 6:55 PM UTC

Have the confidence to know you can do anything.

Have the humility to know you can always get better.

The moment you believe your the best at anything it becomes very dangerous because you have no reason to improve, your the best. Generally speaking there are very few people that are the best at anything (In fact only one for each thing). Most likely there is plenty of room for growth.

I'm glad the author used the negative comment as motivation to get better.

Re: Coding Skill and the Decline of Stagnation

#194

Post by kragen » Sat, Jan 14, 2012, 6:55 PM UTC

doyoulikeworms wrote: post #120

jiggy2011 wrote: post #87

Earlier quoted context omitted.

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.

But when you write an exam, clues to your mental state are all throughout the material you write on the exam, and that mental state includes everything you know. Someone who's "good at passing exams" can extract clues to your mental state from the wording of the questions and figure out what kind of answer you want. On multiple-choice exams, they only need to come up with 2 bits of information about which answer to choose, and the proposed answers themselves give additional clues to the exam-writer's state of mind. 2 bits doesn't feel like mastery; it feels like an educated guess.

It depends on the subject area, of course, and the skill of the exam writer. But it's very common to be able to pass multiple-choice exams without knowing anything at all about the material.

Knowing the material, of course, helps you come up with the right answer --- but it also helps you a lot with "reading" the exam writer. And you don't necessarily need to know a whole lot about the material to get an advantage that way.

It's also often possible to get acceptable marks on exams by parroting rather than deep comprehension.

I think my test-taking skills were usually worth one to two letter grades' worth on exams when I was in school. I could usually get a D or C on exams where I should have gotten an F, and an A on exams where I should have gotten a B or a C. A little while back, I got 97% correct on the ai-class final exam without having learned more than half of the material. (In that case, though, I think the test also failed to cover most of the material.)

I think non-multiple-choice math exams are probably the hardest to "fake out" this way.

There are other people whose test-taking "skills" actually have a negative effect on their scores. First, they study the material in their bedroom or at the kitchen table, rather than the classroom, unnecessarily impairing their recall when the exam comes. Then, they show up to the exam exhausted and sleep-deprived from cramming all night, damaging their ability to think creatively or tolerate stress, and then they have an extreme stress response from the test-taking situation, further handicapping their ability to think. It's easy to imagine that someone like that could fail a test I'd get an A on, with the same level of knowledge.

Re: Coding Skill and the Decline of Stagnation

#195

Post by esrauch » Sat, Jan 14, 2012, 8:32 PM UTC

jeremysalwen wrote: post #164

esrauch wrote: post #79

Earlier quoted context omitted.

Except there are cases where it will be way more pain later and no perceptible loss ahead of time. Imagine you are debugging something and you want to know where your public variable is getting set to 3. If you are using java and public members you will have to check every single call site, whereas if you have a setter you can just add a single if(x==3){} and put a breakpoint in there and you have done in 30 seconds…

Eclipse can add a breakpoint to a variable. Any time that variable is accessed or set, the breakpoint is tripped. That's less than 30 seconds, that's like 5. You literally just click to the left of the variable definition.

The point of my example is you can put a breakpoint under any complex condition, I guess I should have made it more complex something like if(someComplexCalculatedValue() == 10). Anything that can be expressed can be added as a breakpoint if you use setters, then you won't have to step through every assignment, which could be thousands in applications.

Re: Coding Skill and the Decline of Stagnation

#196

Post by easp » Sat, Jan 14, 2012, 9:55 PM UTC

ceol wrote: post #188

eliben wrote: post #142

Earlier quoted context omitted.

Project this onto math, and we all could be Ramanujan or Galois with the right investment of time, right? Of course not. People differ in level of intelligence, and this is a fact. Some programmers are just brilliant people - had they chosen math they would probably be professors churning out papers. Some others just don't have the mental skills required. This isn't about race or gender or whatever - just innate diff…

> People differ in level of intelligence, and this is a fact. Define intelligence.

Which seems to underscore his point.

Re: Coding Skill and the Decline of Stagnation

#197

Post by ceol » Sat, Jan 14, 2012, 11:38 PM UTC

easp wrote: post #196

ceol wrote: post #188

Earlier quoted context omitted.

> People differ in level of intelligence, and this is a fact. Define intelligence.

Which seems to underscore his point.

"Intelligence" isn't some stat you train to make your spells do more damage. It's a complex mix of what you've learned, how you learn, and who's teaching you. "Intelligence" is just as hard to define as "consciousness".

Re: Coding Skill and the Decline of Stagnation

#198

Post by humbledrone » Sun, Jan 15, 2012, 12:58 AM UTC

hackinthebochs wrote: post #185

humbledrone wrote: post #149

Earlier quoted context omitted.

Have you ever looked at a class named ObjectFactoryFacadeCollection and thought to yourself, "oh boy, this part will be fun to read?" On one hand there's the complexity of the problem you're solving. On the other hand, there's incidental complexity. The ObjectFactoryFacadeCollection class squarely falls into the incidental complexity category. In other words, the moment you are writing a class of that sort, you have…

This isn't necessarily true. Sometimes you do in fact need these types of abstractions. This is why they've been made into patterns. The trick is to not use it before its necessary. The mere existence of it doesn't imply overengineered code.

Yes, of course you do sometimes need these types of abstractions, but you seem to have missed my point: they are a factor of incidental complexity. To restate, they are not at all inherent to the problem you are trying to solve. They are inherent to the tools with which you are solving the problem.

For instance, if your problem is calculating the trajectory of a projectile, a solution certainly exists that does not involve anything at all like an ObjectFactoryFacadeCollection. However, certain solutions involving unnecessarily complex abstractions could conceivably require one. This is incidental complexity. On the other hand, all solutions will require some information about the projectile's velocity, gravity, and so forth. This is complexity that is inherent to the problem itself.

Re: Coding Skill and the Decline of Stagnation

#199

Post by nostrademons » Sun, Jan 15, 2012, 1:59 AM UTC

kragen wrote: post #194

doyoulikeworms wrote: post #120

Earlier quoted context omitted.

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

But when you write an exam, clues to your mental state are all throughout the material you write on the exam, and that mental state includes everything you know. Someone who's "good at passing exams" can extract clues to your mental state from the wording of the questions and figure out what kind of answer you want. On multiple-choice exams, they only need to come up with 2 bits of information about which answer to c…

"Someone who's "good at passing exams" can extract clues to your mental state from the wording of the questions and figure out what kind of answer you want."

I actually tried an experiment on this when I was in high school. I took the AP Comparative Government without ever having taken the course, or really having any sort of academic exposure to it (hey, it was free with the purchase of the AP US Government, and I was taking the day off from school anyway for the latter test). My only knowledge consisted of what I read in the newspapers, plus half an hour with a test prep booklet at breakfast that morning, plus whatever I could glean from the test questions themselves.

I scored a 3 on it. Not a great score, but passing. Pretty good, actually, considering that the test involved writing 4 essays on a subject I knew nothing about. So I figure perhaps 50% of the outcome of a test is knowing the material and the other 50% is test-taking skills.

Ironically, though, I think that the skill of extracting subtle clues to the mental state of the people around you, and the answers they expect, is far more valuable than any subject matter you learn in school. It's absolutely essential if you work in an organization, so you can understand who the decision makers are, what their priorities are, and what will really impress them without them having to tell you anything. It's absolutely essential if you manage people, so that you understand why they're working for you and what will motivate them to do their best work. And it's absolutely essential if you choose to strike out on your own and be an entrepreneur, because that's how you tell what customers want. They're generally indifferent to you and often have no clue what they actually want; there's no way you'll get them to tell you.

Re: Coding Skill and the Decline of Stagnation

#200

Post by goblin89 » Sun, Jan 15, 2012, 1:16 PM UTC

extension wrote: post #176

goblin89 wrote: post #167

Earlier quoted context omitted.

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…

> The code makes the game what it is.

No arguing with that. Same as building material makes a house what it is. The question is, does the success depend on material used? You can build a great house amidst the desert.

But that's an analogy. More real-world example—imagine two startups:

- Startup 1: bad programmer, good QA. - Startup 2: good programmer, bad QA.

Where would you invest your money?

> If you write bad code, your product may be overbudget, buggy, inadequate, and so on.

Here I disagree. Overbudget? It depends on product success. Buggy? If you have good QA, it's not buggy. Inadequate? You can write the cleanest code, but your product won't work as users want it to.

When we say ‘great product’, do we mean that it has nice clean code, or it's something else? How many great products have bad code?

> There is no dichotomy between the product and the code.

As long as you are ‘just a’ developer, and there are other people focusing on product and its functional quality. In that case you receive specific tasks with deadlines, and yes, you should focus on writing good code.

Not so if you're a solo developer.

1) No one will focus on the product, except you. 2) You most likely would be heavily biased towards writing good code. (Because you're a developer, you're supposed to write good code, right?)

You need to force yourself to focus on the product, to avoid becoming the Startup 2 from above example. Intentionally writing bad code is one way to do that. In that case you at least can be that Startup 1—you'll be forced to pay more attention to functional quality (as opposed to structural), so you'll be good QA.

You can argue that one can focus on both. My opinion is that it's too risky. You need to have priorities set as clear as possible.

> To suggest that you can make better software by neglecting the code is absurd.

Yes, it sounds really controversial (especially to a programmer). I'm far from satisfied with that statement. What would be a better way to be a good QA while being a great programmer?