Goodbye mails, moments

Saying goodbye is one of the most difficult things. And yet you know that it's a change which ought to happen. Someone said "I'm a passenger, and I ride and I ride" which is so apt to everything including life itself. Change brings new opportunities, new ideas, new lessons.

I'm in the middle of switching jobs and have said my goodbyes in person to many people I knew.  But writing a goodbye mail is particularly difficult; how do you put a decade of your life in one e-mail taking care it covers all the things you want to say and yet remain short enough for people to read it fully. I took my time: after couple of drafts, I had a copy which was ready to be shipped. The subject of the e-mail reflected my re-ignited admiration to the unix language. Got a number of replies and answering them as I write this post ....

Pleasures of the notice period

A notice period is the period between submitting your resignation and the last day at the job. In my case, the notice period is 2 months. Though it seemed pretty long at first, I must say it's needed or that I needed it; especially when you're trying to end almost a decade of your career. Therefore this dedicated blogpost!

At first I thought that this period would bring with it mixed feelings. On the contrary, those feelings have been only that of joy. It gives you the opportunity to look back at all those years; ponder on the memories, experiences and most of all - the people you've come in contact with. For me, it's that people factor that has brought the joy. I've been taking the time to talk to most people who've been a part of my life at my current job and during all of those conversations not only have I renewed my contact with the person but genuinely learnt more about him/her and created a deeper bond. These conversations are nothing like the many we've had in the past years. They bring something new - they're about motivation, passion and all of those things that makes you wanna work in this field.

My most cherished format has been the one-to-one lunches. And I have had many! Dinners and drinks reach a broader audience but aint as personal. Although I look forward to each of those moments. With less than a month to go and couple of evenings & lunches planned, I hope to bundle the last decade and store it in a very special place in my mind.

MacGyver and the A-Team

I have used this approach to successfully and sustain-ably implement the REST architecture. Yes, this blogpost is still about software development! The credit for coining these terms go to Ron Kersic.

Couple of years back we began with a new architecture implementation that involved RESTful services. As with most new things, the details were missing. The vision was clear - RESTify. But the mission and how to get there - NOT!
We chose for the Macgyver - A-Team approach to rescue us.

MacGyver phase
 
How this works is real simple. MacGyver, as most people know is someone who only needs a swiss army knife to put his scientific knowledge into action. For those who are from my generation and later could read up on this character here.
The MacGyvers in our case were a team of 5 persons; belonging to different specializations from an architecture point of view. I was the Design MacGyver. We set out making an inventory of stuff that is being handled by the current architecture and stuff that needs to be handled by the new, RESTful architecture. This was by no means a complete list but just items which required immediate attention to get a setup going. We worked out the items in proof-of-concepts and got a working bit going. What's important here to note is that the solution was not as polished and refined as it needs to be, but we got stuff up and running! This took couple of months (2 hours a day to be exact).

A-team phase

Once all the items in the list were tackled, the A-team was formed. This team consisted of stakeholders from all aspects of interest in an architecture (design, development, infrastructure, domain knowledge). Lot of people overlapped but new ones joined as well. The A-team worked on getting stuff refined created by MacGyver. They worked on getting stuff documented (standards, guidelines, etc.). They worked on proclaiming the knowledge using training, workshops.

Looking back
The MacGyver still exists. He is available on demand when something needs architectural attention. He happily does his swiss knife magic. The A-team helps in the refinement and the broadcast of the message. The project teams use the principles and work towards finishing the product. An emergent architecture setup!

I can't stress on it enough - it is crucial to get stuff working and get immediate feedback before it's rolled out to the mass. The MacGyver - A-Team approach addresses exactly this and am very happy to have discovered it.

2 years of doing Gamification

Last two years I've been involved in initiating and implementing Gamification. And what a learning experience it has already been! It all started with a simple problem. After leading a group of developers for couple of years, I noticed that we could use more binding as a group. This was difficult to achieve given the fact that we were placed at different locations and worked for different customers. The feedback from the group made this problem very clear and I set out in search to address this problem. I remembered the TED talk from Gabe Zichermann where he talked about games providing engagement. And I thought: let's try and see if it really works.

With a small core team, we designed a game; very custom-made, fit-for-use for our group. The design and implementation of the game kept the core team engaged and the rest of the development community liked the fun aspect of it. But stuff like this doesn't remain hidden. Soon people from the rest of the organisation found out and before we knew it, the game was rolled out to the whole of our Netherlands business unit.

The game is simple and revolves around badges like most gamification projects. But what makes it special is that customization. It is tailor-made. We introduced events to go with the game - pure gamification events! They are fun and bring people from all over the organisation together. We created a game we wanted to play!

After 2 years, we are now a Gamification special interest group which attracts people from all corners of the organisation having different roles. What gels this group is the drive to study effects of Gamification and how to implement it in different situations. All of this is done after office hours. We have achieved Engagement!

Looking back, I'm very happy with getting to know and experimenting with Gamification. I will be implementing it in every context where I see a possibility. 

Always "Think about the Little Guy"

During the Mobilism 2013 Conference, the statement "Think about the Little Guy" was repeated in couple of presentations. Even after a week, this statement keeps resounding in my mind. It is something we tend to ignore as software engineers. We, software engineers are one of the selected few who have access to the newest technology there is. We tend to take this for granted and often assume that the whole world shares these perks. The world scene, sadly is a bit different. Not only are there loads of people who still do not have access to the digital world of services and things, but a lot of them who do often do not have the luxury of fancy and smart devices. Do these people then not have the right to services and proper user experience?

Hell yeah! The little guy has as much right to the proper user experience as any of us. Why don't we then design our services for the little guy? Why do we lend an sarcastic smile when experience on Game Console browers is discussed?
We need to start changing our outlook of seeing our services. We need to start caring about the little guy. We need to start caring about the user experience on all devices and not just the smart ones.

My new mantra - "Always think about the little guy".
Hence I will worry and do Responsive Web Design and take it to the very extreme of delivering the same user experience for all devices... (Responsive images, Responsive content, and all there is). See link for stuff I'm gonna use.

P.S. The picture is RK Laxman's - The Common Man

License to code

The license to code shall be given to a developer who meets the following criteria

Passion for writing code;
Passion for creating software;
Recognizing the beauty in computer languages, their strengths and weaknesses;
Knowing that beautiful code is preceded by beautiful design, leading to beautiful software;
Having respect for others who will read your code; hence focusing on it’s readability and maintainability;
Finding the best possible way (and not just a possible way) to write code for a certain scenario or requirement;
Challenging the reason for using a certain pattern, framework or tool;
Willing to go that extra mile - by writing corner case unit tests, behavior driven tests;