mattvanhorn

Wow, Upwork comes out looking worse than the asshole who was abusing the system. Wasn't expecting that. Guess the world is just full of assholes and their enablers.

Real programming ended with Mel.

tl;dr: "Conceptual debt" is what Ward Cunningham described as "technical debt". That thing you call "technical debt" is just a combination of bad habits, haste and apathy.

Tell them to subpoena you - then the choice to testify is not yours any more. You'll have to. But you can tell future employers that you were forced, if you'd like to.

I'm terribly saddened by this. It's a great genre bookstore, and although I have a kindle, I still love having dead tree books, especially ones I read for pleasure.

I worked at a place where the VPE would talk about technical debt as a mortgage. Yet they had a culture that abhorred paying down the debt through refactoring, and so it was more like one of those interest-only payment mortgages. They paid higher interest in the form of reduced productivity and speed, and ended up with the same amount of debt as when they started.

I suppose that if you do keep things that small, it could work well to trash and rewrite. Plus it has the benefit of making you consider explicitly what is going/staying.

Personally, I like my tests to be pretty clearly about the behavior of the contract, and not the implementation, which is hard when you require every method have a test.

I'd also be concerned that other team members are reluctant to delete tests - as this is a dysfunction I see often, and try to counteract with varying degrees of success.

I agree with the general approach suggested in the article (in tests, write/assume the code you wish you had).

But one detail ran counter to my personal practice.

I don't believe that "symmetrical" unit tests are a worthy goal. I believe in testing units of behavior, whether or not they correspond to a method/class. Symmetry leads to brittleness. I refactor as much as possible into private methods, but I leave my tests (mostly) alone. I generally try to have a decent set of acceptance tests, too.

Ideally, you specify a lot of behavior about your public API, but the details are handled in small private methods that are free to change without affecting your tests.

I think that Red-Green-Refactor is as much about learning to habitually look for and recognize the refactoring opportunities as it is about being meticulous in reacting to those opportunities.

It's true that nothing forces your to refactor - but I think wanting that is a symptom of treating TDD as a kind of recipe-based prescriptive approach. It is not a reflection of the nature of TDD as a practice or habit.

It's a subtle difference, but important:

A recipe says "do step 3 or your end result will be bad"

A practice says "do step 3 so you get better at doing step 3"

I think far too many people fail to make the distinction between designing an algorithm and designing a program (which implements it).

This is why I have to watch co-workers create dozens of useless error classes and utility functions, and totally ignore YAGNI, before actually taking a single step towards a working program.

If you don't know the algorithm, and haven't figured out the abstractions, then just slinging some implementation code is the easiest (and laziest) thing you can do. It's basically a way of avoiding having the necessary conversations. In this case, the question that needed answering before beginning TDD was: "How does one efficiently solve a sudoku puzzle (as opposed to just manipulating one)"

Only TDD the code that you don't want to waste time debugging later. Skip the parts where you have proven no edge cases exist. Skip the parts you are sure will never, ever, need to be changed for any reason whatsoever.

I still do a lot of decent work on a non-unibody MBP from 2008, so I think a 2009 model would still have some utility, but I would consider the price carefully - it might be more worth it to buy a newer MB air or something, knowing you'll get a few more years out of it.

I don't find implementing the tests very difficult at all - but I am comfortable with regular expressions, and ruby.

It's no more burden to write step definitions than it is to write RSpec directly. I use SOLID OOP to write my tests, most of the logic lives in regular old methods, and my steps look like:

  Then 'the current subscription payment date should be tomorrow' do
    verify_next_payment_date(Date.today + 1)
  end

Since I start with the Gherkin file, I type less than 10 keystrokes to make the step.