Why I'd rather be an optimist

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

Some programmers take pride in calling themselves either an optimist or a pessimist. Both have their positive and negative stereotypes: The out-of-touch bubbly optimist vs. the encouraging can-do optimist; the always grumpy pessimist vs. the face-the-facts pessimist.

Part of it is that most producers tend to be optimists, as it takes a can-do attitude to carry out the positive act of creating. Most critics/complainers tend to be pessimists, negatively and constantly pointing to the shortcomings. However, these are not equal positions. The producer can produce without the critic, but that the critic needs someone else to produce something so that they have something to criticize. In other words, the producer (usually the optimist) does not need the critic (usually the pessimist), but the critic needs the producer. It's like riding a sled down the hill vs. pulling it back up - they're not equal tasks; one is much easier. Likewise, a room full of complainers will never actually build something. While constructive feedback is great, a purely negative feedback loop isn't constructive. It also will get on other coworker's nerves.

Some pessimists think they're providing a great service by always pointing out the flaws, lest the optimists lose touch with reality. However, "reality" doesn't need any help in reminding developers about the facts of life. It's got the compiler, project plan, and end-users to do that.

Ideally, as with everything else in life, there would be a good balance. But, everything considered, if I had to choose one I'd rather be an optimist. It's been said that "The pessimists may be right, but the optimists have more fun along the way."
 

 

Random quotes that could apply to development

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

Here's a list of seemingly-random quotes that could apply to development. I don't recall the sources for each of these. Every now and then, it's good to have a good quote handy.

• "Talk is cheap."

• "Better to try and fail than to never try at all."

• "I prefer my way of doing it to your way of not doing it."

• "If all you have is a hammer, everything looks like a nail." (good for showing how new tools can expand your thinking)

• "The pessimists may be right, but the optimists have more fun along the way."

• "You can be right, or you can be happy."

• "Give a man a fish - feed him for a day; teach a man to fish - feed him for life."

• "Consider it done." (very nice thing to say to your manager when asked to take care of a task)

• "Easier said than done."

• "At some point, you just need to jump into the arena."

LCNUG: SharePoint Authentication: Inside the Hybrid Provider

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

At the LCNUG last night Chris Domino presented on Sharepoint. He's a SharePoint superstar, and it showed. The LCNUG still is a smaller group, so we could ask a lot of interactive questions. I especially liked a dialogue about document versioning history in SharePoint vs. saving words docs as xml and then storing those in normal version control (like subversion).

 

Overall, a very good night. I think it also marks the half-year mark for the upstart LCNUG group.

Bad Interview Question: What is your greatest weakness?

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

For technical interviews, I think "What is your greatest weakness" is one of the dumbest interview questions ever. It's like the recruiter thinks they're being so smart and sneaky ("ah ha, this unsuspecting candidate will reveal all their shortcomings as I judge them"), but it really misses the point.

 

Problems with this question:

• If the interview cannot determine your weaknesses from normal interview questions, are they really weaknesses? It is part of the recruiter's job to determine your weaknesses, and by directly asking you, they're essentially asking you to do their job for them.

• Most people aren't even aware of their biggest weakness, especially because human nature always sees ourselves in the best light possible.

• It's an abrasive question that puts the company in a bad light. People want to talk about their successes and how they'll add value, not their mistakes.

• Does the interviewer actually expect the candidate to tell the complete truth about their own flaws?

• To avoid ivory-tower syndrome, (in my opinion), recruiters should not ask behavioral questions that they themselves are not prepared to answer.

• It's a dead-end question that prompts the recruiter to pick the "least of the evils" - if you're just discussing your negative qualities, you're not going to look like a positive candidate.

• If I knew my weakness, I'd already be fixing them.

• It's very dull, and shows no creativity from the interviewer.

• This sort of question isn't going to impress a candidate. Often, the interview is really two ways, with many companies all trying to woo the star candidates.

Really lame replies:

• "I work too hard", or "I try to hard". --> anyone who has been around can see straight through this.

• "I do such a good job that it makes everyone else envious of how great I am."

• "I don't really have any flaws." --> everyone has limits, which is very different than saying that you do have shortcomings, but they occur mostly in other, unrelated fields, or long ago when you first got started.

• "I've never been in a position with enough influence to do any damage, so I'm not sure."

Possible good replies:

• Humor: "You know, you could get a really good answer for that if you just talked to my wife." (or husband/spouse/significant-other )

• Serious: "While I've made mistakes in other fields, like buying my first car, for years I've been putting most of my eggs into the software engineering basket precisely so I don't make huge costly mistakes anymore. But we can discuss my early car-buying experiences if you'd like."

• Confident: "Let's have an interview and you tell me."

• Change topic: "Here's how I've dealt with mistakes that the company has made, and turned them around to be profitable..."

• Pick a small, past event: "When I first got started, 10 years ago, I used VSS for source control. The default single-user lock model really messed up our multi-team project. Now I'm happy that we always use Subversion."

