What do you want from your employer?

-- publishing another old draft. written at my career low. it always helps to pause, think and know what is it that will make things better for you.  --

Peace of mind :)
Someone asked me this question a couple of days back and I thought it makes sense to write something down about it

Being paid and not doing worth it isn't fun. If you are not running at your full potential its a lose-lose situation that needs to be fixed asap.
The *right* fix for this is mutual which means it needs efforts from both ends. So you as an employee would do your bit (that is in your interest) and your employer (could read manager) should provide the complimentary bit!

So the answer to "What do you want from your employer?" boils down to: Provide me with an environment (read manager/co's, work, compensation etc) that will make most of my potential.
So to say provide that 'complimentary bit' whenever you run into issues.

From the perspective of worker (read developer) in the software industry this boils down to:

1. Flat hierarchy (mostly in technical choices)
Everyone should have say but the best *known* solution should be chosen. Highlighting known since its pointless to keep saying this is not right because of blah blah.. and not suggest what is the right thing to do.
End of the day the "best choice" should ship and not the "best mans choice" :)

2. Fairness
You should get what you are worth. This includes appreciation, compensation and credit to work. In any competition it is unfair for the judge to have favourites. Similar principle applies to the manager.

3. Challenge
The work should be challenging. Otherwise you are not hitting the limits which is the best way to grow forward.

4. Change
One cannot do "a" thing every day and keep doing that. It is natural to want to do something different. While this may not make sense to do everyday but it should be possible to do this every once in a while

Need help? Help yourself

--publishing another old draft. times when instant messaging was new!--

Very often you have issues and often you have to seek help from a colleague or an expert in that field.
Quite a fraction of this (typically) "seeking help" thing happens in a rather informal way. Apart from the coffee tables and over the desk medium this includes "chat".
Call it the "informal formal written talk" (brevity: IFWT). This is extremely handy. And no wonder its getting more and more popular.

Chat takes the best of written and spoken worlds.
1. Saves time
2. Keeps record
3. Stays informal
4. Interactive

Unfortunately a of people mess this up.

Lets start with a very common scenario.

c: hi.. 04:50 am
s: tell me.. 05:00 am
c: you there? 05:10 am
s: yes! 05:15 am
c: hi 05:15 am
----- no response from s ----
----- c continues with his greetings ----

Lesson 1: Get to the point quickly
Though chat is a interactive thing.. people are tied up with other work so you have to be prepared for delays in responses.
Since the person you seek to has less idea of what you want so its your onus to move forward in the process. (at least in the beginning)

Another scenario.

c1: hello
c2: hi
c1: i am getting a segfault when i start the app
c2: ohk.. i know why this happens. run the xyz script. should be okay..
c1: theres no such script! the environment is f!@#ed!
--- follows a special invesitgation ---
c2: damn! i thought you were talking about application foo!

Lesson 2: Set the context
It is very important to set up the context for any issue. There's a lesser chance of being misinterpreted. In this case, c2 could have also avoided the situation by proactively asking. Which app, where etc. But I am going to stay focus here on how the seeker can get things right.

Lesson 3: Make no assumptionsAs far as possible try giving as much information as possible, and make know assumptions about your helpers knowledge on your specific setup. It doesn't hurt to repeat yourself. A wrong advice does!

Lesson 4: Be Grateful
Again, it is you who needs help. Be polite, use smileys, and always thank him for his time!

Lesson 5: Talk to the right person
Its a very good idea to start with telling the person why you are talking to him in the first place. Especially when you are talking to someone you don't interact very often. He should know where you are coming from and whether or not he is supposed to/able to address your issue.

Lesson 6: Be a good listenerThis is very important. You have to tell your issue and not your ideas about the solution. So its very important for you to get rid of any preconceived notions. Your ideas about the cause of the problem can mislead him into thinking in the same way as you. And essentially end up in the same seat.
Of course you will always find in slots to put in your views/opinions/experiments. Don't just throw it all at him at once!

Most of this is applicable for email communication as well. But the anti-patterns described are more common over chat.

Timing a standup

UPDATE: Publishing this old draft I found. Early thoughts on stand-ups. Over the years I've realised stand-ups are  evil and one of the worst forms of micro-managing a team. Will pen my current thoughts in detail soon!


Its very tricky to deal with developers or for the developer to deal with himself for that matter. Most software companies have this very casual work culture and no one likes to be micro managed. There are times when this becomes a pain to the product manager, and even the developer feels he is getting off track.

Status reports monthly, weekly or even daily are the usual resorts. But the more friendly version is the standup meeting. In a typical cube setup of a team, everyone stands up and takes turn on updating the rest of the team on his status. While this is an excellent idea the timing of this can go terribly wrong.

