Welcome to our continuing series of Code Project interviews in which we talk to developers about their backgrounds, projects, interests and pet peeves. In this installment we talk to Code Project co-founder and herder of hamsters, Chris Maunder.
Chris joined The Code Project… well, at the very beginning. He dodges, he weaves, and he never gets enough sleep. He is kind to small animals. And here’s a bit more you don’t know about him already…
Who are you?
Chris Maunder, Toronto, Canada. Lead Janitor, Bug Fixer, Chief Internal Trouble Maker, Defender of the Orange, Community Punching Bag, Occasional Author, Assistant SysAdmin, Signer of Cheques, Dishwasher, and Industry Liaison. Also: Co-founder, The Code Project.
What do you do?
Over the years I’ve worked on a few interesting projects on partitioning spatial data into Digital Elevation Models along with researching and implementing rainfall, runoff and erosion models on these DEMs, MFC UI controls, certain, ahem, data processing applications for the Defence Signals Directorate in Australia, a failed CE app that would route you through any transit system in the world (failed because it turns out the idea had been done a year previously) and then a couple of web sites.
I also worked on The Ultimate Toolbox when it was a commercial product owned by Dundas Software, and a few Windows CE apps that never saw the light of day.
My latest project is CodeProject.com and this takes up my days, weeks and any time in between. It’s a 24hr job, starting and ending with email, but running the entire gamut of community interaction (AKA hanging out in the Lounge wasting time) architecting, cranking code, code reviews, deployments, sysadmin duties, servers and hardware, and DB design and administration. Some editorial, a little graphics, legal, financial, looking after staff issues, talking to clients and general monitoring of systems and the community.
My team and I are also working on Lake Quincy Media, our media company that serves CodeProject and hundreds of other sites under its umbrella.
Basically, I do everything including cleaning out the dishwasher when it’s full. It’s a fantastic job. I’d highly recommend it.
What is your development environment?
I work with C# and the .NET Framework 4, ASP.NET Web Forms and MVC, Visual Studio 2010, SQL Server 2008 R2, Notepad2, and Expresso. Nunit for testing, StyleCop for styling, TeamCity and Nant for build/testing, and occasionally Expression Web 4 when Visual Studio can’t behave. We also use Chirpy for JavaScript compression, CSS .less and T4 files within Visual Studio. For our search server we’re using Lucene. For our mail servers we use Linux.
CodeProject.com was originally written using ASP and VBScript. The current .NET version was started around 2003 and so there is a ton of legacy code, most notably a solid foundation in Web Forms using the old onion architecture, instead of using SOLID principles and MVC that the cool kids use these days.
We are, however, constantly refactoring and moving to the MVP pattern and implementing IoC where it’s missing to enable us to move to MVC less painfully and improve our automated testing as well as caching.
Parallelism is something I have a long interest in from my work on CRAY computers. While this is something I get to play with on some of our standalone applications such as our mailout system, ASP.NET by its nature doesn’t provide huge opportunities for this.
The technologies that most interest me at the moment are anything that makes our back-end database system less critical. Caching, obviously, but also SQL clustering from the view of load balancing rather than failover clustering. We spent an inordinate amount of resources in developing an extremely slick system to allow standard installs of SQL Server to act as a load-balanced cluster, but in the end the cost of building and maintaining the system was more than the cost of simply buying a bigger, faster machine, and this trend continues.
We also arm-wrestled SQL Server into providing useful full-text indexes for technical content weighted by member ratings that returned excellent results for articles, but not the speed or the flexibility we needed for messages, news items, catalog items and so on. We ripped it all out and moved to Lucene and this has not only lowered our database requirements, but also provided the opportunity to shift some queries (such as related articles) from SQL Server onto Lucene. These NoSQL-style technologies are providing great benefits.
I also have a deep need to understand our network topology, which is something I swore I would never do. Up until 6 months ago we were still relying on Windows Load Balancing as our method of clustering web servers, but with the move to hardware load balancers and VLANs we’ve gained efficiencies and flexibility that’s made a noticeable difference. Window Server admin, DNS, SQL setup and admin, SQL Failover clustering, and anything to do with IIS are all things that now have a certain level of interest to me. I either know them or our monitoring guys call me at 2AM to tell me the search server is asleep.
A vested interest does wonders for your ability to master a technology.
What is your coding pet peeve?
Currently (because it changes with the seasons) using var where an int is more appropriate. For example…
var value = GetIntValue();
instead of…
int value = GetIntValue();
It drives me insane.
My second great peeve is not providing an explanation in your code as to what you are doing. That’s right: comments. I have had many discussions on this topic with Steve Smith and while we acknowledge many of each other’s points, it usually comes down to “it depends,” to which I answer “when do you know when it depends,” and so always ask that code is commented.
Four main situations, in my book, call for comments.
-
You’re coding something complex, unintuitive, highly optimised, a work-around or something that the code itself cannot explain.
-
You are working with a team that didn’t read thesauri during recess at school.
-
You use parameters and return values.
-
You are writing code that is non-trivial over a period of time.
The first one is obvious and is just the nature of the beast. An in-code (i.e. inside a method) comment should be a warning sign that something is amiss, or that you need to be aware that something a little non-obvious is going on. Codebases can be huge, and in reviewing them it’s easy to fall into a trance as you read the code. An in-code comment should wake you up, but they should not be done for the sake of having a comment. In that I agree with Steve.
The second situation is the most dangerous. It’s not too painful to write your class, properties and methods in a way that each name is self-describing and obvious. Assuming, that is, you don’t mind extremely long names:
GetItemGetItemByNameGetItemByNameFromCacheButNonFromDatabaseIfNotExistingInCache
Yes, a contrived example but it illustrates a point: unless you and your team are extremely good with thinking up names, and have a religious adherence to extremely well-defined naming standards, names will slip and you will have someone, somewhere, make an assumption about what a function does. Maybe they assume “Create” means “Create on disk” when the author meant “Create in memory.” Small errors like this can be a nightmare. In theory they are totally avoidable by correct naming.
In theory there is no difference between practice and theory. In practice there is.
The third situation is a little facetious, but my point here is that the name of a method does not convey what the arguments represent, or what may happen if invalid (or no) values are provided. Again, naming can help in most cases but that “most” is the killer.
The fourth point is that you may write perfectly named methods and objects, but then, if you have a system that does something non-trivial, your code will only ever tell you one thing: what it does. It never answers the actual question, which is: why.
So this is why not commenting, really, is a pet peeve. I look at code, I can see what it does, but I don’t know why. I don’t know why I would use one method instead of another, and I don’t know what the purpose of that other object is. Why have it?
The comments I like to see are the brief XML summary comments that describe what an object does in a way that answers the “why,” as well as summary comments on the public methods for those using the public API of a class. There will always be trivial comments, but I prefer to live with the evil of trivial comments than have a developer ask themselves “Do I explain the purpose of this method and it’s parameters, or is it obvious enough that I can knock off early and go home.”
Consistency is the most important thing in a codebase and I strongly feel that, as long as the correctness of comments is ensured via code reviews (comments are still code), the overhead is paid for by the clarity brought in those cases where a perfect name or a seemingly justified assumption break down.
Assuming that writing a piece of code with a certain name will make things clear is as misguided an assumption as assuming that writing a piece of code will work as you expect. There’s no compiler for the vastness of human interpretation, so build in some backups.
Ahem. I’ll get off my soapbox now.
How did you get started programming?
I didn’t have a computer until I started my first contract at 27. This was a deliberate move because I used to harangue my Dad constantly to bring home a portal computer from work every weekend so I could work on it. I knew that if I had a PC in my bedroom it would be 2–3 years before I saw sunshine.
Even so, I started mucking around when I was 11 on a TRS–80 and then a Kaypro II. BASIC was the language of choice, but it wasn’t until Year 11 when I was introduced to Pascal that I became a full addict. The Turbo Technojocks Toolkit will forever hold a place in my heart.
From there it was C, then FORTRAN. The odd progression was because my work in my physics degree allowed me to use C, but my first real job was working as a Geomorphologist writing DEMs and FOTRAN was the one and only language there.
My patience with FORTRAN was short-lived so I started moving everything to C++ and MFC, blowing away their expensive mainframes with 133MHz PCs. After that it was back to FORTRAN on a CRAY. While the language was the same, the automated parallelizing tools that took your code and made it better were mind-blowing (to me). I was humbled.
I love their general lack of firearms and personal grudges. No, hang on, I’m thinking of a different community.
What I most love is the community’s desire and ability to share knowledge selflessly and prolifically. I am constantly amazed and humbled at what I see developers providing to the community. I also enjoy the intelligence, wit and creativity of the community. Conversations are quick and merciless so it keeps you on your toes.
What I most hate? Conversations are quick and merciless.
Actually what I dislike most in the software community is the extremely small percentage who have the ego-driven need to insult others at the slightest mistake or provocation. We’re an egotistic bunch by nature: our work sees us as Masters of Our Universe – at least until you get a core dump – and it can leak into online life a little.
So there is always going to be a group who feels they can do anything better and refuse to consider the practical limitations that other developers face. Maybe they don’t have the luxury of using new tools, or maybe they aren’t native coders, but rather a guy who can get most of the job done when no one else in his company can, and from that perspective he’s providing a critical service. His code may smell but he’s doing his best and he’s doing what’s most important: providing software services that allow others to do their job. I think many people forget the ultimate purpose of their code and this can lead to a loss of perspective.
Which gets back to my motivation for starting and continuing to build the CodeProject community. I enjoy helping devs in their daily life get things done or get code that they would not otherwise be able to get, or get done. It makes the head-shaped dents in my desk worthwhile.
What advice would you offer to an up-and-coming programmer?
You cannot write 100% perfect code. Even if you do, in 6 months time it will not be perfect. Stop trying to write perfect code and focus on writing code that works and that is – in the hands of your users – as fast as possible. It’s far better to write code that is robust, maintainable and that will tell you what’s wrong with itself so you can fix it quickly rather than assuming it will work flawlessly. It won’t.
Oh, and get a good chair. It’s really important.
