You need to code

As a senior member of the team, its very easy to get into a comfort level and literally stop coding. Have seen many people do that.

Especially, in the kind of software industry we work in.. you’re encouraged to leave coding and get to the so-called ‘Next Level’. That means a raise in salary. That means a higher position. And yes.. that means people work for you.

There used to be a sugar mill in my village. Incidentally, it closed down few years back. It had a similar tradition. Your importance was measured by the number of people working under you. You were the boss to 10 people under you meant that you’ve achieved the greatest feat the village folks have ever achieved. I’ve seen tears in family’s eyes once their son was promoted to that level.

It kind of made sense there. Not completely, but some sense. The kind of work performed did not really need a great deal of creativity or thinking. It was a mundane job. Loading/Unloading a sugarcane truck. Moving the load to the machinery. and so on.. So if a person was very good, he’d be twice as productive as the regular guy. Frankly, it didn’t mean much. Twice as good.

But, you’re in a software industry. A good software engineer is many more times productive than a mediocre one. So if he’s not coding.. its a team’s loss.

One of the reason given is.. you need to get other people to work and help them get to speed.

Frankly, I’ve been long enough in this field to know that it just doesn’t work. You can’t really replace a good software engineer with 5 mediocre ones. The output will only be mediocre. Add the fact that, leading a team is not something that comes naturally to software guys. In fact, on the contrary, good software folks aren’t really preachy types. They prefer showing the stuff in practice.

The speed with which the world is moving, most of the technologies get outdated pretty soon. So there is no real fun in holding on to Dracula and angels. In few years you’d find yourself struggling to keep your job competing with young guns equipped with modern artillery.

One way out of it is office politics. No one loves it. But they don’t have a way out.

And of course, management in no way compares to the fun and excitement that programming brings to everyday life. Isn’t it.

So let go of the status quo. Get back to programming. Show them how its done.

 

Revisiting is the key.

Thats the difference between good stuff and great ones. The second look. Revisiting your work.

Its the time when I started my career.. and a certain gentleman named Asokan, who was helping us getting started with Programming said:

“Your programs are supposed to function. They need to provide the right output. But, your work as a programmer doesn’t stop with that.”

There’s always a tendency to stop improving things once they’ve started to work. I’ve experienced this on many occasions where we released software as soon as it just started working. Then there is this over-celebrated QA team, that does some quality check and boom.. the customer has it in his hands. And it breaks (well, not always.. practically only 99% of the times) . We find ourselves spending pretty much the same time as we took to write the code, fixing it. Well.. we don’t learn. We follow the same cycle as above. It just has to work. isn’t it?

Well.. the truth is that stuff breaks. In software, it sure breaks like hell. So the wise decision is to be ready for it. Now, its not that we do it on purpose. Sometimes we’re not well informed, not experienced enough, are bounded by self-imposed time constraints. Most of the times.. we just don’t care.

So what can we do?

Give the code a second look.. (once its started working). Its not a crime to write ugly code to get stuff working. Its advised not to get into the habit of clean stuff.. and forget the actual solution. So get it working first. Then pause. Stop for a while. Its working now. Lets improve it a bit.

Clean stuff up.

Proper names. Rethink names of methods and variables.

Write tests if you’ve not written them yet.

Refactor.. Refactor.. Refactor.

Release it.

I know there is an urge to release stuff as soon as they’re ready.  The stuff above doesn’t take that long anyway. And saves lot of time and money later. Try following this cycle.

Next time you estimate a work, dedicate a little time for revisiting your code too..

Hope it helps.

Who do you work for?

Who’s your customer?

Typically you work for your customer. A person who pays in return for your services. Its extremely important to know who or which one of them is your customer.

That’s easy, isn’t it.. OK. A small quiz:

Q. If you’re a software engineer.. Who’s your customer?

a) Project Manager

b) Team/Tech Lead

c) Your CXO

d) The actual customer of the company that you work for..

The answer almost always is one of the top three options.. and never the fourth one. By the way, fourth option needs to be the right one.

