Last weekend I set about mining all the links from Alvin Ashcraft's Morning Dew excellent link blog site which has been documenting .Net goings on since 2007.
In the back of my mind was the idea of applying some machine learning techniques to automatically generate blog article recommendations using the labelled links as training data. Each link in Alvin's site has a date, category, title and author.
I took 2 passes:
- programmatically find all the post urls
- parse the HTML posts using the HTML Agility pack to extract labelled links
I now have a CSV file with over 80K links – that’s a lot of reading from Alvin.
It struck accord with me and quite a lot of the people I shared it with on Twitter:
I also posted some quotes from the article including:
This is one of the responses:
It reminded me of a recent vociferous exchange I'd seen on Twitter:
Judging by those comments as I’m not using Resharper when writing C# I must be "silly", "stupid" and "retarded".
Seriously though, this is not the first heated discussion around Resharper, and name calling doesn't feel like a grown up way to have a discussion, wouldn't it be better if we could just agree to disagree and live and let live.
So why am I not using Resharper?
The short answer is that I want to like Resharper and I've tried it a number of times, but each time I've found it overly intrusive in my workflows and ended up uninstalling it after a few days. If Resharper works for you though, honestly I'm happy for you. Even though I don't use Resharper, it doesn't mean I don't use or like tools, I use TestDriven.Net to run my unit tests, REPLs for getting quick feedback and I've been happily using the built-in basic refactoring tools in Visual Studio since they were introduced way back in 2005.
Back in 1999 Martin Fowler wrote about the idea of code smells in his Refactoring book. I consider finding myself typing the same thing over and over or jumping back and forth through the source code frequently, both as good forms of discovery of code smell. The former of code duplication, the later of high coupling. From bitter experience, instead of making code duplication easier through code generation, and code coupling easier through navigation tools, I want to get strong early signals of the problem and tackle it head-on before it gets out-of-control. That said there are times when both code generation and navigation tools can be handy too, and yet others when they feel more like I'm taping over gaping wounds with temporary bandages.
Step away from the tools
Sometimes when I’m stuck in the debugger for a while, I begin to feel like a gambler who’s trying to gamble his way out by doubling down instead of cutting their losses and walking away. Sometimes the best way to solve a problem is to step back from it and take some time to think about it (picture via Edwin Brady):
And sometimes the solution isn't easily found in the code or the tool, but rather from stepping back and taking time to discuss it with your co-workers.