Matthew Nolton’s
comments about performance got me thinking about how the web has affected programming. Hello, my name is Marcus, and I'm an "internet-era programmer". 99% of my programming has been for the web, using ASP and ASP.NET. I started programming about 4 years ago, so whenever I hear anything about C++, Python, etc., my ears naturally tune out (much like when my wife turns on WB.anything()). My first exposure to programming was script. Java- and VB- to be specific. I’ve realized that this is not the best beginning, and work hard at learning more advanced programming techniques. I use
NUnit, PerfMon, follow
naming standards, and all the other things good little programmers are supposed to do. However, I can see how many programmers that came around in the internet age get stuck in bad practices.
The problem with having used the web as one's first attempt at programming is that performance was inaccurately distorted. If your code wasn’t 100% tight, it didn't really matter because 1) the engine was weak (VBScript on IIS compared to compiled C++); 2) the time to transfer the rendered html to the client far outweighed the time to create the html; 3) heavy traffic could make the site slow no matter how well coded. These situations made it easy for the developer to say, “it doesn’t matter if I use a “foreach” statement instead of a “for” statement – no one will ever notice the difference in performance.” And it was probably true.
Now, these same developers are having to work with .NET, possibly even writing proper Windows programs instead of web apps, and the performance issues are blowing up. Learning how to use a new language (C# or VB.NET) and the new IDE (VS.NET) doesn’t mean you can program .NET. If you don’t have a good understanding fundamental programming concepts, your code is going to be bloated.
One thing I check to make sure my code (and architecture) is optimized is the number of hits to the database for each page load. It should usually be only one stored procedure call. Data for lists that come from look-up tables should be cached (or enumerated, but that’s a whole new can of blogs). Pages (or parts of them) should be cached when possible. Control the size of your viewstate –
store it in SQL if appropriate. Images should be optimized. If you’ve pared down your page to 30k, but you have a high quality JPEG where you could use a GIF and get the same look, you could be wasting twice as much data on images as the rest of your page uses. And of course, know your syntax. Use for instead of foreach, StringBuilder instead of myString +=, etc. It will make a difference.
Other performance links:
Bill Wert has
offered to take suggestions on how his team can help.
Matt Davey posted a great
list of links relating to performance.
It’s been 3 months since I left a lead position to become a system analyst. Looking back (and taking notes for the next time I have to assume those responsibilities), the one thing I’d change is the hiring process I went through for adding people to my team. I filled about 4 positions in the 16 months I was a lead. Before I started interviewing candidates for the first position, I had a pretty good idea of what I was looking for. Our budget was cramped, but it was a great opportunity and a solid paycheck in a slumping economy. I was looking for 2+ years of experience in ASP, with some exposure to SQL and .NET. Not too stringent. Finding a good candidate was hit and miss. Many times I had a project deadline and the first qualified candidate in the door got the offer because 1 month of a mediocre developer is (we thought) better than 2 weeks of looking for the best and 2 weeks of the best’s time. Needless to say, this worked out sometimes, but not as often as it should have for such an important decision.
In the same position again, I’d look for a developer that loves to develop. The one that has a network of old machines at home with different OS’s, or the one that would just as soon stay at home and measure the performance difference between remoting and web services as he/she would go out for a cold one. Sure, knowing the language is important, but one of the best developers I worked with didn’t know a drop of ASP when I hired him for an ASP project, but I knew he could code like no one’s business. Sure enough, he picked up ASP quickly and had the project under control within 2 weeks. Maybe I should say knowing a language is more important than knowing the language.
Of course those aren’t the only things I look for – they have to work well with others, be able to discuss business issues with clients, have relevant experience, etc. But if I do get the opportunity to interview others again, I’ll focus more on gauging their love for 1’s and 0’s than their results on a canned test.
All right, now that you’ve made it through all that stuff above, I’ll admit this is my first blog entry. Thanks to Scott for setting me up. I used to be a developer/team lead and am now a system analyst. Surprisingly I’m doing the same things now as I was then, minus the personnel management and external clients. I’ll be blogging about development ideas, architecture, Whidbey, and hopefully entrepreneurship.