If you’re a manager, ask your folks this simple question and try it out.. Who do you work for? If you have atleast 50% of your folks say the name of the customer, you’re running a unique firm, most  probably a successful one too..

Minimizing the gap

The crux of the argument is that, its extremely essential that the execution team is well aware of the larger problem at hand. The actual problem that is being solved.

Most of our organizations have so many layers of hierarchy that the people who are executing have no contact whatsoever with the people who’re going to use their solution. No contact.. zip.. zero. Only time they probably meet the customer is some dinner some day.

This mode only guarantees mediocre solutions.. and yes, mediocre companies. The ones which depend on ignorance and mundaneness.. rather than enlightenment and innovation. Ones where developers are props (or famously known as ‘resources’) whose job is to stare at the monitor and tap the keyboard.

Developers are much more than that. Developers are problem solvers. They need to be treated that way.

In most cases that I’ve seen..

accessibility to clients/customer

improves

the quality of the solution,

morale of the team and

overall comfort level of the customer.

As a developer, try to get close to the actual real problem at hand and contribute to the overall solution. As a head of organization, try to encourage your folks to engage at a higher level.

It benefits all the parties.. the developer, the organization and most importantly the customer.

Protect your dear ones

Many times you encounter code that reads as follows:


public class OuterClass{

private ContainedClass containedClass;

public ContainedClass getContained(){

return containedClass;

}

}

public class ContainedClass{

public void someMethod(){

// Do something

}

}

Typical usage:


// Usage of the class

OuterClass outerObj = new OuterClass();

ContainedClass containedObj = outerObj.getContained();

containedObj.someMethod();

This is a very common pattern and you’d have surely witnessed it in some form or another. There is something essentially wrong with it. Before I begin, Let me tell you a real life instance first:

Imagine you have a girlfriend. Hmm.. for most of us this is easy. We’ve always only imagined a girlfriend 🙂

Back to the point. Lets say you have a girlfriend. A buddy of your calls one day and asks you for her details.

Your obvious response would be “What do you need to do with her?”

He says he has nothing wrong in mind, he just needs to check on something.

Your response “Tell me what you want checked.. I’ll check and let you know”.

This would be a very typical case of how you’d react on that kind of a request. What are you doing here? You’re trying to protect her from exposing it outside, fearing it may harm her or cause her some trouble. You abstract her out from your friend and act as her messenger at times.

Now lets look back at our piece of code above.

1. The OuterClass contains an instance of ContainedClass.

2. It exposes it completely through the method getContained()

But thats not the kind of thing you did in real life.. didn’t you. You abstracted out the details from the friend who called you up.

You need to follow a similar approach here. Lets have a look at this piece of code. (With the ContainedClass remaining same)


public class OuterClass{

private ContainedClass containedClass;

public void someMethod(){

return containedClass.someMethod();

}

}

Typical usage:


// Usage of the class

OuterClass outerObj = new OuterClass();

outerObject.someMethod();

Here you have abstracted out ContainedClass from rest of the world. It can only be accessed through the OuterClass.

It is also referred to as ‘Law of Demeter”

It has many advantages:

1. It helps build more cohesive units and loosely coupled components.

2. The implementation details are hidden from outer world and can be easily modified if needed.

3. The dependencies on the calling objects are limited. It only depends on OuterClass now.

4. Testing is far easier, since you have less dependencies to satisfy.

Hope you found it useful. Do share if you have any thoughts on the above.

Object Builder alternative

Its a fairly common discussion and usually solved by

1. Constructors

MyObject(String name, String blog){
   this.name = name;
   this.blog = blog;
}

Usage:

new MyObject("Satya", "onSoftwareAndStuff");

There is a small issue with it. During creation of the object, the parameters “Satya” and “onSoftwareAndStuff” do not say what they are.  One of the alternatives with dynamic languages is (with Groovy)

 new MyObject(name : "Satya", blog : "onSoftwareAndStuff");

This is much more readable as it says.. name is Satya and blog is onSoftwareAndStuff.

2. Setters

