Tool: Microsoft SQL Server Database Publishing Wizard 1.1

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

I was experimenting around with some starter kits, and I came across this good, free tool - Microsoft SQL Server Database Publishing Wizard 1.1. Basically, it can write a database schema, and data, to a sql script. I think it has a command line API too!

 

I found this useful when trying to deal with some database in a starter kit that I couldn't access outside of Visual Studio. I wanted to be able to script and extend it. It was in an ASP.Net 2.0 app_data folder. I'm sure there was a way around it, but this approach seemed so much faster for me. I scripted the database, and then re-ran the script in SQL Studio, and changed the asp.net db connection strings to that new database.

Paylocity is Hiring for a Software Engineer (in Chicago)

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

Our software engineering department is hiring again. This is a technical position, we're located in Chicago. You can see the job description here.

• Great Learning Opportunities: Working with cutting-edge .Net development (already migrated to .Net 3.5)
• Work-Life Balance: Local software department - no travel. Dress code is casual. Office hours about 8-5. We have laptops and can do extra work at home.
• Working from home twice a week.
• Job Security: Smaller company (175 people total, 30 in software department), so we're too small to be outsourced, and privately owned (and owner refuses to sell), so we won't be sold.
• Company has been profitable and grown every year (for all 10 years) - even during the IT crash we still grew.
• Interesting work: There are separate IT and Internal development departments. Even within our department there are separate QA and Business Analyst teams. Therefore you can focus on development.
• Great, collaborative team. Average person has maybe 8 - 10 years experience. Team is large enough that you can specialize in areas that interest you (UI, Business Tier, Database, etc...), yet small enough to still get an interesting variety.

If you're interested, just leave a message, or email me directly at tims@paylocity.com.

 

As an aside, Jeff Atwood has a great article on interviewing.

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.