Reputation
2,924
Top tag
Next privilege 3,000 Rep.
Cast close & reopen votes
Badges
14 30
Newest
 Good Answer
Impact
~143k people reached

Dec
5
comment Evaluating a product owner
@maple_shaft Makes sense. Why was this question closed as off-topic, then? If evaluating a product owner is part of an Agile process, then the question is very much on-topic!
Dec
5
comment KISS principle applied to programming language design?
Really? Never heard "simple stupid" as an adjective. In any case, the version from the Jargon file changes the meaning: it's not about "average developers" anymore. It simply telling you "don't be stupid and don't overcomplicate things" :)
Dec
5
comment KISS principle applied to programming language design?
You misquoted the principle. It's not "keep it simple stupid", it's "keep it simple, stupid". The comma is important because it means the "stupid" is an expletive directed at you, the reader.
Dec
5
comment Evaluating a product owner
What would be the purpose of evaluating a product owner?
Dec
3
comment Test driven vs Business requirements constant changing
I've never met a client who "bought" Agile who agreed not to change requirements but didn't fight hard to make exceptions in every single sprint... Every single one of them agrees in theory and disagrees in practice. (Yeah, I know this is just anecdotal evidence)
Dec
2
comment Tips or techniques to use when you don't know how to code something?
Oh, test cases are definitely part of problem-solving. TDD is not just about test cases, though. I'm disagreeing with TDD, not with testing! I'm disagreeing with the design part of TDD. (Though now I agree with you maybe the algorithm scenario doesn't apply to the OP's situation)
Dec
2
comment Tips or techniques to use when you don't know how to code something?
Agreed that "blindly" is the most likely culprit. But if Ron Jeffries, an expert on TDD and cofounder of XP, cannot do it right, then who can? :P More seriously, I think the other answers to this question are more relevant than TDD: breaking the problem in smaller chunks and reasoning about them, writing pseudocode, writing a proof on paper, etc, are all more important than test-driven design and "test first". When the problem is algorithmic in nature and nontrivial, TDD won't help you (as much). TDD will help you when writing CRUDs, though.
Dec
2
comment Tips or techniques to use when you don't know how to code something?
Here is a counterargument: TDD is not a good way to solve something you are unfamiliar with. See the infamous How to not solve a Sudoku where TDD "expert" Ron Jeffries embarrassingly fails to provide a solution while blindly using TDD, and Peter Norvig solves it using good old fashioned "knowing about the subject matter" and "thinking about it". You cannot generalize an algorithmic solution out of TDD cases, unless it is trivial or you already know your goal in advance.
Dec
1
comment Which is more maintainable — boolean assignment via if/else or boolean expression?
+1 for "Another reason to prefer the second form is that you can declare c and assign it in a single statement"
Dec
1
comment Which is more maintainable — boolean assignment via if/else or boolean expression?
Writing a clean boolean expression is not a clever trick!
Nov
30
comment Which is more maintainable — boolean assignment via if/else or boolean expression?
The first form had at least 1 bug which needed to be corrected, hidden in its verbosity. Second form was simple and to the point, and had no bug. I rest my case. In any case, the main purpose was not to type less characters! And this question wasn't about performance at all, which is irrelevant in this case.
Nov
30
comment Which is more maintainable — boolean assignment via if/else or boolean expression?
What!? c = (a == b); is not error-prone. First form in the original question is way more error prone, as demonstrated by the OP itself having to edit his/her question to fix bugs!
Nov
30
comment Which is more maintainable — boolean assignment via if/else or boolean expression?
Wow, do C# devs really consider the first form acceptable? This... seriously reduces my trust in them. In my experience, use of the first form heavily hints at a complete misunderstanding of boolean expressions.
Nov
28
comment Is it useful to unit test methods where the only logic is guards?
You are not making "more work" for the maintainers. If they change logic, they must change the corresponding unit tests. That's how it works. I don't see your cons: if your unit test didn't require changing, then it wouldn't be testing anything, would it? You might as well question whether unit testing is useful at all.
Nov
25
comment Is modern C++ replacing C#? Is Microsoft pushing developers to adopt C++?
@rotman Please do not reply to other people's answers in your own answer. Answers should only address the original question :)
Nov
22
comment Is there an excuse for short variable names?
My guess is that longer names make sense in OOP because meaning is derived from them, whereas in FP, where generality and abstraction are much higher, succinctness is more valued.
Nov
22
comment Is there an excuse for short variable names?
Not an answer because I quite can't understand it yet, but in Haskell (and FP in general, I guess) the consensus seems to be to write 1 or 2-character variable names. (this is unrelated to common Physics or Maths abreviations). I'm still not used to it, but it seems to be related to the extreme generality FP programmers strive for. So lists are usually named "xs", with a particular element named "x"; longer names seem to be frowned upon. And yes, industrial strength software IS written with Haskell/FP.
Nov
20
comment C++ job interview questions?
You should probably be honest with the interviewer and explain that you are proficient with C, but have little experience with C++.
Nov
20
revised What's the benefit of the Nothing constructor in Haskell?
added 3 characters in body
Nov
20
answered What's the benefit of the Nothing constructor in Haskell?