What motivates us.

Whats the motivation level in your project? Are your coders roaring to go each day or they just try and slough true. Daniel Pink in his book Drive: The surprising truth about what motivates us give us some amazing insight that it's probably not the money.




In the video he talks about 3 main things that motivates people, Autonomy - The desire to be self directed, Mastery - The urge to do better or get better at something and Purpose - The need to feel that they are doing something meaningful.

Jurgen Apello in his blog post People Motivation: Target Intrinsic Desires talks about the same things in a slight different form, he talks about Competence, Autonomy and Relatedness (Self Determination Theory).

See a pattern here? Autonomy appeared twice, Competence = Maestery and Purpose = Relatedness. Nothing about money, nothing at all. Surprising ? Not really, remember there's this old joke about it's lucky that our employers are paying us to do what we love, if not we would have to start paying them. I guess that dosen't just applies to programmers, it applies to all who truly love what they are doing. I know not everyone has the luxury to do what they like, hopefully for them they will find their little niche in life.

So managers think about this. How can I give autonomy to my team and how can I stand behind them to ensure that the autonomy is being exercised.

We've got a domain stephenonsoftware.com!

Now you can go to stephenonsoftware.com and It will redirect you to my blog spot address, this is to make it easier for you my readers to quickly find my page, and also in the event that I decided to host my blog on my own instead of using blogger there will be one consistent address for you to find me.

If you are interested in my blog, please subscribe using RSS using the links on the right or by clicking here. This will ensure that you will always get my latest updates.

Why I love programming!

I am fortunate to be one of those who love programming and get to do it as my day job. But why? Why do people who love programming love it ?

I guess it just a desire to create! To keep learning! It's fun, To make the world a better place!

I started with my first PC a 486dx2-66 with 8megs of RAM and DOS 6.2 at age 14-15, it came with QBasic and i got a book on basic and started hammering things like Print "Hello World", running the nibbles and gorilla examples. The only neat QBasic program i did was this mini paint program using my joystick as a means of control.

I thought at that time whao it would be great to write games for a living, my inspiration was from games like Ultima, Wing Commander. I picked up a book The Black Art of Visual Basic game programming, learned about timers and how to bitblt and do XORing get transparency effect. All i really did with that knowledge was to create a sailor moon screen saver.

At this time i was already in a Polytechnic doing computing, picked up C and C++ there and for my final year project did a multiplayer, sort of dungeon game with DirectX and DirectPlay. There was this bug in my game and it kept crashing and I suspect that it was because of the screen update thread and my DirectPlay updates from the rest of the players was interfering with each other. So i basically need to do a thread safe implementation of my linked list (I rolled out my own c++ template linked list implementation at that time). I thought that was pretty neat, I mean at that time I didn't know much about STL, i just tried to apply stuff that I learnt in my Data Structures classes and my Threading classes to my project.

During the same time Window 95 was the cool OS of that day and I wrote a Windows 95 theme creator in VB, I put it on the net, I couldn't remember where I put it though and i lost the code to it. Never really expecting any one to go download it, but surprise ! Someone did downloaded it and even emailed me that he liked it. That was the first time some unknown person wrote to me and told me they liked what I did! Someone actually like my stuff !

I went on to university doing computer science, and went to join the Navy nothing to do with programming whatsoever, sailed around for 4 years, during that time wrote little pocket pc applications to help in my work on board the ship. After my tour in the Navy was over, joined the government sector and now doing mainly Enterprise applications using Java and also some GIS work. 

The transition from my previous career in the Navy to now a professional developer job was not too easy, stuff in the programming world moves so fast, When i left the University it was Java 1.2, when i came back Java 5 was there. Lots of stuff changed too, Light weight frameworks like Spring were fast becoming standard in lots of places. The stuff I learned in school regarding Web programming was outdated (I programmed everything in the JSP pages in those days), but I guess that didn't deter me from jumping back into programming because fundamentally programming is all about using Sequence, Selection and Iteration (as quoted from Uncle Bob in his Keynote) and solving problems. Besides I love programming ! I picked up stuff on J2EE design pattern, OO design patterns, read and learned about Agile and liked what they preached about putting users first and having working software. Hopefully can put more of that into practice with my team.

The same joy that I felt when I was younger was there (okies I am not that old), I still feel it now in my job, the feeling of creating stuff, solving problems and learning are all there. When my users tell me that they liked what I did for them, i felt the same joy as when the email from the person who liked my Win95 theme designer.

