Purist vs. Pragmatist

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/purist_vs_pragmatist.htm]

I've seen a lot of different developer personalities over the years. Two main groups, who always seem at odds with each other, are the "purists" and the "pragmatists".

 

Here's a brain-dump based on my personal experience:

• The purist wants to do pure, perfect coding, and never get their hands dirty with un-pure code.

• The pragmatist wants to get the product shipped and make the client happy, but may take hacks and shortcuts to do so.

I see pros & cons to each approach.

 

	Pro	Con
Purist	PRO: Always trying to do it right, wants to avoid hacks that would be costly later on. PERCEPTION: Seen as visionary leaders whose best-practice principles set the entire project on the right path, and spares the team from endless hours of hacks. EXAMPLE: "This is a 3 month project, we're going to take the first week and set up a build server with proper continuous integration". FAVORITE SAYINGS: "We got to do this right" "These are the best-practices" "Look at the rate-of-return"	CON: It is easy to be a purist on paper, or with the easy problems, but the mess of the real world (deadlines, client changes, complex technology, personality differences) means that we often need to make compromises that aren't always perfect. PERCEPTION: Seen as ivory-tower elitists who never actually get the job done because they keep waiting for the perfect component in an un-perfect word. A purist is more talk than action, and because it's easy to talk, purists are always asking for the impossible. If a purist actually had to do it themselves, they'd act like pragmatists. EXAMPLE: "That fileCopy utility (used only for internal development) isn't good enough because it may not handle the new encoding standards in three years, you need to re-write it from scratch." FAVORITE SAYINGS: "My previous project (which did everything perfect) got this right"
Pragmatist	PRO: Focuses on getting the job done so that the company stays in business. PERCEPTION: Seen as the "real workers" in the trenches who get the job done. EXAMPLE: "It'd be nice to have a script that automatically deploys the entire product, but there are some third-party manual GUI configuration steps that we just cannot automate yet" FAVORITE SAYINGS: "Talk is cheap" "It's easier to describe than implement" "Show me a proto-type" "How will you find schedule time for that"	CON: The pragmatist may get so caught up in "just getting it done", that they always take the immediate solution, which is usually not the best long-term solution. PERCEPTION: Seen as desperate hackers who get the current product out only by writing mountains of bad code, for which the purists later spend 10 times the effort to fix. EXAMPLE: "This component is due next week, I'll just copy this code to ten different places because I don't have time to refactor it." FAVORITE SAYINGS: (bad if used as a justification to commit some hack) "We got to get it done" "We don't have time".

 

You could simplify this as the purist is obsessed with the cause (we'll do it right, no matter how long it takes), the pragmatist is obsessed with the effect (we'll ship a product, even if we need to cut corners).

 

Of course, I think the ideal approach is a balance. The very good book, The Pragmatic Programmers, shows many such balanced-techniques. Sometimes, you'll be forced into a hack - but there are still good ways to handle that. It also helps having a team with a range of these personalities so that people can hold each other accountable and bring out the best in one another.

Three year anniversary

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/three_year_anniversary.htm]

Jan 19th is the 3-year anniversary of this blog. I started back in 2005.

Some obligatory stats:

• Total posts - 244
• Total hits - about 715,000 - almost 3/4 of a million
• Total comments - 270
• Most popular blog entry - Multiple Onclick JavaScript Events on a Single Control - 23,600 hits.
• Most difficulty blog entry - Silverlight TruckWars - I spent a good chunk of time writing a Silverlight arcade game.

Some things to note:

• The popular posts are never what I expect. I spend 10 hours writing a detailed post, and it gets little traffic; I spend 5 minutes whipping out a brain-storm, and it gets a thousand hits. Ironic.
• User comments have been great. There have been some discussions on posts, some people who have added useful enhancements to a post, and others who just let you know that they're reading it.

This is also a good time to point out that in the upper right corner of this blog, there's a "Donate" button to the Lupus Foundation of America to help find a cure for lupus. If you've ever been helped by this blog, consider giving even a $1 or $5 donation to help people with Lupus.

Thanks.

Build vs. Compile

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/build_vs_compile.htm]

In the Microsoft development world, I hear a lot of "non-process-oriented" developers intermix the terms "build" and "compile". I can understand why; I used to be that way myself. For example, if I look at even the new VS2008, the "Build" menu will by default just compile your solution. Sure, you can add pre-build and post-build command line calls, but the point is that out-of-the-box, if you just use VS2008 on a small project, it's easy to think that "building" means "to just compile your code".

 

