It’s in the Framework, Dummy!
25 April 2008
No one who knows me would describe me as humble. I guess if everyone thinks I’m not humble, maybe I’m not, I don’t know.
One thing I do approach with humility is my ability as a programmer. It took some concentration to “get” the fancy algorithms in university; I’d always try to solve the problem with brute force and “move up” as needed. I still do. I don’t think that’s wrong, either; worse is better. I practice TDD when I’m writing something that matters. I also remind myself that the first question isn’t “How do I do this?”, but “How has everyone done this before?”
Judging by the code I’ve read from my colleagues and online, a lot of people don’t share this perspective. They blindly assume that they have to solve every programming problem that crops up and that they can solve every problem better than everyone else who programmed before them ever. I doubt most programmers think that way but the results in the code could support that notion.
There are lots and lots of developers out there, all with a lot of the same types of problems to solve; some times - I’d say rarely - you need to revisit the problem yourself, but chances are, you can just use what other people have done. You can see this trend with the technologies and languages in use today verses, say 50 years ago. There’s a definite progression from machine code, to assembly, to procedural, to OO, to runtimes and frameworks. The code in J2EE or .NET or Python or Rails embodies thousands of little problems already solved for you.
To be a good programmer, therefore, one must get pretty good at searching the docs of your particular framework; learn to read source code; and always remember that someone already solved your problem. Even Isaac Newton didn’t do it alone. Being a humble programmer allows you to progress passed solved problems.
Before I end this post, a few examples from .NET:
- File paths are something everyone has to deal with if you’re writing a desktop app. You have a directory path and a file name and you need to concatenate the two to work with the file on disk. You could write
string path = dirPath + fileName;
but that assumes that dirPath ends with ‘\’ on Windows (let’s not consider Mono right now). So, now we have to check to see if dirPath ends with ‘\’. Or, you could just use Path.Combine! It’s been in the framework since 1.0! That Path class has all kinds of good stuff on it. Use it! Stop reinventing the wheel.
- Here’s one that I didn’t know about until a few weeks ago: Title case for a string involves capitalizing the first letter in every word. I’ll admit I’ve written functions in production scenarios, but I didn’t have to, and now I never will again because of the TextInfo.ToTitleCase method. TextInfo hangs off of CultureInfo, and it’s in the System.Globalization. I bet your naive implementation wouldn’t have considered internationalization. Microsoft has to deal with that a lot, they’re probably really good at it. Solve your problem, not one that Microsoft already has; it’s in the framework!
Here’s a rule I usually follow: if there is a requirement to do something, always, always, always, check the Google, or your favourite search engine to see what others have done.
Have you got any methods or classes that are in the framework but nobody uses?
Tags: .NET
This entry is filed under .NET, Rants.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

The Missing .NET #4: Cue Banner in WPF (I mean, Watermark in WPF) | a geek trapped in a cool guy’s body Says:
6 June 2008 at 0706[...] Top of the page Related Posts The Missing .NET #3: An AutoComplete TextBox in WPF, Part 4 - WPF FlourishesThe Missing .NET #3: An AutoComplete TextBox in WPF, Part 3 - Control TemplatesThe Missing .NET #3: An AutoComplete TextBox in WPF, Part 2 - Making it reusableThe Missing .NET #3: An AutoComplete TextBox in WPF, Part 1 - A rough first draftIt’s in the Framework, Dummy! [...]
Dominic Says:
6 November 2008 at 0622TextInfo.ToTitleCase does almost NEVER work in my applications. Since the beginning of time I’ve been using my own more reliable function:
private string CorrectCase(string UpperCase)
{
string IterateString = UpperCase.ToLower();
StringBuilder OutputString = new StringBuilder(IterateString[0].ToString().ToUpper());
for (int i=1;i<IterateString.Length;i++)
{
OutputString.Append((Char.IsWhiteSpace(IterateString, i-1)) ?IterateString[i].ToString().ToUpper():IterateString[i].ToString().ToLower());
}
return OutputString.ToString();
}
Toby Says:
18 December 2008 at 0841This makes so much sense for all Dot.NET developers, however, developers coming from C++ or even VB6 (yuck) are accustomed to thinking totally different. Boost never took off, but imo, it was the best thing that ever happend to C++.
Java programmers will know this, but most java “programmers” are people who came into contact with java in an academic sense, and thus couldn’t ever program anything useful. those few java programmers which are actually good at java produce some amazing stuff.
.NET is unique because you can go both ways: program small programs without much knowledge of the framework, or know the framework and take your program to the next level. java has a steap learning curve, some shitty IDEs and, ftw, bytecode?.
Learning by doing is the most important thing in the IT industry, .NET enables this, many other languages don’t.
Which brings me back to my orginal point: many .NET developers are still “learning” .NET themselves, in time, people will use the framework more and more.