Now that I am now the father of a very active 8 month old daughter and moving onto a more senior and kind of half technical and half management role in my team, time for learning and tinkering at home gets lesser but I still try to read at least one work related book each month. Currently I am reading The Art of Lean Software Development and The Toyota Way to get some insights on Lean software and Lean thinking. I am playing around with Common Lisp, trying to write a small game, learning Clojure by reading Programming Clojure because I think that functional programming may be the way of the future and beside that it's fun to learn about stuff like Homoiconicity, multimethods and a whole new way of thinking, I am also playing around with Google App Engine in Python (Cause I love Python!), trying to code some stuff that I will tell you later when I am more or less done.

 

In short I love programming because I love to create things, I love to learn and its fun, hopefully in the process, I have made the world a better place for some people.

Tips for a better continuous integration environment

All of us have a build server right? Here's some of my personal tips of getting the most out of it.

1. Write your own build scripts

Eclipse and Netbeans do provide some form of a automatic build script when you create the project, but I advise you to do your own since the scripts they automatically generate are usually very complex and if you want to build in automatic static analysis or some code coverage (Findbugs,Cobetura) tool it might be difficult so just go do your own.

Make your script run the unit tests also and put the report on the build server's dashboard.

2. Do not check in dependencies

If you project depends on your project teams module, it might be tempting to just get him to pass you the module and you check it in with your project. This is bad, cause when he updates his code, he will need to generate another jar or dll and pass it to you manually.

Better is for you to check out his code and link it through the ide, this ensures a few things, first you just need to do a source code control update and build. You are always kept updated no need for your colleague to keep passing you things and then your build server will run much better.

But then how will your build server when running your build job knows how to get the dependency?

3. Manage your dependencies

Unless your build script for your main project knows how to build all your dependencies first then built itself, but that would make for a complicated script. Why not use a dependency manager like Apache IVY. Everytime your build server builds successfully the dependent libraries, it publishes it to a ivy repository. Then when you main project builds, it gets the dependencies using ivy and builds itself.

4. Make known the status

You want your developers to know the status of the latest build, most CI servers have some sort of RSS, XMPP or you can even link it to lava lamps to get the status. The important thing is to make known that the build is broken and get to fixing it. The place it work uses spark so we use Spark messages to inform the team that a build is successful.

5. Deploy automatically
If you are writing a web application, deploy it automatically to your app server so that your PM or others can have easy access to it. You can even run UI tests on it using Selenium.
For tomcat there are ant modules available, for Weblogic you can script them using the WebLogic scripting tool.

This also has the added benefit that you can compile, build and deploy in one step, cutting down lots of time.

6. Build installers

For thick client kind of application, automate the building of the installer. You can even build different kinds of installers, i.e Mac, Windows, Linux if there is a need.

Vision, Act, Now ! Quotes from the president of IBM

http://en.wikipedia.org/wiki/Thomas_J._WatsonI was reading The E-Myth Revisited, a book about managing and running small business to ensure that they succeed. Not that I was about to run a small business. But rather I was reading business books to learn about how business work and management besides the usual tech stuff that I read. (I am also reading Lean development nowadays).

The below was from Thomas Watson, the president of IBM. Below are just the important extracts.

IBM is what it is today for 3 special reasons.

The First reason is that at the very beginning I had a very clear picture of what the company would look like when if was finally done....

The second reason was that one I had that picture, I then asked myself how a company that looked like that would have to act. Then I created a picture of how IBM would act when it was finally done.

The third reason IBM has been so successful was that once I have a picture of how IBM would look when the dream was in place and how such a company would have to act. I realized that, unless we began to act that day from the very beginning, we would never get there.

If you have a vision for how you team should be and what practices that should do to achieve it, then please do something about it NOW ! I guess most of us are pretty clear about what some of the good practices are (XP, Agile, Lean ... and so on), already, that's why you are reading this. Even practices like Peer Review, TDD that have been proven to produce better quality code, but few project teams seems to implement them. The most common kind of excuse is that "Yeah I know its good but its not gonna work in my place due to ... " substitute that with things like company policy, work culture, then people around you etc.

The way to succeed is to double your error rate.
Thomas Watson

