Nine Things Developers Want More Than Money

Nine Things Developer Want More Than Money

Read if you're a developer and wondering what's missing from your job.

Read if you're a manager and you're looking to recruit the right types of developers.  In particular be honest with yourself over whether your organisation is more aligned to "hygiene" or "motivation".  At least one of the poor job decisions I have made is because the role was mis-sold as one and turned out to be the other.

Working Environment

How important to you is your working environment?

 - Type of desk
 - What's on it
 - Position / type of mouse, keyboard, monitor(s)
 - Music / background sound (or lack of it)
 - Open plan vs team room vs cube vs personal office
 - etc...

These physical items could be extended to include your virtual environment:
 - Eclipse / IntelliJ Idea / Visual Studio (is it still called this?) / other dev enviornment - setup, preferences, window positions
 - OS
 - Desktop icons - do you care what / how many / positioning
 - Which software is always open when you're working, and does it matter what order you open them in (so they're in the correct place on your task bar) (additional: does not having enough RAM cripple you because you have to constantly shut and re-open software?)

How anal are you about setting these things up and getting them just right before you can start coding (or whatever it is you do)?

This post comes to you courtesy of my irritation with my chair.  I want to code cross-legged today and my chair does not adjust in the dimension required to provide me with enough space to do this.

Amazing!

Today, I found my own blog useful.  I was configuring Spring validation on my new project, and had to remind myself how to do it.  We configured validation on the new project in less than an hour, which beats the two days it took me to work out how to do it the first time.

And I impressed one of my new work collegues.  Apparently I am now the Spring Guru.  Oooops.

Multiple Environment Configuration in Maven

Today, I found this blog post very useful.

On the perils of Front End Design

I'm reading Joel Spolsky's User Interface Design for Programmers. A thought that's struck me is about architecture. It's easy to get fooled into thinking building software is a bit like being the architect for a building. I'm not even going to go into the differences between engineering practices à la building design and good practice software design. I'm going to start from the easy point, the stuff you can see.

There's often a pressure from your designers, from your steering committee, even from your CEO, to make your software look "pretty". I, too, with my DTP background, occasionally fall into that camp. You know, slicker fonts, curvy edges, funky this, fancy that.

And you can look at buildings like the Woolworth Building, and think, "I want my software to be the equivalent of the Cathedral of Commerce". 

But for all its Gothic detailing, its flying buttresses and gargoyles, you can still find the entrance. You can still find your way to the elevator and up to the floor you desire. The magnificent detail does not obscure the use of the building.

The same cannot be said of user interface design. You don't simply wander past / through an impressive facade, whatever you think the "skip" button on your flash intro is supposed to do. The decoration, the clutter, is right there in front of the user, the whole time they're trying to DO something.

Do architects design their entrances flush with the walls and the same colour?
Are entrances to basilicas hidden behind flying buttresses?

No (generally). Because the design of a building is supposed to enhance the "user"'s experience, not get in the way of it.

If you're playing with acres of land there's a lot of detail you can fit in that won't hinder the ordinary person. In fact, rather sadly, many of them won't even notice it. If, however, you're coding for 800x600, or even if you're coding for a wide-screen Mega Television of Doom, there's limited space available. You want to make sure the "nice-to-haves" don't get in the way of the user's "must-dos". You want to make sure your entrances (buttons, links etc) are well marked.

You don't want to find you've spent an awful lot of money on something that goes unused.

Job Hunting

I've learnt a lot professionally and personally during my time here in New York, but the time has come to go back "home".

I'll be relocating to London in September. I guess it won't hurt to mention on here that I'll be looking for an exciting new job when I get back there. Check out my LinkedIn profile if you are in the market for a Java tech team lead.

Scrum

I think the statement that struck me the most when I was on the Certified Scrum Master course was: the start of the project is when you know the least about what you're doing.

Which of course is absolutely true.

So why do we come up with extensive requirements, detailed design, and fixed plans at this point of time?  We haven't put anything into place yet, we haven't played with the code, the customer hasn't seen anything of what we're promising to deliver.

If we think about it this way, suddenly the waterfall method makes even less sense (assuming people do still like to work this way).

How many times have you just played with a bit of code, done a prototype, a "hello world", knocked up a basic screen, before you can even give your manager some finger-in-the-air estimates?  I don't know about you but I'm not comfortable unless I have played a bit to get the feel of something before even looking at someone who asks those questions!

The empirical approach makes a lot more sense to me.  So why aren't we doing it more?  

Because it's harder.  

I think it's harder because it works, but I daren't make such a bold claim without having a number of such projects under my own belt, or at the very least digging through the web to find examples.  Which frankly I'll leave to you to do, if it matters to you.