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.

 

 

Advertisements

Playing flash videos on android webview..

Was recently playing around with getting a youtube video to run on a webview in android. Was able to run it fine using the iframe but had issues getting some control over it. Same with ooyala videos.

Simple issues like video still playing once i leave the activity, on orientation change, etc..

It was rather simple in the end, coz webview exposes methods like onPause and onResume to provide control on the flash content being played in that webview.

Here are few things that you can do:

Handle your orientation. This would help keep the video running continuously even on orientation change. Modify your manifest like below.. and override onConfigurationChanged method to handle the orientation change.



<activity android:name:"MyActivity"

 android:label="@string/app_name"

android:launchMode="singleInstance"

android:configChanges="orientation|keyboardHidden">

In your activity, handle onResume, onPause and onDestroy and control the webView instance from there. Create the webview as presented in the method showVideo. It basically loads the youtube video in an iframe. You can use the link of embeddable version of youtube video.

 

 

Hope it helps someone.. Let me know if there’s any better way.

Save and Update with Sugar

This post helps demonstrate the ease with which you can save and update a record with the help of Sugar in android project.

For an introduction to Sugar, click here.

Firstly, to enable your model to utilize Sugar’s benefits, you need to have configured Sugar in the manifest file (as shared in the introduction) and the model needs to extend SugarRecord.

Saving a record becomes straight forward, as you’re only interacting with your objects and not the usually messy way of dealing with SQL queries directly. Here’s a way to save a record using Sugar:

// Note class represents model. It extends SugarRecord.
Note note = new Note(context);
note.setTitle("Make Tea");
note.setDescription("Add tea along with milk and sugar. Boil for few minutes");
note.save();

That is all you need to do to save a record into the android database. The save() method takes care of inserting the record into its corresponding table.
Similarly, modifying and updating a record is made very simple with Sugar. Here’s a way to do it.

// obtain a reference to the note record from database.
Note note = Note.findById(context, 1);
note.setDescription("Take some water. Add milk, tea and sugar. Boil it for few minutes");
note.save();

Here findById() is a query method to obtain the record with id 1 from the table. After getting the reference to the instance, modify the values and call the save() method to update the record into the table.

So, as you see, saving and updating records is made very straight forward with the use of Sugar. The code is located here  . Check out SugarExample for an example project.

Do try it out.

Sugar : Android database made easy.

UPDATE : Some of the code snippets in the below post are outdated. Please visit http://satyan.github.com/sugar/ for latest updates to the library.

This post is an introduction to Sugar library for android. The aim of the project is to simplify database access in Android.

The project draws inspiration from GORM for grails or Active Record for Rails. These patterns have been hugely successful in the web world, and have set a benchmark for libraries for database access.

The basic objectives of the library  are:

1. Creation and management of database and connection.

2. Simple and Intuitive API for database querying.

3. Simple CRUD operations.

Source Code

Source code is present at https://github.com/satyan/sugar

You can clone it and start hacking. There’s a build script along with it to compile and generate the binary.

An example project using the library is present at https://github.com/satyan/SugarExample

Usage

Android Manifest file: 

Include the android:name attribute in the application tag. SugarApp extends android’s Application and initiates the database creation for the project. By including the attribute, you’re basically starting with SugarApp instead of android’s Application class. If you intend to write your own Application class, you can extend SugarApp.

<?xml version="1.0" encoding="utf-8"?>
<manifest..>
<application.. android:name="com.orm.SugarApp">
.....
</application>
</manifest>

Entities
The entities need to inherit from SugarRecord including a typed parameter. SugarRecord provides for all the CRUD methods that will be available to the entity classes.

public class Note extends SugarRecord<Note>{
private String title;
private String description;
public Note(Context context){
super(context);
}
...
}

Thats about it. Configuration is done. You’re ready to dive into the sweetness of Sugar. (OK.. I couldn’t stop myself from saying this.)

# inserting values

Note note = new Note(context, "Note 1");
note.save();

# query

Note.findById(context, Note.class, 1);
Note.find(context, Note.class, "title=?", new String[]{"Note 1"});

# delete
Note note = Note.findById(context, Note.class, 1);
note.delete();

# few more..

Note.listAll(context, Note.class);
Note.deleteAll(context, Note.class);

Nice.. All done. Happy Android hacking.

Keep an ‘A’ player engaged

In my previous post An ‘A’ player in ‘B’ team, I touched upon few options that one has when he’s put in an average to sub-standard team. One of the options was to leave for a better option.

As organizations, you want more and more ‘A’ players. They’re the guys, you can throw into any situation knowing that they’ll take care of it. They sniff opportunities when others are pondering over the problems. They bring energy and momentum even when situations seem dark and bleak.  Its hard anyway to find one, when you do.. letting them go is obviously not the wisest of  things to do.

Typically, they struggle in larger organizations because of all the politics/bureaucracy that precedes any decision making process. And the word ‘process’ itself is kind of a metaphor for killing innovation within the company. People are mostly rewarded for doing average work, not extra-ordinary things. It discourages a good talent to keep engaging himself in company’s growth and activities.

