Category Archives: Programming

The Job Resume Myth

Posted on by
Reply

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.

 

 

Playing flash videos on android webview..

Posted on by
5

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

			
						

				Posted on   by  			

			
						

				2			

					


				

			
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.

			
						

				Posted on   by  			

			
						

				1			

					


				

			
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

			
						

				Posted on   by  			

			
						

				Reply			

					


				

			
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.

			
						

				Posted on   by  			

			
						

				1			

					


				

			
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.

			
						

				Posted on   by  			

			
						

				3			

					


				

			
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.

					

		
		
	


				
					
	

		

						
You need to code

			
						

				Posted on   by  			

			
						

				4			

					


				

			
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.

			
						

				Posted on   by  			

			
						

				4			

					


				

			
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?

			
						

				Posted on   by  			

			
						

				2			

					


				

			
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.