Building is so much more, hence Microsoft shipped MSBuild back in 2005. A full build process may include many steps, of which compilation is just one:

1. Check out source code

2. Run active code-generation

3. Ensure external data stores can be upgraded (i.e. nothing broke the database schema)

4. Compile

5. Run unit tests (ideally with code coverage)

6. Run other tests (performance, stress, functional, etc...)

7. Run static code analysis

8. Create MSI install packages

9. Publish those packages somewhere

10. Publish results to the team (i.e. email/rss feed the build's status)

A lot of developers have CruiseControl running on a dedicated build server, kicking off an MSBuild (or maybe an NAnt) script to run all this.

 

So, the moral is that "Build" != "Compile". Rather, Compile is just a subset of Build.

Intellectual Equity

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/intellectual_equity.htm]

There are two common ways to get financial compensation: equity (you get a percent of the final profit), and fixed-rate (such as an hourly rate). Equity has the potential to pay far more because the actual revenue could be unlimited, whereas an hourly rate is (A) limited by a finite number of hours, (B) limited to an average, market value rate. Successful startups become rich because they have equity in the company. Of course, if the business flops, then equity becomes useless. This also relates to risk vs. reward: usually equity is more risky, and hence the potential for higher reward.

These same principles also apply to learning. "Equity" corresponds to understanding the core concepts involved, not just what it takes to solve your immediate task. This can yield a huge intellectual reward. "Hourly rate" corresponds to just doing what it takes to get your job done. While the hourly rate is "safe", it doesn't give you much in return compared to the equity approach.

For example, one developer spends their time just doing data entry forms, another presses to also learn about the data access layer, the architecture, and how to code generate everything. 3 years down the road, the second developer will likely run circles around the first.

The truly "rich" (i.e. intellectually knowledgeable) developers are the ones going after "intellectual equity".

What if I'm a non-technical person doing technical recruiting?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_if_im_a_nontechnical_person_doing_technical_recruitin.htm]

A lot of non-technical recruiters are stuck with the difficult task of interviewing technical candidates. The obvious problem is that it's hard enough for the developer to keep up with the latest technology; certainly one can't expect the HR recruiter to do so as well. It's even harder for small companies that have one recruiter interviewing for all departments, as opposed to a dedicated recruiter. While it's a difficult situation, there are some things that the recruiter can do. Here's an informal brainstorm:

 

Do not:

• Don't ever bluff. While this may impress a poor candidate (who you don't want anyway), it will turn off the good one (who you do want).

• Don't just assume that years of experience makes a better developer. In the NBA, the top draft rookies will add far more value in their first year than a below-average veteran. That's why 20-something kids like Lebron James and Dwayne Wade make millions. They're that good. And the talent spread is even greater in mental work like programming than in a physical sport like basketball.

Maybe:

• Ask the developer to rate themselves. I.e: "On a scale of 1-to-10, how good are you with C#?" Some recruiters love these ("the candidate is doing my job for me by telling me how good they are!"). I find them silly:

  • Problem 1: Usually the scale is undefined. What's a 10 - Scott Guthrie, an MVP, someone who can perfectly fix all the company's problems? Perfaps the ambiguity is good for other jobs, but development requires more precision. Do you really want to hire a developer who so readily uses an undefined system?

  • Problem 2: The candidate already knows the correct answer - they had better say something better than a 7, or they're disqualified.

  • Problem 3: Usually people think they're better than they are, especially if they were a big fish in a small pond. I've seen lots of guys answer 9 or 10 on these, only to fail to answer trivial C# syntax.

Do

• Round 0: The Resume

  • At least be familiar with the top 10 buzzwords and technologies so that you can see if the resume is on the right planet.

  • Check their resume for extra curriculars. Do they at least have something more than their normal work-hour projects?

• Round1: Asking basic questions

  • Ask simple technical questions, just to see if they can give a confident sounding answer. If a developer can't give at least a confident-sounding answer for "what is polymorphism", they're probably not ready for a real job.

  • Ask questions that transcend the technology and show that the candidate knows how to think, like "what's the hardest problem that you've ever had to solve" (then ask a follow up question). Behavioral questions are great for that. You could ask them to compare projects on their own resume.

• Round 2: a simple quiz

  • Have a simple in-house, 10-question, written exam that has practical questions. Don't send a candidate to take some 2-hour, third-party, trivia quiz ("What are the 19 method overloads for StringBuilder"). The third-party quiz is usually a one-size-fits-all trivia marathon. Instead, use a quiz written by your own developers to test the knowledge your team cares about. Paylocity uses http://www.pereless.com to help administer this kind of quiz. Then ask your devs to grade the quiz; they'll usually be able to run through it in less than 10 minutes.