I have some vision of how now I would like my team to be like, the only thing left for me is the hard part, that is to ACT NOW! Even if something don't work out at least i know i tried.

If you want to achieve excellence, you can get there today. As of this second, quit doing less-than-excellent work.
Thomas Watson

Even if not every one accepts the practice do it yourself, and prove the value of what you are doing. Sooner or later it will be accepted.

Tips for being a better programmer

1. Read, Read, Read
Read a lot, read stuff books, blogs whatever. Subscribe to blogs so that you will learn something new everyday.

Read other peoples code, I mean read good code, for me I read some parts of the Spring MVC and Spring Security modules code to better understand how it works and I sometimes amazed at how clean the separation of the different modules are. Reading bad code, cause you will never want to do the things that guy did.

Read about the history of programming, it's quite a shame that most programmers don't really know much about its history. You can watch Douglas Crockford's video to get an idea of where all these came from.

2. Try Try Try
But its not enough to read, you must try! If you are a OO try try functional programming, if you are a functional guy, try OO. Try web programming if you mainly do desktop apps.

Don't try with something trival! Like printing HELLO WORLD. Try and solve a problem.

See a problem? Suitable for writing a small project? Go ahead and try it! I always try to keep in mind a few such problems so that I always have something to do if I have some free time. And by trying it in a context of a problem you can see what value the new tool/framework/language can bring to you. You need to develope your toolbox so that everything you see will not be a nail.

Interested in Google maps ? Write something with Google map!

3. Be Clean

Write clean code, leave the code a little bit cleaner than when you came. Uncle bob's Clean Code, is a great book about how to write better code, read about the SOLID principles while you are at it.

4. No "I" in team
We work in teams, very few of us that are doing this for a living work solo. Learn to be a people person, I remember during my high school days, an image consultant came by to teach us how about color and clothes and etiquette and she emphasize the importance of people liking you, because if people like you they will be willing to teach you even if you are not very good. Dale Carnegie has a nice book on the topic, How to win friends and influence people.

Many a careers are sometimes determined by not how good you are technically but how you are as a person.

5. Be through (or at least try to be)
What can be more frustrating then someone coming up to you and say "Hey the webservice didn't work", and when you probe further you found out that he didn't know what exception caused it because he didn't bother to check the logs. He just comes up to you and expect a magical answer.

Well try to be through in solving a problem, at least your lead or your manager will appreciate that you have at least tried to find out the cause.

6. Know your users domain
Know the domain be it accounting, customer service, military, will aid in you communicating with your users. It makes talking with them so much the easier.

Things i wish my Project Manager can be like

Don't delegate ... if you can
Don't delegate your stuff to your underlings, first see if you can do them yourself, unless its really for the learning experience. Look deep into the reason why you are delegating, don't do it because you are lazy or afraid to do  Try to be the remover of impediments instead of being the impediment. Context switching while doing programming is expensive, in fact context switching between any task is expensive.

Try to understand the project technically. 
Having a overall picture of the system is a what a PM should have but if possible try to look at the code, understand whats new in the programming world. Understand terms like Web services, SOAP, REST, XSS, XRF, Sql Injection and what they actually mean instead of some high level definition. But it does pay off, imagine during stand up meetings when the developers are telling about what they did at least the manager have some understanding of where things are going, where the technical challenges are.

if your last programming effort was in the good old client server days, read up a book on enterprise patterns like service locator, DAOs and program abit. If possible see if there is some very low value function that takes little story points/mandays and try to implement, your developers will have a new found respect for you, and it cuts down the time after stand up meetings where you ask the developer what he meant when he said all that.

Be a people person
Face it you are now longer dealing with computers anymore, you are now mostly dealing with people, go learn how to deal with them, how to negotiate, motivate. Learn what makes them tick.

Most project managers are there because they are good programmers or good technical leads. Not many are there because they are great managers. Go read books/blogs about human behaviour and how to motivate them. So books that I liked are Drive: The Surprising Truth About What Motivates Us, Peopleware. Read books on leadership and management. All managers should make learning how to deal with people a top priority.


Wouldn't it be nice to have a PM that can fire you up and make you do your best ?

Look ahead and Take charge.
Managers can't anticipate all problems but it helps it you are looking out for them rather then hoping everything will go according to plan. Take charge when you need to, nothing is worse then having a boss who is indecisive. It affects the team if they are constantly having to put out fires all the time.