Peter Evjan's blog

The debate of IDE or no IDE usually boils down to static or dynamic, or to helpful or getting things done. Right now, I tend to agree with both sides.

I work as a .NET programmer using Visual Studio 2010 by day, but during evenings and weekends I do mostly Ruby/Python/JavaScript in TextMate on my beat-up old white MacBook. The Mac is so slow it freezes for a second or two when I scroll to the next page in a PDF, so a heavy IDE is out of the question. Since I spend a lot more time at my day job than I do at spare time hacking, I am much more accustomed to the IDE way.

Speed and crutches

The major points are speed and editor help. Visual Studio is slow but helps you out a bit more (refactorings are soooooo easy), TextMate is fast but doesn't reach out its hand when you are making mistakes. So when using a text editor I find myself spending a lot more time duckduckgoing (yes, I verbalized "DuckDuckGo", so what? (yes, I verbalized "verb", so what?)), reading through documentation or correcting stupid spelling errors.

Example: last night I mistakenly typed "." instead of "_" in a method call, which gave me absurd error messages to the point where I felt compelled to cook dinner instead. I would have discovered and corrected this in a matter of seconds in Visual Studio. But Visual Studio is huge and requires a performant machine, otherwise you'll spend a lot of time swearing and waiting.

Watching Zed Shaw code confirms my thoughts. He is an experienced text editor programmer and his workflow is much more chopped up than mine in Visual Studio. There is a lot more pausing because you don't remember a method name and have to go to the documentation, which interrupts your current thought process ("what is a customer, really?") and replaces it with another one ("what arguments are needed?"). I don't know if this is good or bad, but it is a difference that I still am adjusting to.

Not only am I less experienced with TextMate than with Visual Studio, I am also a bit of a special case, since my internet connection is very unstable. I sometimes experience weeks without online access in my home. This makes duckduckgoing around a huge bottleneck. I've downloaded books and downloaded API documentation and guides with wget, but sometimes that documentation is not enough and I get stuck on very trivial problems for a long period of time.

So, Visual Studio makes coding more fluent, but seeing your work requires waiting. TextMate makes coding less fluent, but you see the results of your work much faster. Which is better?

Messy code

There's the argument that people using IDEs as crutches make messy code, since they don't have to think as hard about the structure. I don't know whether this is true or not, but see Avdi's post on the messiness of legacy Rails applications compared to static ones. I'm pretty sure the apps he mentions were not written in Eclipse.

A lot of very smart people prefer to work without the crutches of IDEs. Maybe the case is that young programmers, that don't yet have the complex thought patterns that come with experience, make complete messes without an IDE, whereas more experienced programmers are better off without them.

Conclusion

I make a bit of an unfair comparison, since I am much more accustomed to Visual Studio. But I like both, I use a gargantuan IDE for static code and a lightweight text editor for more dynamic code. Just like everybody else. There is no winner in this war, there are only different tools for different jobs.

This blog post was written in TextMate, not Visual Studio. Go on, comment about how that means something.

At ExplainerDC we usually watch a video or do some code sparring on Friday afternoons. Last week I showed the other developers the introductory episode of Uncle Bob's series Clean Coders. Today we watched episode 2, "Names++", and afterwards we had a short discussion about the topic. I tried to transcribe it as we went along:

Ibrahim: I thought it was very informative and it reminded me of things taught in school. I can't wait to see the next episode.
Kwabena: Really, you were taught this stuff in school?
Ibrahim: Yes, at NIIT.
Francis: I used to think that code was just for myself, so any name was a good name. Now I understand why good names are important for communication with other people.
Me: Yes, but it can also be important for yourself. Like if you have a CSS class called "VideoHeader" that you use in the header on both the image and video page, and you then go back to it two weeks later and forget that the class is used on both pages and make a change, then you get into trouble.
Kwabena: This video should be good for somebody who still is in school, it is important to learn this early. Also, the material was not as advanced as I thought it would be.
Me: I found the reversed scope rules confusing, how public functions should have short names and private longer, but for variables it was vice versa.
Raymond: It is because few verbs are long, they are often short but expressive.
Ibrahim: I found that a bit confusing too. Shouldn't it just be one pattern for naming? That would make it easier.
Me: And I also think it is more important that public functions are easy to understand than private.
Ibrahim: I like the thought that we need to challenge ourselves and look at what our code looks like. It's been a long time since I was taught by such a worthy lecturer, it was a style of teaching that really keeps you awake.
Me: What did you think of the astronomy part in the beginning?
Kwabena: I think it was related to how the egyptians didn't have good enough tools and therefore made mistakes. Today we have good tools, like good compilers and IDEs that mean we don't have to use type prefixes and so on.
Sylvia: The part that I liked the most was that code should read like beatiful prose.
Kwabena: But I think that abbreviations are good, GetLName is as understandable as GetLastName but makes me program faster.
Me: I think that can be tolerated if we are sure that everybody will understand them, like very common abbreviations in the business. But what will they look like to new developers in the team?

Then we got into an architecture discussion. We will most likely watch episode 3, "Functions", next Friday.

Good: "How do I access the file system? Aha, good. Next step!"

Bad: "How do I access the file system AND mock out the file system for my tests? Wow, a feta cheese salad would be nice by now! Is Matlock on yet?"

The flow. I experience that whenever I really enjoy doing something. It is very important for making just about anything a joy. Therefore, all things that break up the flow should be eliminated. Sometimes they can't, but it should nevertheless be the vision. TDD messes up my flow when I am taking a plunge into the world of a new programming language.

There are so many things that you need to take into account when learning a language. Not only the syntax, but the frameworks, the runtime, the environments, databases, shell/visual tools, idioms, package/module structure and so on. TDD on top of that means you need to understand more advanced architecture, mocking, TDD tools (like how do I run the tests?), etc. Important things, but they multiply the complexity level, and for flow you should ideally have only one level of complexity at any given moment.

TDD gives me a flow when I am familiar with how the general way of doing things and how to get around in the programming language, IDE, editor, infrastructure etc. But when I am new to all that, I really don't need more levels of complexity which might put me off the whole thing altogether.

I've so far encountered one exception to this: learning Ruby while picking up Rails. Since testing is so deeply engrained in that experience, doing TDD and learning at the same time becomes a joy.

The problem for me is that whenever I abandon TDD and just hack, I feel filthy. I usually don't add on tests after and manual testing is dirty testing. But sometimes you need to get off your high quality horse.

So tonight when my wife has fallen asleep, I'll pour a glass of red wine, put on a Mogwai record and just hack. I will need a shower afterwards, but at least there will be Flow (and not just of water).