Top all-time · #1721
Ravi Mohan
Personal blog · ravimohan.blogspot.comprogrammingcareer
Ravi Mohan writes One Man Hacking, a personal blog at ravimohan.blogspot.com about programming and career. Since 2007, 45 different Hacker News readers have linked it 55 times, most often “Ask HN: How do you solve hard problems if you can't make incremental progress?”. The last post was in 2008, but the archive is still widely read.
Ravi Mohan's Blog
Most-linked posts?
- Ask HN: How do you solve hard problems if you can't make incremental progress?34 people · 39 mentions · first linked 2007-07-19
- But Martin, Enterprise Software IS Boring3 people · 3 mentions · first linked 2009-02-23
- /2007/04/learning-from-sudoku-solvers.html2 people · 2 mentions · first linked 2021-08-23
- /2007/04/learning-from-sudoku-solvers.html?m=12 people · 2 mentions · first linked 2016-09-12
- Ratcatchers and Engineers2 people · 2 mentions · first linked 2008-01-24
What Hacker News says?
When I was doing programming competitions, the most valuable advice I was given was to print out the problem set and then walk away from the computer for the first hour of the competition. This skill was even more important for the four-people-one-computer challenges, where you have to be able to design, implement, test, and debug your code without the crutch of a computer to be productive. This advice I consider to…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “What eight years of side projects have taught me (2019)”Submitted Ask HN: How do you solve hard problems if you can't make incremental progress? as a story · 65 points
HN discussion" It should also solve the "don't know how to start" problem, because it de-emphasizes planning and design in favor of just jumping in; you write the tests, and then you do the bare minimum to make them pass" It doesn't SOLVE this problem. It only pushes it in time, making it actually worse, because you're wasting time on stupid tests instead of actively researching a solution. No amount of tests is going to help yo…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “An External Replication on the Effects of Test-driven Development [pdf]”Submitted Learning from Sudoku Solvers (2007) as a story · 15 points
HN discussionThe goal of the study was not to measure if testing is valuable at all, but to measure if there is any difference between TDD and TLD. I think no-one questions the value of testing per se. As for your points why TLD is theoretically worse: 1. "in TLD tests just don't get written" - this is a dual argument to "in TDD the code just doesn't get refactored". After tests are green, there is no motivation to do so and it…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “An External Replication on the Effects of Test-driven Development [pdf]”Submitted But Martin, Enterprise Software IS Boring as a story · 5 points
HN discussionIs this actually a new phenomena? I remember when I started programming c. 2000, the big-name programming gurus were folks like Kent Beck, Ward Cunningham, Uncle Bob, Ron Jeffries, Dave Thomas, Joel Spolsky, Jeff Atwood, Martin Fowler, et al. While some of them mostly knew their stuff, some were outright hacks (Peter Norvig's vs. Ron Jeffries' attempts to create a sudoku solver is one of my favorite examples [1]). M…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Why Is Front-End Development So Unstable?”Submitted Sudoku solvers vs TDD vs Peter Norvig as a story · 4 points
HN discussionBeing 10× more productive doesn't always feel like being 10× more productive. It can mean spending two days on a project which, seven years ago, you would have spent five days planning out, two days implementing, and eight days debugging; or you would have spent five days planning out, eight days just beginning to implement it the wrong way before someone pointed out that there was a library that already did what yo…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Programming: Doing it more vs. doing it better”Submitted Learning from Sudoku Solvers (2007) as a story · 3 points
HN discussionI hope you don't mean to imply that TDD haters are not real computer scientists. http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
Comment linking /2007/04/learning-from-sudoku-solvers.html?m=1
on “AlphaCode as a dog speaking mediocre English”Submitted Ratcatchers and Engineers as a story · 3 points
HN discussion“OOP” is one of those terms (like most terms) that have a narrow meaning and a broad meaning, and either proponents or detractors can use one of them in arguments: • OOP, narrow sense (emphasis on “object”): data-with-associated-functions, encapsulation, etc. • OOP, broad sense (emphasis on “oriented”): organizing your program around objects that model the nouns in the problem domain, “everything is an object”. A (s…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Pretending OOP Never Happened”Submitted Tech Company Caste Systems as a story · 2 points
HN discussionOk agentic Ron Jeffries https://ravimohan.blogspot.com/2007/04/learning-from-sudoku-...
Comment linking /2007/04/learning-from-sudoku-solvers.html?m=1
on “The Normalization of Inexplicable Failures”Submitted The Implicit Assembly Line (2008) as a story · 2 points
HN discussionI know I'm late to the party, but why isn't everyone mentioning Ron Jeffries infamous TDD Sudoku as a comparison? A lot of the links are dead these days, I'm afraid, but back in 2007 this was the kind of thing that everyone on HN knew about! http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “The Myth of the Myth of the 10x Programmer”Submitted Ruby, Lisp, Why a Lexus is Not An Acceptable Ferrari as a story · 2 points
HN discussionAre you surprised by that? The 10x longer statement doesn't surprise me at all. If you ask someone, "Please implement a Java class that has the following methods and behaves like this" you might expect any competent programmer to finish within ~3x of each other. But given some more nebulous task, where architectural decisions must be made and serious research and testing needs to be done, it's not surprising at all.…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “An apology to readers of Test-Driven iOS Development”Submitted Ratcatchers and Engineers as a story · 2 points
HN discussionContrast this with the TDD approach: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Solving Every Sudoku Puzzle (2006)”Submitted Learning from Sudoku Solvers (2007) as a story · 1 points
HN discussionIt's the same problem test driven development faces. Some things can be inferred from a list of test cases (exam answers). But some things require deeper insight that no amount of test cases can provide without spending time actually thinking about the big picture. http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Father-son duo helped techies ‘hack exams’, earn top scores for big payday”Submitted Scribes and Programmers [2007] as a story · 1 points
HN discussionI learned testing on the job. That said, I would never trust a learning channel like the one you describe. I've learned the hard way that people who consider themselves experts on unit testing tend to believe that more tests are always better, and have no idea of the impact of excessive unit tests on a codebase. So a channel like the one you describe is going to attract people whose opinions I'm suspicious of. Inste…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Don’t mock what you don’t own”Submitted A Rogue Researcher's Route Map as a story · 1 points
HN discussionI'd disagree with this assessment. In my own experience, I've found that competitive programming is useful in teaching a few skills. However, the apparent point of competitive programming--building up a good repertoire of advanced algorithms and data structures--is pretty close to useless. In my professional career, the most complex algorithm I've ever had to code myself is ... union-find (on like two occasions), wi…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Competitive programming is useless”If you haven't, you really need to see this post.[1] Starting simple and writing a test driven algorithm is not necessarily bad. However, realize that you are really just turning the act of finding the optimum solution into a search space where you have to assume mostly forward progress at all times. Not a safe assumption. At all. And, because I love the solution, here is a link to my sudoku solver.[2] I will confes…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Stanford study shows success of different programming styles in CS class”This is the same guy from the failed sudoku solver... http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... Maybe he had also tried TDD "wrong"? Or maybe he's just another snake oil salesman, like "uncle" Bob?
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “We Tried Baseball and It Didn't Work (2006)”No amount of tests can help you if don't know how to solve the problem. And the better you know how to solve the problem the less tests you really need. ;) Old, but quite relevant: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... Some sane amount of testing is good. However, I'm not very convinced writing tests first is a good idea. I saw a few programmers practicing this and when writing code they of…
Comment linking /2007/04/learning-from-sudoku-solvers.html
on “Tests Are Overhyped”
