23,670 reputation
14996
bio website back2dos.wordpress.com
location LE City - Germany
age 29
visits member for 4 years, 7 months
seen Mar 1 at 16:54

"the code is the design"


Mar
25
awarded  Nice Answer
Feb
27
revised Frankly, do you prefer Cowboy coding?
added 264 characters in body
Feb
16
awarded  Nice Answer
Feb
6
awarded  Guru
Feb
5
comment Is prototypal inheritance inherently slower?
@JonathanJ.Bloggs: Yes, although that's really just a REPL with access to the DOM. Smalltalk and later Self had programming environments that were fully interactive and persistent. I think you will find Self: The Movie quite impressive.
Feb
5
answered Is prototypal inheritance inherently slower?
Feb
5
comment Leaving intentional bugs in code for testers to find
@Dunk I have pondered this a lot. We probably just have a very different culture. You seem to perceive work as a process that creates products to satisfy some metric. I think of it as a path to personal growth, a broadening as well as a deepening of skills. Circumstances change. What has been good enough yesterday, may be obsolete tomorrow. The habit of putting yourself to the test helps in transcending the volatile nature of things. Developing and following it, I think, is not a terrible idea, but one well worth the attempt and even failure.
Feb
2
awarded  Nice Answer
Jan
29
comment Leaving intentional bugs in code for testers to find
@Dunk You are simply contradicting yourself. You said the number you proposed is a sensible metric. It is far from it, as I have abundantly explained. Your analogy is much better suited for your claim than mine. Why I say the idea is not terrible is because it is merely the application of the general idea that if somebody improves during training, they will do better in the field. That's why people train. Of course you cannot accurately measure the effectiveness of QA. I didn't claim you can. But suggesting to therefore not even try is a perfect solution fallacy.
Jan
29
comment Leaving intentional bugs in code for testers to find
@Dunk No that is not "completely and totally false". Try reasoning in categories other than extremes. I said the number correlates more than the one you proposed. If less bugs make it into production in release B than in release A, then it can meaning anything. For example that release B was easier to get right. Or, as I said, that the programming methodology has improved or what not. Or that users do not discover the features in B and therefore do not report defects they encounter. Almost none of the effects you propose measuring say anything about the QA.
Jan
29
comment Leaving intentional bugs in code for testers to find
@Dunk As opposed to that, the "false error" actually does give you more information, under the assumption that the difficulty of finding them doesn't fluctuate erratically (which can be arranged). Because you know how many artificial defects there are, you can tell exactly what percentage of them were caught in QA. So the extra information you get is how effective QA is in detecting artificial defects. And that number certainly correlates more with their overall effectiveness than the one you suggested.
Jan
29
comment Leaving intentional bugs in code for testers to find
@Dunk Then you didn't read the question properly. It suggests that this method increases morale and also thoroughness. Also the number of bugs that make it through QA doesn't reliably measure the effectiveness of the QA team. It is equally affected by how many bugs the developers introduce. If they start using TDD and there is a sudden decrease in defects in the release, what does that say about the testers? Nothing.
Jan
28
comment Leaving intentional bugs in code for testers to find
@Dunk: Keeping track of that number won't make your team better automatically, much like keeping score in a sport doesn't make you the best athlete you could be. In fact athletes do train, i.e. perform artificial tasks to increase their performance in a controllable fashion, which is not unlike what is being proposed here. Unless you have an idea how to get people to improve that number, it's of little value.
Jan
28
answered Leaving intentional bugs in code for testers to find
Jan
28
answered How to politely decline a pull request?
Jan
13
comment Is “White-Board-Coding” inappropriate during interviews?
@JuliaHayward: If you give every applicant the same problem, then of course the response becomes google-able. Not surprising, is it? But again, my answer remains: do not do whiteboard coding on fizzbuzz level in an interview. It just shows that you didn't bother preparing a good and interesting problem. As you have said yourself, there are ways to establish basic programming abilities way before you invite the candidates to your whiteboard.
Jan
13
comment Is “White-Board-Coding” inappropriate during interviews?
@JuliaHayward: Establishing a candidate's basic coding abilities in a pre-interview is a different thing. You don't actually have to invite somebody on site to do that. You can send them a small problem that they can solve. Possibly discuss that solution (or github code) in person. Most imporantly: It's highly unlikely you will find a candidate able to gracefully master the type of problem I suggest, while not being able to solve fizzbuzz type problems. The interview should be used to determine how able the candidate is to deal with the complexity typical of real world problems.
Jan
12
comment Stack and Heap memory in Java
@hagubear: It depends. In some cases the JIT (or even the compiler) is able to avoid allocation (and the overhead it incurs). But unlike in C for example, you are not actually explicitly saying where the value should be allocated.
Jan
8
awarded  Nice Answer
Jan
7
comment Does using == in JavaScript ever make sense?
@EricKing: I disagree. It's not that I like JavaScript. I much prefer to use statically typed languages, where static analysis forces you to ensure the operands have sensible types. But if you make it a design philosophy that your language should be forgiving by automatically coercing things at runtime as needed, you can't do it everywhere except with the == operator. The result is would be unusable. Given certain axiomatic design decision, this is sensible behavior. Dismissing that seems like a perfect solution fallacy.