My Latest Work : SignEasy

SignEasyHere’s an update on my work lately. Just released an updated version of SignEasy on the play store. SignEasy is a mobile-only app that makes signing documents really a piece of cake. Import your document from dropbox, box, sd card, email and quickly sign them digitally with a smooth experience. I’m a user of the app as well and truly appreciate the simplicity with which you could sign the documents. There’s nothing complicated about it.

I started work on SignEasy only recently when Sunil (co-founder, SignEasy) approached me to improve their android version of the app. The app was in a decent shape, with the existing code not available in a great condition. The android version had a few performance issues too and the workflow was a little tedious. The major issue was that the signing process felt incomplete. There was no provision to sign the document on the client side. It was uploaded to the server to sign and return back the signed copy.

This was a slightly painful experience for the user. Since the user couldn’t immediately see where he signed in the document. It’d only be available after he finishes his editing and the document is returned from the server. We analyzed a few android pdf editing/rendering libraries and went with one with supported local editing and rendering ability. Integrated that quickly into our code and that was it. Now users can quickly see their signatures on the app, and don’t need to wait for server processing. We also changed a few finer things in the app and the results are available in the new update of the SignEasy app in the play store.

If you’d like to work with me on your product/idea, Please do send me a note at satya@satyanarayan.in.

Smartness is in the language.

There was an interesting discussion that I recently had with a friend. The context was around choosing a technology stack for server end of the solution. We were discussing around php, python or Java. Client-end technology does not provide many choices right now. On mobile, Android/ios have specific platforms. If you’re going hybrid, you’d go with javascript based ones. Server end is a little different. There’s a host of choices. 

Ok. Back to the discussion. So we’d need to hire developers to work on the back end. Our thought was this: If we choose a more sophisticated language, would we get better developers. Now, in the choices we had, python was the most sophisticated. Personally, I like the language and the community around it. Now, if we went with PHP or Java, it’d be relatively easy to hire developers in India especially. Also, due to sufficient supply, we could also hire at a nominal rate and not burn our pockets. Though, the quality of such folks is rather questionable. In my experience, we’ve had to interview 10-20 people or more on average to find a decent developer in PHP or Java. Especially one who could appreciate programming in general and understand different design paradigms. Typically, you come across people who’ve known to code a certain way, and base their experience around a couple of tools. They feel completely foreign when introduced to newer concepts, even though experience-wise boasting greater than 5 years or so.

Now python developers aren’t too common here and come at a relative premium. Same with Ruby, Clojure, Node or similar languages/platforms. But since the language is so sophisticated, it instills lot of good practices in developers. Also, the quality of design skill is certainly higher than a regular PHP guy, to say the least.

In the end, you need a smart developer. One who is a good problem solver, has neat design skills and likes to produce quality stuff. Our conversation came to a conclusion that we need to choose a better platform to find the right developers. Python is a choice that we made for the exact reasons.

The emphasis on a good developer because : A good developer is much more valuable than just his coding skills. There are many facets of product development, where a sound feedback or input from developer shapes the product in a great direction. Since they’re the closest to the core/internals of the product, their inputs are very valuable, and a right person at that place is the first step in that direction.

[Note: The idea is not to look down upon PHP and Java developers, or anyone for that matter. I’ve known and worked with extremely smart developers, who used these languages to express themselves. The post is in general a reflection of current status of hiring (especially in startups/smaller teams), and lack of efficient developers.]

Would love to hear your thoughts as well.. Please do share them here. 

The Job Resume Myth

Last year or so has been filled with interviewing developers. If I’m to summarize one learning from them, it has to be this: Resumes are useless.

There are very few carefully crafted resumes that I’ve come across. Even those haven’t been entirely true, once you have a chat with the concerned person. There are times when it gives you an impression that the guy knows a lot of things, turns out that he can hardly write any code. So then what are resumes for?

1. Filtering purpose (incase of large numbers of applicants)

Well, ask them to write some code. They’ll filter themselves. It needn’t be very difficult problem too. Just throw in a basic problem, and watch their submissions.

2. Pay more attention to code and less to stories.

One thing I like to discuss with people during interviews is their code. I believe a developer resumes should have some references to their code. Without that, its utterly incomplete.

Once you look at people’s code, you tend to have an idea of their style and maturity in that area. The presence of tests, clear separation of concerns, will clearly indicate the proficiency one has in coding maintainable programs. Then, the interviews could be filled with discussions on their design choices and alternate ways of achieving the solution.

Ignoring this, you’re left with a list of technologies listed in the resume. Most of it he’d have only heard of. Some he’d have actually written a ‘hello world’ in. And a small portion, which he would have really used and knows something about.

3. My HR doesn’t know any better.

You deserve poor candidates. Hire Them. Seriously, engineers can’t be hired without rigorous engineering sessions. HR role is book-keeping. Nothing less and nothing more.

These are my thoughts and not of my employer or associates.. Please share if you have any thoughts regarding this.

 

 

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.

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.

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.