At this point, you're probably ready to decide if the candidate is fair game to send to the development department for a real interview - the kind where they write real code on a whiteboard and get drilled by technical experts.

 

Hiring based off years of experience, an analogy with art and the NBA

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/hiring_based_off_years_of_experience_an_analogy_with_art_an.htm]

I'm always intrigued how HR recruiting is often obsessed with how many years of experience a candidate has. This is absolutely not the same thing as "does the candidate have the required skills". The thinking seems to be that developers start at the same place (maybe as college kids in computer science class), and learn at the same pace, therefore the real determiner of skill is the years of experience. Therefore, a dev with 10 years should most likely be better than a dev with only 3 years. I think this is dangerous and misleading thinking. Sure, all else equal, years of experience would be a good indicator of skill, but all else is not equal.

1. People start learning to program at different ages - not everyone starts at college, some start when they're 10 years old

2. People learn at different rates - some people just naturally learn things faster than others

Think of it like art - some people just can't draw (like me). Maybe if you give them years of classes, and they practice and practice, they may be able to squeak out a simple painting - but they're always going to struggle with it. Other people just have a natural talent for it, and even as a 10 year old, can draw a good looking picture. The best question to determine who is the better artist is to ask for their portfolio (samples of what they've drawn), not ask how many years of experience they've had. Like asking for an artists' portfolio, interviews can ask a developer to show them an open-source project, or actually write code on a whiteboard. That's a much quicker way to verify their skill set.

 

Or, look at the NBA. While of course veterans and experience are good, there are plenty of young rookies who add far more value than a 10-year veteran. Simply hiring based on who has the most years of experience would naively miss out on good talent.

 

I see it much like the graph below of skill vs. time. Someone could start learning as young as 12 years, or wait until college, or even do a career switch after college. You can't really count playing around with programming as a child as "years" or experience on your resume, but it sure does increase your skill level. So, a recruiter could categorize all three cases as "just four years of experience". But the skill difference is too wide for that naive approach to be practical. There are 18 year old interns that just "get it", whereas some 40 year old contractors that do not.

 

That's why it's always best to look at the skill, as opposed to blindly check for years of experience.

 

Next: But what if I'm a non-technical person doing technical recruiting?

Missing EventValidation because modal dialogue blocked rendering

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/missing_eventvalidation_because_modal_dialogue_blocked_rende.htm]



I saw an application giving this error:

System.ArgumentException: Invalid postback or callback argument. Event validation is enabled using in configuration or in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

As is often the case, it "worked on my machine", but failed in production. It looked like one of those ghost bug things.
In this case, the problem was that the "EventValidation" field was missing entirely, so ASP.Net thought the page was corrupted:

1. In production and QA, the page had a modal dialogue pop up. This was because both those environments ran in HTTPS, and that particular page had a JavaApplet on it, such that a modal dialogue popped up asking the user to confirm the security permissions.
2. If the user clicked no, then that interfered with the final rendering at the bottom of  the page, which practically meant that just the "__EVENTVALIDATION" was never generated. The rest of the page looked the same.
3. EventValidation was required to validate ViewState, so the server thought someone was hacking the page, and the Exception got thrown.

At first glance, a developer might just set Page EnableEventValidation="false", but that is a bad idea because it opens up a security hole (anyone could change your EventValidation value and exploit the app).
You can get an idea with this html code snippet, where I've substituted the JavaApplet call with an alert message (although the alert is truly modal, so you can't click a button until it's closed).

<body>
    <form id="form1" runat="server">
    <div>
   
  Text 1: this is the initial alert
   
  <script language="javascript" type="text/javascript">
    alert('yo!');
  </script>
 
  Text 2: this appears after the alert
 
    </div>
    </form>
</body>

If you attach a debugger to the JS, you'll see that the second chunk of HTML text (Text 2) only gets rendered once the user closes the modal alert box. However, we can fix this by running the JavaScript code that called the applet in an asynch process via setTimeout, something like so:

<head runat="server">
    <title>Untitled Page</title>
    <script type="text/javascript" language="javascript">

    function DoStuff()
    {
      setTimeout("MyMethod()",500);
    }
    function MyMethod() {
       alert('yo!');
    }

    </script>   
</head>
<body>
    <form id="form1" runat="server" >
    <div>
    ASYNCH Hello world
   
    this is the initial code
   
  <script language="javascript" type="text/javascript">
    DoStuff()
  </script>
 
  this appears after the code
 
    </div>
    </form>
</body>
</html>