MyObject(){
}
public void setName(String name){
     this.name = name;
}
public void setBlog(String blog){
     this.blog = blog;
}

Usage:

MyObject obj = new MyObject();
obj.setName("Satya");
obj.setBlog("onSoftwareAndStuff");

This is more readable but spreads into multiple lines and repetition of variable “obj” and method ‘set*’ is uncomfortable.

3. Alternatives

To achieve the readability equivalent to the groovy construction, lets try the following alternative:

MyObject(){
}
public MyObject name(String name){
     this.name = name;
     return this;
}
public MyObject blog(String blog){
     this.blog = blog;
     return this;
}

Usage:

MyObject obj = new MyObject().name("Satya").blog("onSoftwareAndStuff");

Probably for a 2 parameter constructor this is an overkill.. but if there are more parameters, this looks a fairly feasible solution.

Any thoughts?

Thoughtworks..

It’s been couple of months since I left Thoughtworks a.k.a TW, one of my dream companies (and still is..). A tribute has been due, so let me try that out here.

Joining TW  was at a time, when I was going through a very lean phase.. both personally and professionally. Leaving my startup wasn’t an easy decision, especially after spending about 2 years on a wonderful product LeadSimplified, which I would always reckon ‘My first Baby’. Professionally, pretty down for obvious reasons. I hadn’t worked in a recognized organization for last 2 years and in our part of the world the word ‘entrepreneur’ is not really a great tag to have. It only gets you into messy situations with your colleagues (especially your boss), if you know what I mean.

TW, I initially thought was the best place I could have gone at that point of time. The open culture, innovation and creative freedom that they practice would not let me feel out of place. I was right to most extent. There is a fair section of the organization which is extremely innovative and hungry (to do something worthwhile).

Getting to the point, A few quotes:

1. Our people are not talking about it (Rebecca Parsons, CTO, Thoughtworks)

A lesson in management for me. The emphasis on bottom-up management and employee empowerment is certainly applaudable.

Something that I touched upon in my article Decision making and organizations

2. Yeah. Of course. (Ketan Hajirnavis, GM, Chennai. Thoughtworks)

These were the exact terms used by Ketan when I went to him requesting for allowing me to register a startup. Any other company.. any other GM.. I would be out of the company. No questions asked. It was my honesty and confidence in TW that I told them about it. That’s the confidence that TW culture instills in its employees.

Couple of things that I would take with me always..

Of course, there were few things I didn’t appreciate.. but that’s for later.

Its an organization any good programmer/consultant would be proud of.. and I am.

Nasscom Product Conclave takeaways

Here are few of my primary takeaways from the event in no particular order..

1. Vivek Wadhwa live..

This one’s obvious. I’ve been a fan of his research and his thoughts for quite some time now. It was great to have his presence there. The sheer candid nature and knowledge of the man is fantastic. He’s not always correct, but the good thing is.. he doesn’t try to be.

2. “Company needs a different management team when its $5M than when it is $500M. Sometimes you have to let people go.”

As an Entrepreneur, you need to be rational about your decisions about your organization. Can’t be very emotional about it. This statement was courtesy Sharat Saran, CEO ON24

3. “Selling is a major function for Entrepreneurs.”

Its not an option really. Entrepreneurs have to be good at selling their idea. If not, should learn it. Replacing this deficiency by hiring a VP-Sales is not a good option at all.

4. “Never sell wrong stuff to people.”

Absolutely. Do not sell people what they don’t need. This model is not scalable. At times, it is better to say “Our product doesn’t really fit your requirement.” If you’re nice enough you can follow up by saying “Here are a few products which can help you with your need… “. You’re building lot of credibility and trust for yourself.

5. “Every employee is your salesperson.”

Every interface that your company has with external world leaves impression. Impressions about your company, people and product. Its essential that every employee of yours understands the true values of your company and exhibits that in his interactions.

6. “Indians have a higher chance of success at their venture”

Since Indians are flexible to change and accomodate/adjust to situations relatively more easily to their western counterparts, the chances of them achieving success is fairly high. Only thing keeping them from it is giving it a shot.