So, what do you do.. to retain them, and keep them engaged.

1. Give them some space.

2. Opportunities to innovate.

3. Accept failures.

4. More responsibilities to execute.

5. Provide them good team to nurture and guide.

6. At times, keep them away from the bureaucratic BS.

7. Pay well. Don’t restrict them to bands.

The list is not exhaustive, but certainly ample to help you retain him long enough. As is generally said, a good programmer can be ‘X’ times more productive than average one (with X ranging from 10 to 100.. and at times infinity too).

An ‘A’ player in a ‘B’ team.

Its a tricky position to be in.

Well, let me define the situation a little more.

‘A’ player is one who is typically smart and effective. Has more than one solution to a problem, where other team members hardly understand the problem. Never ever do you need to follow him to get work done, in fact, he keeps the team on their toes. Takes initiative, and often undertakes more work than he can handle. Inspires people and has a following of some kind.

‘B’ team is one which either comprises of too many senior folks who find ways of not getting out of their comfort zone or folks who’re not competent enough to solve the problem, leave alone solving it well. Both look to choose the easier route, one which is closer to their intellectual reach and doesn’t stretch them.

So, what do you do in that situation..

1. Take advantage of the situation:

Well, since you’re few steps ahead of the team, take advantage of that to finish work early and make up more time for other activities that you like. Contribute to open source, work on a part-time project, etc.

2. Try to pull the team up:

Try to motivate others by your effort and dedication. Coach them, mentor them, push them.. set higher bars of excellence. Show them the way.

Easier said than done. Most teams don’t react well to peers’ advice. They’re a ‘B’ team for a reason. But one can certainly try it out.

3. Get that promotion, you missed last time:

There’s no better opportunity to do lot of work and get that desired promotion. However, need to be careful with the team politics. You may be overloaded with work, and eventually blamed for things (since you were the one who did it).

4. Shut up, and go through the flow:

Chances are you won’t do it, but the probability is high. Just get through this project and move on to another one, quickly.

5. Run as fast as you can.

After trying out above things for a while, if you don’t see any improvements or changes. Move out. Its not worthwhile to spend effort on a team that has no motive to excel. Look around for right people and projects, in certain case companies too.. and run as fast as you can.

Well.. I could only wish, you never get into one of those situations.. But if you do, tackle it with some care. Your action or inaction, can have lasting effect on your career.

 

Working with legacy code.

Its generally not a preferred option to work with legacy codebase, but every now and then you do come across a codebase which hasn’t undergone a overhaul in long long long time. It is very common to lose all your calm on it.. get frustrated, and either do nothing about it or leave the job to do something else.

I had a recent encounter with such a codebase and below are some of my findings and recommendations about handling such a codebase.

Let me start with the definition of the codebase.

It had been written 2 years back and the software has been used since by 2000+ people.  There have been multiple revisions of the product and all the changes have made the codebase fairly rigid and incomprehensible. It was supposedly written in hurry, so quality wasn’t taken care (typical of startups). Since then it has not been re-written or even cleaned up.

Long.. huge all powerful classes and methods. No object-orientation whatsoever. All static methods. Algorithms and logic written so beautifully that even the author finds difficult to navigate through them. Messed up assignments and states. It was at times a game to guess what a particular variable would contain after few iterations of the code.

Ok, you get the picture, right?

It is very easy to start criticizing the people who wrote it and make all noise. But, have a look at the good part.

The software has been running pretty successfully for last couple of years. Been used by thousands of people. Been earning money for the organization. Its not all that bad, isn’t it?

So, first step to tackle such codebase is to treat it with respect.

Not easy when you’re supposed to add functionality on top of it. But, appreciate the fact that the product has been useful for a longer period of time. Many software products never get to see the light of the day. Beautifully written, wonderfully functional, but never released. It is much better to release a product and iterate on it than never release at all.

Having said that, lets see some of the ways to tackle that code (in no particular order).

1. Don’t be afraid to change.

It is difficult, but not impossible. Leave the tendency to not touch the existing functions. The sooner you get comfortable with the code, the better chances you have of adding features on top of it.

2. Try to divide the codebase into smaller classes and methods.

Be methodical about it. Make small changes and test frequently. But nothing beats this approach. Separate a big class into multiple smaller ones. Long methods can be broken into more meaningful smaller methods. This will automatically give you a picture of what is going on within the code.

3. Change the names.

Work with the team to change the names to more appropriate ones as and when possible. You’re not only making it easy to understand the code, but, also making yourself comfortable with changing the code, without touching the solution much.

4. Write tests around existing code.

At times it gets difficult. But with some discipline and patience, you can write tests around existing code. It helps a great deal to understand the code and improves your confidence in changing it at a later stage.

5. Understand and manage dependencies.

Try and separate different areas of the code and manage the dependencies between them.

These are few strategies to approach a large legacy codebase. Please share if you’ve come across similar situations and how you handled them.