Until I did it myself when I was leading a team, these stand-ups used to happen early in the morning. One of the reason being the manager wanted everyone to be at desk early. A status would mean, what I did since we stood last and what I plan to do next.

The morning time has couple of issues
- still not everyone is in
- you can get away with fancy deadlines for EOD today
- what you worked on yesterday isn't fresh in your minds
- one tends to defer work till later in the night

The later in the day stand up OTOH
- gives a nice incentive to work hard and present it end of the day
- don't waste to much time during the day, for end of day you'd be asked a question

I just started with this, and so far its worked well. I'd write more on how this approach goes in coming times! And may be with more teams, if I am able to inspire.

What you get and what you want

In the software industry one keeps getting into a situation where he has to do things that he doesn’t want to be doing. This is especially true for fresh graduates. The best thing here is to get out of the situation as smoothly as it is possible. It is bad for the company and more importantly it is bad for you. The best interest for both the individual and the organization is to keep working on aligning their mutual goals.
One of the companies I know has had this “random” resource allocation strategy for fresh graduate hires. “You will have no choice of projects/work. Be prepared to do what you get to do” said the campus presentation. This makes sense from a pure administration point of view. All fresh recruits are above the “bar” set for the employees, they have negligible expertise, most of them have little clue of what they want to do in life and above all they were plenty in number. But in the long term this turns out to be bad. Misallocates will leave or live with the job.
There are several factors that can leads to such situations and every professional most likely faces it every once in a while. How an organization, manager or the HR deals with it is another thing but here are some tips for the victim to keep in mind while dealing around this situation.

• Know what you want to do. Otherwise you will never know what you should be doing in the first place. Think yourself a handful years down the line. And see how you can work towards getting there.
  

• Learn to say “No”. If you have the option then just say it! It is good to deny doing something upfront rather than doing it just for the sake of it or even worse giving it up at a later stage.
  

• Look for the opportunities you still have. See how the job still has something that will help your cause. When I had switched to a completely different profile, I was surprised at how two radically different job roles can have so many skill sets in common. This will especially be true for fresh graduates since they are still acquiring the skills needed to work in the industry
  

• Work on what you want in parallel. Save time while you do your day job and spend that time (I say push yourself for more) reading and experimenting things that you really enjoy doing. Of course saving time doesn’t mean doing it miserably. Remember what you are paid for is the day job and of course who wants to have pointers to bad work after getting famous :) Often this becomes a blessing in disguise. Learning to do things efficiently and learning to do things in parallel (read prioritizing) are one of the most precious work skills and they take a lot of time and effort to master
  

• A more common situation is that your job has a mix of tasks some of which you like and others you don’t. Always make sure you have those secret spare cycles to pounce on what you want to do and at the same time have those pseudo busy cycles to avoid getting into what you don’t want to do

While we are at this remember that the most important thing is to enjoy whatever you do and deliver the best for your worth. And of course there is the James Barrie quote: “Happiness is not in doing what one likes but in liking what one does”

First

Good bye mailing lists

After using Stackoverflow for sometime, I've decided to experiment with it as a substitute for internal (company) mailing lists.
Stackoverflow doesn't seem to have any internal hosting options. So I did a little search and figured out OSQA. It looks very promising and in fact I find its UI more appealing that stackoverflow's. Shapado comes as a close second. Though to be honest I haven't done an extensive comparison. (so the "second" verdict isn't to be taken too seriously)

Here's why I think QA system makes more sense compared to mailing list
1. Politeness
The striking difference between QA and mailing lists is the politeness. If you ask a bad question on comp.lang.c you would be flamed. And the meanest reply comes from the highest authority in the group. Well there's no such notion but that's what the readers would perceive anyway.
Its another story when it comes to QA systems. There the seeker has the option to rate up and rate down the answers (so do the readers) and he also has the right to choose the best answer. And points is the basic currency in the system.

2. Use as a knowledge base
The fact that the user marks the best answer. And the community rates answers, as a reader you would always like QA system more than searching on mailing list. The common scenario in mailing list is that the OP never gives a feedback on what worked for him or not.

3. Quality of content
Again because of the rating, both parties want to write presentable stuff.

4. Tagging
Often the same mail belongs to many mailing lists. Its difficult to choose one. Cross posting is even worse. The QA systems allow to search questions (and answers by tags)
So if you tag your question well, you'd reach the right audience.

We are starting to use this on a small scale within our group and if all goes well, the plan would be to replace our internal mailing lists.
It looks pretty straight forward to migrate existing mailing list threads to OSQA too.

That said, not *all* mailing lists can be replaced (please excuse the title) The announcements and general discussions still hold good for mailing lists.

Stay tuned for more updates on this front! (non technical)