Are You Good?

{

A good way to get attention in the programming blogs is to draw a distinction between "good" and "mediocre" programmers and allow developers to question whether they can consider themselves "good."

Atwood posts that you're either good or mediocre at programming despite the amount of practice or effort you may decide to put in:

"A mediocre developer can program his or her heart out for four years, but that
won't magically transform them into a good developer. And the good developers
always seem to have a natural knack for the stuff from the very beginning."

Joel Spolsky and a few others seem to use the tactic quite a bit; reeling people in by causing them to question themselves.

I wonder what it is in a programmer's DNA that leaves them with a self doubt? On the other end of the spectrum there are a lot of popular posts devoted to the topic of making oneself better - I found this old Steve Yegge post as a rebuttle to Atwood; that practice is not only a way to get better, but a necessity of the better programmers.

I have no idea how to categorize myself; I don't dare think of myself as good especially when people like Joel Spolsky can throw tests my way that pretty much leave me gaping and grasping.

But, although the blog post I bothered to take time to write speaks to the contrary, I'm not sure if questioning oneself is very productive. Most programmers I respect out there are unbelievably productive - there doesn't seem to be a lot of time for being paralyzed by self doubt.

Back to practice I go.

}

Querystring: Laziness or Design?

{

Mads Kristensen posted about retrieving items from the querystring by a series of checks against nullness (is that a word?) and type values. His starts with:

if(!Request.QueryString["foo"] == null){
// do interesting things
}

Continues with a little more elegance:

if(String.IsNullOrEmpty(Request.QueryString["foo"])){
// do interesting things
}

Finishes with a check on type integrity during the querystring check:

if(!String.IsNullOrEmpty(Request.QueryString["foo"]) &&
Request.QueryString["foo"].length == 5){
// do interesting things
}

I like seeing things like this because it's interesting to look at how someone does something I do all the time with a different twist. I'm a pretty lazy guy, and although I hope to attribute it to the perl affinity in me, I'm not sure if it's really a spade being a spade and I actually am lazy in a bad way.

For most of my projects (except when I'm at a client or somewhere that I need to copy follow a defined pattern) I usually write a little "helper" class with static methods for this sort of thing:

class Helper{
public static string GetQS(Page page, string key){
return (page.Request[key] ?? String.Empty); // ?? is so slick yo.
}
}

When I'm reading out querystring values, I sometimes read and assign simultaneously:

string foo;
if((foo = Helper.GetQS(this, "foo"))!= String.Empty){
// do interesting things with foo
}

Of course this is a variation on Mad's theme, but one critical difference - a lazy one - is that my gut reaction is to intentionally allow failure on type integrity outside the querystring check. That failure usually invokes a more generic handler related to the operation in question rather than having to decide what happens the moment I know I have a bad querystring value. For example:

string quantity;
if((quantity = Helper.GetQS(this, "quantity"))!=String.Empty){
this.UpdateQuantity(Convert.ToInt32(quantity));
}

My rational is that I can write my exception handler for the operation "UpdateQuantity" rather than the specific querystring item. UpdateQuantity may throw different types of exceptions and I can capture them all in one fell swoop instead of defensively trying to test everything up front.

try{
string quantity;
if((quantity = Helper.GetQS(this, "quantity"))!=String.Empty){
this.UpdateQuantity(Convert.ToInt32(quantity));
}
}
catch(FormatException ex){
// specific exceptions I can of more assistance
}
catch(Exception ex){
// log and inform *shrug*
}

Of course that's lazy. I'd like to think it's lazy in a perl way rather than lazy in a couch potato way. What say you?

}

Yahoo Blew It

{

Just finished a Wired piece by Fred Vogelstein on how Yahoo fell behind Google. There's more detail in the tell but in a nutshell it boils down to a comment Joel Spolsky had made on his Venture Voice podcast: non-technical managers and CEOs are the doom of technology companies. Or, in the closing paragraph of Vogelstein's article:

"At Yahoo, the marketers rule, and at Google the engineers rule. And for that,
Yahoo is finally paying the price."

It's a good morality tale and definitely one I see as true in the world around me. Especially as many non-technical people launch "Web 2.0" companies, I wonder how often it will be replayed for those of us with a different, more technical perspective.

But I'm not convinced that Yahoo is out for the count. There are a few things that I think they get right and with a change in approach can really capitalize on:

1. Mail - Yahoo makes my favorite web based mail client. I use the "beta" version of their mail software which was written by the folks from Oddpost. I wonder if they'd turn these guys loose to write some other cool software, like a killer RSS Reader to make Netvibes eat its heart out.

2. Curators - The craze at the moment is over user generated content but a model that I think will still remain profitable is that of having curated content; hiring someone who knows what they are doing to pick out what's interesting for others in a particular domain. Why can't Yahoo take what is done so well on Yahoo Picks and extend that to more specific content? Not overblown CNN style content heaviness, just a small group of people that find a few interesting things and keep the site sparse. What's ironic is that as "user generated" content seems to overtake the web, there is more need for people who can pre-parse it to find what's more special.

3. Developer APIs - One thing that made me happy about Yahoo's Developer Network was that it had to do with pushing out their philosophy and sharing what they standardize well. Their APIs are a bit bulky in my opinion at present, but there are some clever people over there who can really help developers be more productive.

4. Excellent content - Yahoo Movies, Yahoo TV to name a few. I keep going back because they are that useful.

There are more things but I'm an outsider who is simply commenting on what he likes. Yahoo has a lot of smart technical people they don't seem to be listening to. Reading Jeremy Zawodny and Josh Woodward shortly after the release of Google Finance seemed to confirm this sad fact.

Because the one thing about the Wired post that bothered me was that Vogelstein kept going back to the leadership of Yahoo under Terry Semel where I see as big of a problem in Yahoo not being able to leverage its developers for ideas beyond how to implement specifications. Semel's ability to make deals and encourage integration are a part of this, but it seems like it occured at multiple levels of management, not just at the top.

One more thing I can think of helping Yahoo stay relevent in their battle against Google and other web companies: why not buy some of Paul Graham's companies (or other "built to sell" companies that seem like winners)? Forget revenue models, forget integrations - forget all that MBA stuff for a moment. Thinkature (Yahoo anounces Visio modeling mixed with Powerpoint presentability for the future), Snipshot (Yahoo delivers online photo editing and hosting for the masses), Jamglue (Yahoo presents technology to mix/remix and make ringtones)... there are a lot more than these to be sure, but just of the top of my head - represent some ideas that can get people excited. Not only that, the young founders are the types of people who won't stop thinking even after their technology enters a bigger and perhaps more orthodox arena. Money doesn't grow on trees but Yahoo has a lot of resources and a big market capitalization to work with - it only takes one good idea to make the whole thing worth it.

I don't think Yahoo is done by any means. I sincerely hope they have a second life, not necessarily as a victor in a war against Google, but more as a successful web company staying relevant and making people happy.

}

view-source, javascript, about:config

{

A while back Aaron offhandedly shows me a slick trick with Firefox when I'm complaining about how it doesn't show namespaces on xml documents: you can use view-source as a protocol to look a website's source code. If you've got Firefox, check it out.

I've been making my way through the 5th edition of the Rhino book and Flanagan shows another technique of using your address bar with a protocol. You can type something like:

javascript:alert("Hello World");

into your address bar and just like that you've got a little play pen for your javascript. You can also extend it to include html that you'd like to render, for example:

javascript:alert("Hello There");<p>Hello</p>

Of course do not forget about:config as a way to configure Firefox. Any more of these goodies?

}

Certification

{

Jeff Atwood posted recently about certification, coming to the following conclusion:

"I don't believe in certifications. The certification alphabet is no substitute
for a solid portfolio; you should be spending your time building stuff, not
studying for multiple choice tests. But that doesn't mean they're worthless,
either. I don't think certifications get in the way, as long as you can
demonstrate an impressive body of work along with them. "

Many of the comments are the predictable reactions to certifications: they suck, people who obtain them don't know anything, they are self taught without certification, those who can't code obtain certifications and so on.

Reading a lot of the comments makes me want to add my own perspective to the fray, as cluttered as it is, because I'm the product of certifications. My own conclusion on certifications doesn't fall far from Atwood's, but because I was and am tied to that world, I reach it by a different means.

My background is what led me to certifications. My degree was in Accounting, and the only company that took a serious look at me in the technology world as I frantically tried to leave the public accounting firm I worked at required them. In fact, during my interview, my interviewer told me that I was one of several candidates who they were considering, and the first of us to obtain a certification would probably get the job. I didn't really know where to start - I had some sparse computer experience from building web pages and working in my university computer lab, but I was limited in doing practical things with computers. I went to my neighborhood bookstore and inspected the shelves, settling upon the biggest book I could find (assuming it had the most content) to study for the Microsoft Networking Essentials exam. I spent my lunch breaks at the accounting firm memorizing differnent network topographies, cables, and protocols.

I failed the exam on my first try, but this was not because I missed anything in the book. I was a fairly good student, and I literally memorized large portions of the book. Rather, I failed because I didn't know how the test would relate to the material I had learned. Once in the "certification game" I understood how people study for the exams (practice exams, looking at exam objectives) and how to look for "keywords" - things that give away the answer to the question.

For that basic networking exam, relating Novel any time I saw IPX/SPX was half the hard work in finding an answer to the question. For example:

Q. You have connected several Novel print servers to your Network but users complain that they do not work. What should you do?
A. Verify that IPX/SPX protocol or client is enabled.

I never failed another certification exam. Well, alright, I failed a VB 6 Enterprise Application Development exam because I'd had a wisdom tooth pulled the day before and was under the influence of painkillers, but I'll pretend that didn't happen.

As the exams got more elaborate, I learned it was very important to know how questions were asked (use practice exams) and where I was weak (exam objectives). The exam objectives would tell you which part of a product you were weak on. For example, I was never very good at answering deployment questions when taking developer exams. Not only was this somewhat difficult (and boring) to simulate, it wasn't something I needed to do very often living primarily in the world of web application development.

Now that I've had some distance in the certification world, my conclusion for people - especially developers - is that people who certify are responsible for learning how to answer questions. Although these questions may be related to their experiences, experience and knowledge are not a sure way of passing an exam. One needs to know how the questions work. Even on exams that involve simulations, understanding what will be needed is critical.

I certified on SQL Server many years ago - I don't remember the exact year - but it was during the SQL Server 7 days. I will probably take the new SQL Server exams but much of this is based on simulations - I know this because a coworker recently passed on of the exams and told me about it. The interesting thing is that I've used SQL Server every day for at least 5 years and prefer to live in TSQL for most of what I do. I'd have to spend some time getting comfortable with the GUI in order to take this exam, but it would not be related to my experience. Even more frustrating - my time looking at the GUI would just be learning to do things I already do.

In this sense I share the frustration that many people have about certifications: ability to answer quiz questions doesn't translate directly into the workings of day to day development. Many of the typical questions even if unknown would be about a 1 minute trip to Google or the documentation.

Here is my "but:" certifications force exposure for the people taking them. I know a lot more about deployment than I would have if I based what I knew on what I was inclined to learn on the job. I know a lot more about networking than most of the people I work with simply because I did have to learn it to be "certified." I'm sure some of my time without certifications would have been spent on personal projects or readings of personal interest, but without discipline some of that reading is of only general benefit. And because certification objectives are very practical (if not boring) they usually result in knowledge that is more focused.

I had a friend who was largely self taught and extremely intelligent. His personal study took him into the world of C++ where he excelled, preferring to spend his time studying Open GL libraries. It's interesting stuff, to be sure, but it's not MFC or the Win32 API. As a result he could make a lot of cool demos, but he wasn't the type of person to write a banking application. He wasn't particularly interested in that but as a thought experiment what if he'd decided to endure some of the boredome and learn how to write MFC with database connectivity? Certification would have forced that exposure which, combined with his aptitude, would have made him quite a developer.

One final note before I give my own conclusion - similar to Atwood's but different enough that I felt compelled to write this. Atwood posts a comment from an older article on certifiction:

I suggest that we have a perfectly fine selection mechanism at work today;
it's called the market. Some people get hired as software developers and some
people don't. It is a lot more competent than any appointed elite would be and a
lot more ethical.

I recently realized that there is a little bit more economic activity in certification, not necessarily on the side of the big companies that sponsor them. Many people who have certification use it as a tool to restrict supply and drive up their own "value." For example, many Microsoft trainers are eager to have Microsoft require a "premier certification" in order to teach their coursework. The argument they use officially is that it will ensure that the trainer delivering content is knowledgable but the intersting facet of this argument is that obtaining and maintaining "premier certifications" (many of which have multiple exams) requires considerable effort (and massive opportunity cost - instead of learning the new GUI of SQL Server 2005 a person could be writing, say, a stored procedure generator using SMO). It leads me to believe that most of them know that increasing the amount of time and effort for certification is in the interests of their pockets as much as it keeps people "knowledgeable." I also observe this pattern in my own certification life: when I'm doing project work, which is usually intense and requires a lot of my off hours, I'm never certifying. When I'm between jobs, or if I'm asked to teach a class or do something that requires certification, I sit down and do what's necessary.

So my big conculsion? Everyone has a story of the MCSE who never installed Windows or the "certified" guy who had no practical experience. A lot of the time it's people like me - not disciplined in the work of computers and trying to put something on a resume. In that sense I don't disagree that a certification all by itself is meaningful. I defer to Atwood's comments about showing work that's been done and a track record of personal effort.

But.

Certifications in addition to a person's track record are a good thing to take into consideration. Not only do they show a person putting in some effort beyond work related requirements, it also means they've got some exposure (knowledge-wise) to areas of a technology outside of the context of immediate use.

In the end my apology is biased because I do have certifications. But there's a value to them that most people miss because they have had bad experiences with people that abuse them or try to compensate real experience and/or projects with them.

I'll continue to get certifications as a part of work related requests but I'll never get them again in the context I started with: a guy who loved computers and was trying to get a job and demonstrate to people effort and a little bit of knowledge. As I interview people and present myself I'll present my certifications as that original effort, not necessarily where I am now. I've got projects (day and night) to try to assert my credibility.

}

Stay on Java + Algorithms

{

Because I'm in C# all the time, my Java is passable with effort, but not pristine - like a Norwegian's use of Swedish or a Portuguese person required to use Spanish.

But there's good reasons to hang onto that Java; it seems like Google interviews may require rapid prototyping in the language.

Most algorithms are language agnostic (save the ones that leverage language features (think functional)) but it's also interesting to see that quick deployment of those with optimizations seems to be a part of the process.

}

Crockford Javascript Presentation

{

I'm excited that next week I'll be in Los Angeles. I got the opportunity, along with some other people from Daktronics, to attend Developmentor training on Biztalk. Tonight I was going to watch a Biztalk presentation from TechEd but got a little sidetracked watching Douglas Crockford's excellent javascript presentation on the DOM.

Although the presentation is about the DOM which a lot of people think they know and understand, Crockford adds a lot of historical and insider information about how browsers work and what implications that has for writing DHTML. Really interesting.

There's a different presentation I was looking for - on javscript's prototype based inheritance, but I'll get to that on a different day.

}

YAJL - Yet Another Javascript Library

{

I've been between libraries... did I post this before? Probably... anyway I've tinkered with Yahoo!, Prototype, and jQuery thus far and have yet to decide which poison is best or whether I roll my sleeves and reinvent the wheel a bit.

Anyhow, today I learned that Adobe Labs has released Spry - Yet Another Javascript Library out for public consumption. No time to dive in tonight but the documentation looks pretty good.

As an aside, not sure how I got there but here is some great documentation on Prototype.

}

IE 7 appendChild bug

{

I'm working on t3rse::proper to allow custom shortcuts but discovered a bug with IE 7 when using the appendChild method of an element. It will take a bit more time to nail down specifics but try the following:

var tr = document.createElement("tr");
var tdchar = document.createElement("td");
var tdtext = document.createElement("td");
tdchar.appendChild(document.createTextNode('foo'));
tdtext.appendChild(document.createTextNode('bar'));
tr.appendChild(tdchar);
tr.appendChild(tdtext);
// you need some table with the id as testTable
document.getElementById("testTable").appendChild(tr);

Pretty straight forward and does _not_ work in IE 7. Check it out in Firefox and it works like a charm.

But the bug doesn't seem to be that simple; if you are called appendChild on a DIV or SPAN outside the context of a table, it works fine in both browsers.

// make a div with an id attribute of 'test'
document.getElementById('test').appendChild(
document.createElement('span').appendChild(document.createTextNode('foo'))
);

I'll dig into this a bit more - I see comments on similar things via Google search but nothing definitive. Unless AJ has answers... you always have answers...

}

Jifurahishi

{

... which means in Swahili to "be excited." It's interesting to me how Apple is so good at generating a buzz and feeding the frenzy of their users. My boss is using Vista right now on a brand new shiny laptop but no one is gathering around the machine to say "ooh" - but I guarantee if I had an iPhone in the cub area people would be crawling over each other to have a look.

To be sure a lot of it is design, but there seems to be something more. Apple seems to court their users with the new and the novel, Microsoft rolls out a new version of what you already have (operating system) or a copy of something else that's successful (Zune). Apple knows how to keep people guessing and drum up occasions like Macworld to wow people. Microsoft seems to release their products in a time warp (Origami, anyone?) and make things that seem to have no mass appeal (Origami == Newton 1994?).

Sigh.

I'm geeky enough, however, to be excited about Microsoft's products - specifically IIS 7.

Well, the iPhone is out of my price range (I always take the free with the service phones) but it's good eye candy.

}

JSON Wars

{

Perhaps not war, but there seems to be an upswell in the JSON versus XML discussion. JSON as many describe much better than I do is a javascript object literal you can return directly to a page along the lines of:

{"name": "David Seruyange", "age":31, "preferredLanguages": ["C#","perl", "javascript","ruby"]}

If you type a lot, you can do the same thing with an xml style of notation, something along the lines of an element person, nested element name, nested element or attribute for "David Seruyange"... the whole thing gets to be quite a bit (I'm too lazy to type it out at the moment).

I first noticed Dare Obasanjo sniping a bit, after which I saw a few trails elsewhere - the post he was responding to by Tim Bray, and another referenced one from Don Box.

But it's extended - Simon Willison chimed in on flexibility of JSON in response to Dave Winer's post on JSON. Megginson makes a comparison here (in the end favoring XML), and so the conversation goes.

In terms of my own personal experience, I discovered and used JSON on my last project. It's a very, very seductive thing but I found killer gremlins in terms of making sure I used proper characters in my object literals. Javascript does allow you to use the \ character to escape quotes in strings but as you ship strings around you have to make sure you keep track of what you escaped - especially in my case where users would have to "see" things on screen (remove the escape) and then be able to push them to a database.

In the end I think JSON will prevail (by this I mean more and more developers will use JSON with AJAX than web services) not only because XML is more verbose but also because parsing out nodes in an xml document is more painstaking than leveraging the power of javascript to turn a literal into an object. I'm curious to see (or discover since they are probably out there) more JSON parsers than take care of things like escaped quotes and special characters. I'm equally curious to see server controls (or encapsulated code) that can ship data structures to a client as JSON - one night project I see coming up is a library that can take an ADO.NET DataTable, for example, and convert it to a JSON string.

Oh, one last thing. At the time of my last project when I was deciding how to proceed with Ajax, I took a long look at an early beta for Atlas. I was surprised that the JSON functionality hadn't caught on there and it seemed to use full blown SOAP encoding web services. This may have changed with the release candidate of ASP.NET Ajax but at the time JSON was pretty popular in the world of javascript.

}

Two Responses

{

One thing that gives me delight to no end is making tools that help people around me. I guess that's why I'm a software developer. Or, I guess, that's why I enjoy being a software developer.

I've worked on a few types of code generators to date, the idea of course being to save time when people have to do repetitious or monotonous tasks. Another big idea I've had was inspired by David Heinemeier Hansson's talk at Carson Workshops where he talked of the notion of convention over configuration (linked here in the context of spring, but a general enough design pattern). I thought: why not start with a bunch of conventions and, if need be, customize when necessary?

I've recieved two responses over the utilities I've written that seem to point to different philosophies regarding software development and how I win with some people and struggle with others.

The first was a developer who was excited when I showed him a utility for generating property stubs - a lot faster than using Visual Studio's class designer or code snippets. I could see that it was the idea that got him going, not necessarily the implementation because his following question was if he could have the source. This is no problem on my end - I always just ask for bugs people find and features they'd want so that I can put them in an updated version. Half of the fun is finding out what people want and then giving it to them -

The other response was from another developer who was a little bit more hostile to the notion of a utility that didn't come from a larger party (a company like Microsoft) and wasn't particularly interested in even seeing how the tool worked (let alone what improvements they'd want to make to it). In this particular scenario I prompted the person by asking if they were more interested in hand coding what needed to be done to which I got a quick but very sure nod.

I think the step further that makes these two responses interesting and sidesteps the question of whether what I've made is really all that good is that I know these two developers well enough to know that the first is a younger guy who is interested in open source - who prefers tools like Firefox and Thunderbird, and who has night projects - things he does on his own because he enjoys writing software. He reads technical articles and blogs. He is a familiar and enthusiastic user of RSS and syndication tools. The second developer is a "business" guy - less of a dreamer but very much a hard worker. When Microsoft (or big company X) releases a tool he uses it, and uses it as prescribed. He rarely has "time" to browse the web for leisure or interest. He also, and I think this is interesting, is the kind of person who keeps his Windows desktop as the default.

I think you can take these different archetypes and distribute them quite well - with varying levels of commitment, interest, and aptitude. The open source/mac/web world is full of people who are curious - who look at a problem or solution and think about how it applies to them. Moving beyond the open source "zealot" I see a lot of programmers like this - many in a non Microsoft sphere but quite a few avid Microsoft tool users. At the beginning of last year I thought of somehow trying to take ideas from the open source world and port them to the Microsoft sphere but it's been a delight to find so many people who use Microsoft tools who are still very passionate about technology, and the large contexts of problems and solutions.

On the other end of the sphere there are a considerable number of people who approach development without novelty, without interest in the process and more in a blue collar "just get it done" sense. Because the elegance and style are not important, it's best to go with tools that are proven by the majority - personal extensions and/or hacks are a waste of time because it counts against "getting the job done." People like this seem to have the ability to focus much more on the business or the task. That's why tool customization, hacks, and web reading (articles, blog posts, etc...) are beside the point. The point is the task. Create a XYZ. Write a method that stores ABC. Display MNO.

Of course with this divide I run the risk of upsetting people - especially the second developer (it's doubtful this blog post would ever be read, and even more doubtful that the person would guess themselves) but before I reap any backlash I want to say this: both the first and second developer are pretty effective at what they do because the nature of our work is constained by the type of software we write: big business apps that essentially boil down to CRUD (CREATE / RETRIEVE / UPDATE / DELETE). I think this sort of divide would show up a lot more if we were writing a web application framework, next generation web app, or a game.

It's not my goal to make anyone upset although even Microsoft's got the idea of different personas for developers - the question it leaves is where I can find that kind of nourishment from the first developer, even when an idea is too rough or unpolished to be useful. For people who work with Microsoft tools, without a doubt I think there's a great community in the blogosphere but even more so at conferences - a place where a guy like me can stop a Scott Hanselman and inquire as to this or that. But beyond the conference I think it has to do with (and this is very general) "open" tools and "vendor driven" tools. The open tools seem to have a community that collaborates and grows them - people who by nature are interested in making the process of software better and more enjoyable. People who have the audacity to think that a solution for them might actually help other people who are willing to give it a shot.

}