Ah, but this problem is solved by the code review/pull request process! I see the changes that you make to code and to tests at the same time. If your changes aren't tested I don't merge or you have to have a good reason for why they aren't being tested.

Don't buy it (Edit: Or at least I don't think this is that big of a benefit of TDD unless you're generally a poor developer anyway). My general flow is: Build something small, write tests to test the thing I built, test the thing I built in the app. It doesn't take long doing this to realize how you need to write code for easy testing. Not to mention the vast majority of things that are needed for easy testing are just standard good ol' development practices.

Funnily enough I don't consider this a knock on TDD because it seems like its just a knock on automated testing in general.

I have no issues with this. Imo you are still testing so early on that you'll get the benefits I mentioned. I know some purists will tell you bad dog, but yeah, I don't buy it either.



It wasn't meant as a knock on TDD per se. Just pointing that the nirvana you'll read about in TDD text books requires a good tooling ecosystem, and a lot familiarity with it. People underplay how hard that setup is imo. Although I think this point applies beyond just TDD.

Nice, hope it turns out to be an awesome job.

Regarding TDD...I actually think it slows me down at times and breaks my thought process. I think I'll replace it with sitting down with a piece of paper and scribbling a bunch of ideas on it before writing any piece of code then building a prototype then trying to think about ways of breaking the code on the back of said paper and writing the appropriate tests and then thinking about general improvements.

Or maybe 3 minutes of meditation before writing any code and 3 minutes after every checkin.

clowntable, i agree TDD is counterproductive during early exploratory phases. It should only come in after your idea has crystallized somewhat.

My favorite part of TDD is that we have like 5 different frameworks, a ton of legacy code that wasn't TDD and is nearly impossible to test, at least one suite of tests which are actually integration tests pretending that they aren't, and it seems like they are always broken, so every time I check in I can look forward to getting 17 emails across the next 1.5 days from the continuous integration server telling me that the unit tests are failing

also I hate the term "code smells"

hatey hate rays

all of my this

I can understand the concept of code smells, but in practice I imagine the term gets used to mean "I don't like this but I don't know why so rewrite it."

I just don't like the name.

also python eggs sound disgusting

yeah there's no problem with the idea that certain ways of doing things are normally a bad idea.

I just have an irrational hatred for unnecessary jargonification and that term is particularly irksome

Also on the list is "Representational State Transfer", the state-less web architecture. Solid name choice. ceci n'est pas une pipe

if "code smell" is "unnecessary jargonification", please tell me what the unjargoned form is.

i'm with you on code smells, and on the general principle.

i think as a rule mathematicians and computer scientists name things about as well as they dress and cut their hair.

I said irrational didn't I?

unjargonified is just "maybe you shouldn't do X because <reasons why X is a bad idea unless you really mean it>"

you're right, that's a way better name than "code smell". completely unnecessary to coin a term to describe that concept when it's so clear as stated.

let's not forget about dependency injection. That's also on my list

"Code smells" is great as a proxy for a standard well accepted argument between two good developers.

"Code smells" is ****ing horrible when its used as a proxy for having to make a real argument to defend a decision that doesn't make any sense.

So like most jargon its generally fine when used correctly but a bunch of morons quickly learn to misuse it.

Edit: I never really understood why people often made such a big deal about dependency injection until I actually learned what it was.

I move that we amend the term to contain at least one plausible reference to the goddamn Batman.

Then I will accept it

Batman makes everything better.

From henceforth, each instance of a generally poor programming practice shall be referred to as a "Code Harvey"

i didn't take well-named as saying that the concept had no use. it obviously does. i thought he was purely critiquing the phrase, since it's just sort of gross and somehow dorky.

I don't feel that way about dependency injection. I actually kind of like that one, although it may be overly cryptic.

I never understand anything like dependency injection until I have to work with it first hand. And then when I do get it, I always say "oh why can't you just explain it like X?"

I just remember thinking that it seemed like a lot of work and I couldn't really figure out a lot of the benefits (partly because I didn't really think about it a lot and partly because we didn't test nearly well enough). And then I started writing tests and pulling out code that built objects because they were hard to mock...

What's not hard to mock?

Two days down! I guess there is about 50ish to go.

The guy is really smart and very patient, and he can explain things really well, whereas I have difficulty explaining my own name.

He is an Engineer. He is the type that likes to draw graphs, draw frames, and really think details through. My style is more or less like a drunken walk, where I have an idea and I'll slop up something to see what it looks like and iterate. Right now, we are just mocking up some web pages and this is where I get a little lost. I draw something and it looks like a turd landed on the paper and I just say screw it and build up some HTML or something so I can actually see what something looks like. After a few hours of discussing things and watching him make drawings, I just bust open VS and start hacking. This created an odd issue which I don't feel like rehashing here, but it's really not what you'd intuit.

I probably broke Visual Studio 20 times in the past few days. My brain doesn't really switch out of Emacs mode to well. Seriously, VS feels like I'm trying to program with both of my index fingers broken. I ended up looking up the built-in hot-keys to see if I was missing anything. Nope. I already know all the hot-keys for Word and there isn't anything new here.

Had to sign and NDA so I can't really talk much about it, except that it is a .NET project and I'm having a total blast with it. It really is more fun that I had expected so far.

Use emacs bindings in visual studio?

Glad it's going so well! .NET is great to work in. I understand why VS might be awkward at first, but I'm sure it will grow on you, it's great software.