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.

The Art of Agile Development - automation

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

James Shore, a huge agile leader, is writing a book The Art of Agile Development. He's previewing chapters to get user feedback. His chapter Reply On People encourages developers to play to their strengths. He had a good point on automation, to paraphrase:

Most people don't like repeating tedious tasks, but many devs would find it a creative challenge to automate that same task. It's a good way to show how automation is a win from so many angles - more interesting for the developer, more effective in the long run.

 He's obviously got a lot more gems in that book; I look forward to it getting published.

Good book: The Pragmatic Programmers

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

I recently finished a good book, The Pragmatic Programmer, by Andrew Hunt and David Thomas. (I had read their Unit Testing book a while back).

What I liked to much about it was that:

• It really was practical
• Andy and Dave are good writers, with a down-to-earth style
• It transcended the current technology (much like Code Complete)
• It addressed a huge range of topics, from automation to testing to team culture. Software engineering isn't just about a lone-wolf developer typing the write code. Rather, it requires a huge breadth of skills and process.
• It boiled things down to specific tips.
• It pretty much takes a bunch of lessons that I learned the hard way and presents them.
• It's short - maybe 250 pages (not including appendix, references, etc...)

I wish I had read this five years ago.

What would it take to be twice as productive?

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

Often you can improve the future by learning from the past. Given that we always want to be able to develop faster (given the same level of quality, energy, etc...), it merits reflecting on the question: What would it take to be twice as productive?

Here are some general ideas I was thinking about:

• Better tools (like a CodeGenerator or Resharper)
• Better hardware - a fast machine, dual monitors, perhaps even a spare virtual machine that you could upload code to to run long-duration tests without blocking your main dev machine.
• Reusable components - business logic, validation, UI components. No need to waste time re-inventing the wheel.
• Knowledge transfer - like having a good, quick wiki, or technical/domain experts to trouble bottlenecks
• Prevent and handle regression testing - such as code reviews to ensure higher quality code, as well as comprehensive suite of automated unit tests
• Better automation - ideally you can automate anything tedious that steals your time, like checkouts, tests, code generation, continuous integration
• Taking time to think first before coding - i.e. "code now, fix later" is more than just a moral killer, it also kills the schedule

There's a lot of things that are more standard, that I'd hope any developer would have:

• Good source control system - no one wants to waste time because they lost their code, or had a merge error, or can't track something down
• Issue manager system -
• Good project management to coordinate the team and give everyone clearly defined goals.

There's obviously a lot more. What would make you a faster developer?