Why would someone work for your company?

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

I mentioned last month how everyone likes to say that they recruit the best, but that's just silly. Not every company can all have the best developers. Especially in a good job market, it merits asking - Why would someone work for your company?

At Paylocity, because we're always hiring for top talent, we constantly focus on this question.

Ultimately, you need a niche, such as:

• High salary
• Enjoyable work - the company does the exact kind of thing you like.
• Brand name recognition - i.e. the opportunity to work for a Microsoft, Google, Amazon, IBM, etc...
• Good work-life balance
• Job security - such as a government job where you likely won't get fired.
• Good learning opportunity - like consulting companies that fly you around the country to work with the latest and greatest technology
• Future potential - maybe a startup that you think will hit it big
• Good coworkers - whether it's just team chemistry, or there's a star you want to work with (i.e. ThoughtWorks having Martin Fowler)

In my experience, most companies think they have most of these things when they don't. Sometimes they think they have enough of some niches such that they don't need others (i.e. "we don't need competitive salaries because we have XYZ instead").

Obviously big salaries are the easiest thing to point to. Hiring managers may insist they can't get good recruits because their budget simply doesn't allow them to be competitive -  and there's substance to that. However, the interesting thing is that several of the things on this list can be addressed without your CXO changing their budget:

Niche	How to get it without changing your budget
Enjoyable work	Focus on new problems and process, and not repetitive, copy & paste tasks. It's a win-win: developers will like the challenge more, and managers will like the better code that results from it. Managers can try delegating work items to developers based on their interests.
Good work-life balance	Giving developers laptops lets them work from home. I've found that people are far more willing to do "homework" in the evening (after they've had downtime or dinner with their families) in the comfort of their own home, as opposed to staying late at the office. It also gives you the option of working from home. For example, at Paylocity we often let developers work from home on Tuesday and Friday (we use laptops and instant messenger, and we have mature developers who don't abuse this). If you're firm doesn't require travel - it's much easier.
Good learning opportunity	Good developers have the intrinsic need to grow and learn. Managers can champion having estimates that include even a 5% research cushion, purchasing a requested technical book, or making the business case to upper CXOs how the new technology helps the bottom line. Any manager that stifles that for any reason will simply push their best developers away. Such excuses may include: "we don't have time", "that's not in the requirement", "just do it this way because I said so", "this approach worked 5 years ago", "your job is to support the business, not research technology", etc...
Good coworkers	A manager has tremendous influence over their team. First, they can lead by example - not gossiping, respecting team mates, not showing favoritism, etc... They can also refuse to hire someone who is socially incompatible (i.e. don't hire a jerk), such that the team doesn't get tainted. If a people-problem does arise, such as someone sends out a dumb email or makes an inappropriate comment, a leader can proactively isolate the incident and encourage quick resolution (as opposed to "waiting to see what happens").

 

I'm proud to say that at Paylocity, we do these things - we work with cutting edge technology, have an amazing work-life balance that allows developers to stay mentally fresh for long-term development, always encourage learning, and have the best team chemistry I have personally seen.

 

---

Living in Chicago and interested in working for a great company? Check out the careers at Paylocity.

Why are the good devs ten times faster than the average ones?

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

A lot of developer commentators point out that the best developers can easily be ten times as productive as the average ones. Why is this? I think for two main reasons:

First, unlike many jobs that are limited by physical ability, a developer is limited primarily by their own thought, which has a much broader range of ability. In other words:

1. Humans are physically in the same range. An average person may be able to list 200 lbs, a very strong person may be able to list 400 lbs, or about twice as much. Look at every physical record - how fast people run, how precise they throw, how balanced they are, and the range of people's abilities is a relatively narrow spectrum.
2. Most jobs are limited by physical ability. This is obvious for manual labor jobs, but even other jobs - a salesperson can only be in one place at a time, or a cook can only work as fast as their hands let them. Sure someone who knows what to do will do it faster and better, but you're limited by how fast you can physically do certain tasks.
3. Software engineering is limited by your mental ability. While you need to physically type code in the keyboard (and there are shortcuts for that), most development time is spent thinking, not typing. You can essentially code as fast as you can think. And unlike traditional jobs, you can essentially use more than two hands by automating processes on other machines, using code generation, refactoring your code, making reusable libraries, etc...
4. Mental ability varies far more than physical ability. A smart math student could multiple solve an equation ten times faster than an average student - if the average student could even solve the equation in the first place. Practically, your best developers will solve problems that your average developers lack the ability to even describe, and thus potentially would never solve. For example, I sometimes read the CLR blogs at Microsoft, and I don't even have the background or depth to describe the problem domain, let alone solve it in a timely manner.

So, fundamentally, software engineering is not traditional physical jobs where two average guys can build something as fast as one good guy. There's a similar phenomena for all "Thought Work". For example, the best books sell 100 times more copies than the average ones.

Second - in software engineering, because there is such a low entry bar, there is a huge gap between the amateurs and professionals. For example, in order to become a Civil Engineer, you'd first need to go through several years of schooling at a credited University. There is a high bar to meet. But many "programmers" just start playing around with Visual Studio and gradually move from hobbyists to full time developers. So, practically there are a ton of developers out there that have the mental ability, but just lack the training and education such that they're not nearly as productive as star developers. 

---

 

Living in Chicago and interested in working for a great company? Check out the careers at Paylocity.

Recruiting the best

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

I really like this article from Joel Spolsky about recruiting the best: http://www.inc.com/magazine/20070501/column-guest.html

I especially like how he emphasizes that the best developers are more than 10x as productive as the average developers.

Why the "not-built-here" mentality

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

A lot of developers have the "not-built-here" mentality - i.e. they only want to use code that they (or their department) built themselves. Here's a brainstorm of some ideas why:

• Concern that external component won't actually work or fit their needs
• Too difficult to customize
• No fun to just plug in someone else's component - devs want to build it themselves
• External components often have license fees (turns off managers and business sponsors)
• Too many unintended side affects (i.e. an AJAX web control that can't handle being on a page with a postback)
• Developers think that they can do it better than the external component
• Fear that product won't be maintained (perhaps from a bad customer service experience)

Of course the benefit of using a third party control (especially an open-source one) is that it can save you a ton of time, potentially give you things that you could never build yourself, and provides you something far more standardized.

Programmers who can't program

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

I've lost track of how many "senior developers" I've interviewed who fundamentally can not program. Their resume makes them sound like the next Bill Gates, but they can't write 5 lines of code on a white board. (Jeff Atwood discusses this on his blog). I'm not talking about knowing useless trivia like the 19 overload signatures for StringBuilder, but rather core programming concepts like writing a for-loop or if-then structure.

Many devs are great at telling their credentials ("Yes, I have experience in C#") or simple fact regurgitation ("A DataReader is faster than a DateSet"), but they don't want to actually think. I expect this relates to Bloom's Taxonomy, namely that there are several tiers of thinking: mere knowledge (i.e recalling facsts) is easy, analysis and synthesis (what writing code requires) is hard. Someone one joked "Thinking is hard, which is why so few people do it." A related trend is that many people think that "coding" means "copying the right snippet from a Google search."

At Paylocity, every developer writes code each day, so any interview candidate is also required to write at least a trivial code sample.

What sorts of mistakes do interview candidates make:

• Compile errors
• Bad logic
• Ignored important boundary cases. -
• Code works, but it awful performance or hard to maintain

Why may this be?

• Some developers never really write code from scratch to begin with, they just tweak existing code or copy Google snippets.
• Some developers can't write code on the whiteboard because they're completely reliant on the IDE, intellisense, reference guides, and compiler to hold their hand for each line. They can't write code on paper because they never have before.
• Some devs only program by coincidence (constant trial and error until "that result looks right, so my code must work"). Writing code from scratch on the whiteboard is pro-active and deliverate, not just a coincidence.
• Extensive use of wizards, drag & drop, out-of-the-box functionality.

What can a candidate due to practice?

• Actually write code snippets on a whiteboard or paper - away from the comfort of a IDE.
• Write small code snippets from scratch in your IDE to solve a specific problem.
• Check out some of these samples: http://www.spoj.pl/problems/classical/
• Check out the "exercises" section at the end of your local C# book.
• Make sure that you can at least do the basics like:
  • public static bool IsEven(int i)
  • public static int Factorial(int i)
  • public static bool DoesArrayContainValue(string[] astrList, string[] strValue)
• When you're actually giving your answer in an interview, step through your thinking process, as this is what the interviewer is really after. It will also make them much more lenient on a trivial error if they know that you have the important concepts down.

What are the interviewers really looking for? Obviously the real code you write for a job is much harder than the above trivia. Interviewers want to see your thinking process and style. Do you think first or just whip off an answer? Can you communicate why you wrote what you wrote? How did you determine your algorithm?

This is what software engineering cares about, not if you've memorized soon-to-be obsolete trivia. I'm glad to work for a company that gets this.

What would it take to motivate you to work overtime?

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

Exploring an interesting technical concept after hours, it made me wonder: What would it take to motivate you to work overtime?

Some ideas:

• Personal Enjoyment - You fundamentally enjoy what you're doing. With many developers (like myself) I find this to be the case. If you enjoy researching a new technology or writing a challenging tool, then that's motivating enough.
• The job needs to be done, and you need a job. I saw this a lot in consulting, especially during the recession a few years back. Sometimes the only way to stay employed is with long hours.
• You're on a roll. You may not totally enjoy what you're doing, but things are just working and you can get a lot more done right now then tomorrow morning, so why stop.
• Knowing that you'll make up for it later - perhaps you'll get something ugly out of the way now so that your hours later will be easier.
• Financial reward - bonus or overtime pay. This seems the normal in traditional business, and is also somewhat sad, especially if you don't like what you're doing.
• Peer pressure - I saw this a lot in some consulting gigs; where 70-hour weeks were a badge of honor. This is really sad.

I'm glad to say that at our software development department in Paylocity, it mostly seems people work overtime for the first and sometimes the second and third reason. (If you're interested in working for a great company, check out our careers here.)

Government Forms

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

I recently had to submit a form to the government, and it lived up to its bureaucratic stereotype:

1. I needed to print out a physical hard-copy, and make a duplicate.
2. Unclear directions
3. No validation to ensure that I filled it out correctly.
4. I mailed the form, waited 4 weeks (no way to see what the status was)
5. I get the form back in the mail, with a letter saying that I missed one line on one of the duplicates, and please re-submit the whole thing.
6. I sent the form back in the mail... waiting.

It seems like this was how most processes used to be, and it makes me appreciate how convenient and fast web applications are today - online version, dynamic help, validate before you submit, and instant results.