How to discourage a developer from working overtime

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

A while back I pondered what it would take to motivate a developer to work overtime. I was thinking about the flipside of that - what would discourage a developer from working overtime?

• Constantly change the feature on them - This can be like pulling the rug out from under their feet. I saw this all the time in consulting - for some projects, everything was "of absolute importance". People get burnt out and stop being motivated. After all, why waste my evening plowing on a feature, if the whole thing is just going to be scrapped tomorrow at some executive's whim?
• Assign boring tasks - This speaks for itself.
• Provide slow hardware - Not having the proper tools to do your job is just demoralizing. Imagine your manager with a slow laptop - would they wait 60 seconds while their machine freezes when they try to send a single email, or wait 10 seconds every time they clicked a new cell in Excel? Of course not, they'd get furious about how such a slow machine prevents them from effectively doing their work. Same thing for developers - every time a laptop freezes when you try compiling, getting source code, or running tests, it just demoralizes and frustrates the developer. Yes, savvy developers can optimize their machine, but at the end of the day, the .Net development environment has certain hardware needs. For example, it's just wasting their time asking a developer to work on a machine with only 1 GB ram, or 5400 rpm hard drive, or a 1 GHz processor. They'll spend idle time throughout the day - constantly losing their rhythm. The manager saves a few hundred bucks, but both demoralizes their developer and diminishes the return of a $100,000 resource (total cost of the developer = salary + benefits + other stuff HR could tell you about). It's an absolutely clueless business model.
• Never reward positive accomplishments - Management can offer "non-monetary" rewards like verbal affirmation, or allotting schedule time to pursue a promising research project.
• Waste their time during the normal work day  - If a developer already "wastes" time due to excess meetings, pointless issues, rework from original bad design, or waiting on a slow machine, why would they spend their own evening to "make that time up"  - time that should never have been taken from them in the first place.
• Assign them to a "sinking ship" project - Some projects are fundamentally screwed - the core architecture is hopelessly lost, or there's already a run-away bug list, or the spec is unstable (or even contradictory). There's little motivation to work on this kind of suicide project.
• Have them do a task the hard way because the manager won't pay for the proper tools. For example, have a developer spend 100 hours writing an ajax datagrid, when you could just buy third-party controls for much cheaper. Or, have a developer scour through thousands of lines of database plumbing instead of using a code generator or ORM.

The irony of it all is that the rich get richer and the poor get poorer - i.e. A good environment will motivate the developers to work overtime (or at least be more productive during the day), hence getting farther ahead. Whereas a bad environment will constantly demoralize, frustrate, and slow down its developers, thus getting farther behind.

This is just a partial list - anything to add? What sort of things discourage you from working overtime?

Benefits of writing a new tool

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

I'm a big tool fan. I especially get a kick out of writing my own, custom tools - if it doesn't exist yet. Here are some benefits for writing your own, new tools:

• Very practical - A custom tool can fill a very practical niche, and let you complete a task much faster than the alternative. Usually if there's some tedious task that takes more than an hour, and I can write the tool in an hour, I'll write the tool to do it.

• You can consume it - There's something special about seeing your own code in action, especially when it's sparing you from a lot of tedious grunt work. I still get a kick out of running the MassDataHandler tool which makes it trivial to insert test SQL data.

• Small scale - If you're working on large (legacy) applications, whipping out a small tool can be refreshing. Some custom "throw-away" tools can be as quick as an hour to write.

• Huge variety - It's easy to get pigeon-holed into a specific technology or application framework. Writing a tool lets you explore areas of .Net that you might never get the chance to look at else wise. For example, some application developers might never touch reflection, diagnostics, threading (!), networking, or even streams because their application framework (usually written by someone else) abstracts those all away.

• You can share it with the world - Tools are usually isolated and self-contained (i.e. not glued to a huge framework), and hence easy to share. They are often business-independent, so you can open-source a development tool without revealing any business secrets.

Developer Scrabble

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

My wife and I were playing a game of scrabble the other day, and she was cleaning my clock. I kept staring at my random set of vowels and consonants, and thinking "Couldn't I please just use developer buzzwords and acronyms?" I'd bet the board would end up looking something like this:

 

Some random things I noticed:

• Normal English words and developer buzzwords use very different letters. For example, normal English words always have vowels, and usually have lots of E's and A's, while having very few X's and Q's. Developer buzzwords seem the exact opposite (think SQL, LINQ, XML, XAML, AJAX, etc...).

• Acronyms by their nature are short. So, lots of 3 and 4 letter buzzwords.

• Because developer buzzwords use the rare (i.e. high point-value) letters like X and Q, you could really build up a high score.

 

Book: Silverlight in Action

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

I've been excited about Silverlight since I first heard about it over a year ago. Because I started looking at it as an alpha technology, there weren't even the books out yet. So, I used the quickstarts, Bill Reiss's game tutorials, Jesse Liberty's tutorials, and other people's blogs. Well, the books finally started coming out, and I got a copy of Chad Campbell and John Stockton's Silverlight in Action.

 

I liked it. While I got a lot of the background from the online Silverlight resources, the book was just thorough, filled in gaps, and had really good chapters on transforms, animation, and resources (they finally just "clicked" for me).

 

It reminded me of the "good old days" when learning a brand new technology, and you just huddled down with a book and a computer, and hour-by-hour you kept learning something new. I think this book does a really good job of introducing developers to Silverlight.

New LCNUG website up

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

Check out the new Lake County .Net User's Group website!

It has several new features, including a job board, forums, and other community-building features.

The LCNUG is only 7 months old, and it's been off to a great start. It's been exciting watching it flourish.

Next month (January), the topic will be on NHibernate.

Super Mario in JavaScript (no kidding)

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

I am impressed - someone has ported a trimmed-down Super Mario engine to JavaScript. Wow. I was impressed with Silverlight because it allowed 2D game development and let you avoid writing as much JavaScript. Just wow, got to give credit where credit is due.

http://www.nihilogic.dk/labs/javascript-games/

LCNUG: JavaScript - Beyond the Curly Braces

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

Last night several people braved the potential snow storm to hear Sergio Pereira's good presentation on advanced JavaScript. Sergio did a good job of explaining advanced JavaScript nuances, but not dwelling on the obvious stuff. It's a difficult balance to strike because everyone has already heard of JavaScript, but few people know its many obscurities.

 

Sergio blogs at: http://devlicio.us/blogs/sergio_pereira/