• Sarcasm: "My  biggest mistake ever - like single-handedly causing the stock market crash of 87 - I don't do those kinds of things anymore." (you'd need more charisma than I have to pull it off)

• Smart Aleck: (when you don't want the job) pick a topic that's way over the recruiter's head. I'm trying to think of an impressive example, but I'm sure the readers of this blog would just tell me how simple it was.

• Smart Aleck (when you don't want the job): "What would you consider a failure? Perhaps you can tell me some of your greatest failures so I know what kind of things you're looking for."

At Paylocity, I don't think I've ever asked a candidate this. Instead, I'll ask "what areas of development do you enjoy", or "what areas do you wish you had an opportunity to learn more about". The goal is not to trick people with dumb gotcha questions, but (for me) to figure out where their passion is. I prefer a positive approach of "what are you passionate about" as opposed to a negative approach of "what are your flaws". At Paylocity, we don't ask people to do what they're bad at, we ask them to do what they're good at - i.e. play to their strengths, not their weaknesses. Also, the interview should be an indicator of what the company is about, and what kind of company goes around asking their employees "what do you suck at most"?

 

Published book: A Crash Course in Reasoning

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

Clear reasoning is essential for developers. So, I'm proud to have finished publishing a book "A Crash Course in Reasoning".

 

 

It's a fast read (170+ pages), in plain language. Really it's intended for high school and college students who are looking at basic reasoning skills (i.e. I have kids and I'd like them to eventually read it). However, developers may get a kick out of it too. It covers a broad spread of topics:

• Chapter 1: Introduction

• Chapter 2: Objective Reality

• Chapter 3: Premises

• Chapter 4: Logic

• Chapter 5: Epistemology

• Chapter 6: Communication

• Chapter 7: Psychology

• Chapter 8: Learning

• Chapter 9: Conclusion

Official abstract:

Using images, tables, and constant examples, this book provides a practical and plain-English introduction to reasoning. We start by emphasizing the importance of objective reality. We then explore the different types of premises (definitions, observations, given facts, assumptions, and opinions) that can be built on this rock-solid foundation. From those premises, we can make logical inferences (both deductive and inductive) to arrive at conclusions. We strengthen this process by explaining several epistemological issues. Once the reasoning is clear in our own head, then we can communicate it to others. As we deal with other people, we’ll also need to deal with the psychological aspects that people inevitably bring with them. Finally, thinking clearly for ourselves and with others, we’ll want to apply everything we’ve discussed to increasing our learning and problem solving abilities.

This page will contain updates for the book.

MVC troubleshooting: If the controller doesn't have a controller factory...

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

I was toying around with the MVC pattern, and I kept getting this error while doing a tutorial:

 

'TaskList.Controllers.HomeController'. If the controller doesn't have a controller factory, ensure that it has a parameterless public constructor.
 

I'm no MVC expert, so I had to poke around a little. Ultimately, what seemed to fix it was making the database connection key in web.config match the key in the auto-generated dbml code.

 

The dbml code was failing on this line (in a file like "*.designer.cs"):

public TaskListDataContext() :
base(global::System.Configuration.ConfigurationManager.ConnectionStrings["TaskListDBConnectionString"].ConnectionString,

mappingSource)
{
    OnCreated();
}

I had modiefied my web.config, so there was no ConnectionString setting for "TaskListDBConnectionString", so that returned null, hence it failed. I needed to update web.config to something like so:

 

   

    name="TaskListDBConnectionString"

    connectionString="your_connection_here"

    providerName="System.Data.SqlClient"/>

 

To troubleshoot, I started stubbing out things one at a time - making an empty solution, downloading the final code, comparing the differences, etc...

 

"I prefer my way of doing it to your way of not doing it"

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

I once heard this quote - I forget the context or who said it - but I really like it. Software Engineering is full of second-guessers and Monday-morning quarterbacks. Many projects seem to have that pessimist who snubs the teams' attempt to do something because it's not as good as that "perfect past project" that they were on. There's something to be said for the developer who just gets it done - even if the code isn't the best.

More Xml Design Patterns

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

 

Last month I mentioned some tips for structuring xml, which could be seen as the start of primitive Xml Design Patterns. Here are three more ideas.

 

Strongly-typed nodes

 

Say you have a node, which can have several different groups of attributes. For example, you're making a test automation DSL, and you need to assert that various conditions are met. You may have a basic assert, a correct-page assert, and a text-search assert:

The schema for this becomes messy - you'll have one node (Assert) with all possible attributes. Your interpreter will need to infer which action to take based on the current attributes. Validating the xml file also becomes error-prone. It's doable, but messy. Compare that to this:

.Page pageName="myPage.aspx" />

.Text textToFind="EmpId123" isRegex="false" isCaseSensitive="false" />

This approach has essentially three nodes: Assert, Assert.Page, and Assert.Text. This effectively gives you "strongly-typed nodes". Your interpreter instantly knows which type of node, and therefore what action it expects and how to validate its attributes. Your schema becomes simpler because each node type has only the relevant attributes. This isn't always the best approach, but it can be a good one in certain cases.

 

 

Serializing complex objects to attribute strings

 

You can serialize almost any object to Xml, but the question is what is the best way to do it? For example, you could serialize an array as a bunch of nodes:

   

        12

        35.5

        40

        9

   

However, this is somewhat bloated. A more concise way is to serialize it to a string, and then store the results in an attribute:

You could serialize an array as a CSV list: "1,2,3".

You could serialize a name-value pair: "name1=value1;name2=value2" (this is what MSBuild does)

You could even have a mini DSL, like the Silverlight path expressions: "M 10,100 C 10,300 300,-200 300,100".

 

The main thing this approach requires is an easy way to serialize and deserialize the object to a string. If you've got that, then this technique becomes very reasonable.

 

 

Abstract complex objects to inner content

 

Silverlight uses Xaml markup to describe the UI. Xaml allows a lot of style markup.

 

You can create a simple ellipse, shading the entire thing a solid blue.

Fill="Blue" />

However, you can also give it a more advanced two-color gradient shade by abstracting the "Fill" markup to the inner nodes of the ellipse. Specifying a single attribute is great when you can serialize all the necessary info to a single string, else you can leverage the more-powerful inner xml nodes (per a Jesse Liberty tutorial).

   
     
        
        
     
  

This allows the best of both worlds - the single-line common case, and the more advanced case.