Keyboard closeup

Programming as Writing.

I would completely agree with Eric Lippert when he says code is way easier to write than it is to read.

In Programming, as in writing, we present text and data. Data without structure is useless. How do I find things? How do I consume information? What is important and what is trivial?

When you read something, you expect a certain structure that saves your time and effort.. in absence of which you quickly give up. Lets look at few things that affect writing and programming in the same way.

Important information goes first

Table of contents, indexes and overviews should come first. They present a bigger picture to the reader. They help the reader to navigate through the content in a very smooth manner. Then comes the titles and then the paragraphs.

In programming overview is typically represented by package structure, and tiers. It isn’t as easy as it seems. It is extremely important to confirm to a structure and stick to it consistently throughout the content.

The titles, which would be method and class names, have to define what the following content is going to be. Well written title gets noticed and communicates the intent of the paragraph to the reader.

Then the paragraphs. It is extremely essential to break your content into many paragraphs. A carefully structured and organized content goes a long way in capturing the reader’s attention compared to a single large piece of content. So its important to break our in to proper classes and methods and keep them small and contextual.

Combination of small and well crafted classes and methods with well positioned names for them is a perfect recipe for fantastic prose.

Structure of information

You can structure your information is number of formats that can appeal to the reader. If you understand your readers well and can prioritize the important parts of your information, its wonderful. You can structure your information in the order of importance.

There are many layouts like Hierarchical, Linear, Non-linear, etc. Here’s a good example of a typical structure of a program.

Search-ability

You can provide extreme help to your readers if you make your content easily searchable. That means, readers can reach the content that they’re interested in, very easily.

Especially in softwares, since readers do not go through every piece of code line-by-line, it makes lot of sense to produce content that is very easy to search. Few things that can be done are:

Maintain the same vocabulary throughout the project. So when you name a variable as ‘salesTax’ at one place, it’d help a lot if you use the same variable name at other places in the code too. Making context specific searches extremely easy.

Name your classes and variables in terms of domain related terms. So instead of  a class named ‘SingletonFactory’ it’d be nice to have a name as ‘AccountManager’ or something closer to the domain.

Keep the content and the titles in the same context. So if a method says ‘calculateTax’ it should do only that. Other side-effects like auditing, interests should not be part of the method. They can be placed in their own methods or classes.

Getting a second opinion

Its easy to get lost in your own world and miss out many details. So periodically, one should review their content with few other readers. This would help you validate your assumptions and provide valuable feedback to improve on your writing. You can start out by giving an overview of the content that you’ve written and then let the reader find their way out through it. Observe them as they’re going through your content and how they’re navigating through the different structures.

In software programming, the process is called code reviews. This is where other programmers have a look at your code and provide their feedback. It is extremely important that you do that more often in your whole effort.

Read others

Its amazing to see how related reading and writing are. Once you start reading other people’s content, it has an effect on your own writing style. You tend to appreciate and adapt other people’s style and presentation of content. When you write you try to accommodate those learnings yourself.

You can setup reading groups to improve on your skills. Doing it as a community is extremely effective as you can discuss your views and assumptions with other people in the group and form a very objective opinion.

For programming, there is so much good code out there to be consumed. Start off with your favorite open source code and try to identify the patterns and styles that are used in that code. Try implementing those in your code as well..

Conclusion

In the end, its extremely important that you write. There’s nothing like writing. The whole process of writing improves your process of thinking too. Once you start thinking clearly, the same would show in your code. I believe writing (as in prose..) can have a very positive influence on your skills as a programmer.

So.. lets write. Lots of it.

Two at a time

Social Profile – Interviewing – Part 3

This is a continuation in the series of Interviewing.. Here are the first two parts Part 1, Part 2

I’ve shared my views about the recruitment process in general and the absence of actual coding/programming for programmers. In this topic lets talk about resumes.

What are resumes for.. to define one’s body of work and experiences that one has had in his career/lifetime. They give a glimpse of what the person has been doing in their lives till then.

By looking at a resume (in software industry) you can say that a person is interested in Java/.Net/Ruby and understand that he’s executed multiple projects in these technologies. And most importantly (and mostly useless..) his number of years of experience.  They effectively become the basis of the face-to-face interview that follows next, where mostly one is asked to define the things that are presented in the resume.

Now, how much can you tell about a person by just looking at his resume?

Frankly, the resumes that I’ve seen in last 5-6 years, Not Too Much

Most of the resumes look very similar and there’s very little information that can be termed useful in any way. Frankly, a visiting card would give you the same information that most of our resumes contain.

Now, here’s an alternative.

Let’s read the person’s blog. What does he like to write about? What does it tell you about his personality, his attitude..

Let’s look at the content that he likes to share with others.. Twitter, Google Reader, StumbleUpon, Digg, Delicious.. What are his interests?

Let’s look at some of his code that he’s written.. Github, Google code.. What does he like programming? What’s his style?

Let’s attend to some of his conferences.. Barcamps, Devcamps, Tech conferences.. How good is he in communicating things? What’s his style of presentation?

Now compare the information that you just got with his resume, and see for yourself..

Yes, it requires more effort than reading through a mundane resume.. but your chances of hitting a good programmer are extremely high. (if you’re looking for one..)

After this.. Interview becomes exactly what it should be.. a process of exchanging views. When both of you are moving in the same direction, well.. you join hands.

Many organizations are doing it very actively.. It should only be a matter of time before it becomes fairly mainstream.

2610871129_a609b2660b

how to choose software projects to work on..

Some time back, I had finished up one of my pet projects and was looking for something new to work on.

It’s amazing to see the number of choices one has right now in terms of choosing a software project to work on. I primarily develop web applications and like to focus on Rich Internet applications. So was looking around for things in that section. Thought of checking out with people to what they tend to choose..

It went like this.. The choices were rails, asp.net mvc, python/django, grails, jquery, spring web, gwt, flex, silverlight, scala/lift, and a few more..

Wow. I mean, look at the list. and its not all.. we’re just getting started.

Each one of them have their own pros and cons, and choosing among them is really interesting and difficult too.. I started to compare some of these to decide where to start. After few weeks, I was still at the same point and had not been able to make any decision. I always felt like missing something.

Then I realized that I was doing it all wrong.

Nowadays, there are so many things that one can’t keep on top of all thats happening. So I started thinking about how I should approach this thing. Sometime later, in one of the podcasts from Joel and Jeff (from Stackoverflow), I listened to an interesting conversation about choosing what to work on, and I totally agreed and understood the concept behind it.

Technology is a means to get something done. If you’ve found what to work on, as in a domain (or) a problem to solve, it’s fine with what technology you’ve chosen.

One needs to find something worth doing, a problem worth solving and then choose the technology that should back that up. Thats the trick.

Frankly, if you’re doing something really good, it doesn’t matter even if its in php.. nothing against php folks.. :)

Ok, fantastic. So then I started looking for a good problem to solve. Found couple of interesting ones. Started working on them.

The technology chosen is grails, was a good fit for our kind of team and nature of the project. Well.. lets see how it goes.

1159921_96829457

working for vs. working with Customers.

Customers are always right.

Customers know what they want.

In my career with customers ( and I’ve met a few), I’ve concluded that both our previous statements are not entirely true.

One thing that is true is, Customers have a problem to be solved. And When they hire consultants or vendors, their plain expectation is that they’d solve it.

Most of the times, customers can define their problem fairly clearly. Other times, they don’t. But lets ignore the latter ones for this post.

Ones who’ve managed to define the problem, also seem to have an idea of a solution. A solution that would work, not necessarily the best solution to the problem.

This is where consultants/vendors come in.

There are two approaches that are possible from this time on.

1. Consultants can try to reach the actual problem, and propose multiple solutions either supporting or contradicting customer’s idea.

2. Consultants can just help in executing the conceived solution for the customers.

This is the crux of the title of this post. First point is what I would like to call “working with” and the second one as “working for”.

I’ve always believed that if you have a part in designing the solution for the problem, it becomes dear to you. The level of dedication goes up a notch. This doesn’t necessarily mean that your design has been chosen as the one, it’s just that you’ve been part of the process of arriving at a solution is the key. You tend to relate to the problem better. You tend to feel a part of the solution. End Result, you perform better.

I’ve not been totally convinced with the second part. Its like a Hit-man at his job. He gets a phone call.. a picture of the person to kill.. and he goes kills him.. done. Engineering doesn’t work like that. There are many things that go into executing a solution. Morale and Passion are a big factor. If you lack that in you or the team you’re working with, be ready for mediocrity. That is what it would result in.

So you decide what you want to do.

Work with customers and relate to their problem. Deliver a solution to their actual problem (which may be better than they had thought. Exceeding expectations) or

Work for them. Deliver the solution they asked for (which may not be a solution at all). In this mode you’ll be doing great if you match expectations. Most times you’ll fail to do that too..

Modern organizations, work with customers. They’re much more concerned about customer’s investments, and most importantly.. they believe in delivering a solution that actually works.

OLYMPUS DIGITAL CAMERA

Pluggable products.. competing by collaborating.

A while back, I wrote about competition and collaboration being tied to each other in today’s market place. That was directed towards organizations collaborating with right partners and competing in the space. Recently, I’ve been looking at a similar trend in software products. Its very difficult to separate collaboration and competition. In fact, as ironic as it seems, collaboration has become an essential requirement in today’s competitive environment.

We need applications that integrate seamlessly with other web services like twitter, facebook, flickr, etc. A standalone application is just not good enough.

We need applications that expose themselves through apis, so we could build plugins over them. Few years back, it would have sounded totally absurred to have applications which expose themselves to the outer world.

Think about it this way. You have a product. Of course you’d like people to use it. That’s the reason why you have a product at the first place. Now think about what would make it more interesting for your users.. More features. Well.. not necessarily extra features, but some improvements on the existing product. As a single provider, it’d take you enormous cost and time to try and deliver all by yourself alone. You’d need an additional hand. Expose apis and allow people to lend you that hand.

Its almost like outsourcing some of your development to external developers for no cost. You don’t just get some of your features done, but you also get another perspective on your product, which in certain cases can really change your product itself.

There are certain products like Mozilla Firefox and few other who have created a certain sticky-ness just because of their plugins. Lot of people don’t migrate to other browsers just because they don’t have the plugins that they’re used to in firefox. There are also products that are adding all sorts of new integrations to lure their users. Google Maps, Twitter, Facebook, Flickr, iPhone, Android, and the list goes on..

Ok. So the message is.. if you’re building a product, think about pluggable architecture right from the initial phases instead of building it later.

1028616_66899829

Sometimes Strength is their greatest weakness..

Its odd, but true. Really. Many companies suffer because they did not evolve their business models at the right time.

We’ve heard of companies that fail very early on, in the startup phase, because of lack of a strong business model primarily. But, in current day and age, it is not enough if you’ve made through that phase. In the face of competition, first mover advantage is restricted to very few domains. Certainly not software.

Its essential that company evolves its business model, considering the state of economy, political structure and basically the environment. Many companies make the perennial mistake of sticking to their assumed strength for too long. Yes, I don’t mean to say that one should not value their core value proposition, I’m saying that one needs to continuously keep evolving it.

It’s about continuing to innovate in every means possible, and building that innovation around your core abilities.

When companies get bigger, they tend to be more focussed on their core abilities, simply because it is difficult for them to innovate and grow at the same time. Hence we see a trend that most innovation come from smaller players, who have little to lose and are willing to go that extra mile to build something that breaks the predefined rules. And naturally, bigger companies are found wanting.. playing the catch up game in the competition.

Recently, there has been lot of movement in this space. Many companies have tried to redefine themselves. Companies that have always been very traditional about their business models are getting out there and trying newer things. It is for the benefit of everybody. Those who are not doing it, they better have a very good reason for not doing so.

1055977_30345659

Coding. Interview as a Service – Part 2.

This is a continuation of the Interview as a service series. You can visit the part 1 here, where I talk about some of the common shortcomings in recruitment process of IT organizations.

Well.. to jump directly onto the subject, Coding. How many organizations have coding as a standard practice in their regular interviewing process? To your surprise, not too many. It is absolutely mind-boggling to how one can recruit programmers without actually testing their programming skills.

Programmers are supposed to program. Code. In any language, but Code. That is a absolutely non-negotiable. Any concept, any theory, if it is not demonstrated through code.. it is not correct. It is not good enough if one talks well, is well dressed and knows few technical buzzwords/jargons floating around in the industry. We’ve seen such folks struggle to write even the simplest of programs. And for all the referral process fans here.. these folks have lot of friends like themselves. They will refer everyone. No doubt about it. So you end up having a fantastic team of programmers who can’t program. Not program even if their lives depended on it.

This decision has to be made by the organizations. Do you want such posers in your system? If your answer is we’re fine with it, you can stop reading further. This one is not for you.

Ok. If you’re still here, I believe you understand the importance of recruiting right programmers. One of the important exercises to be done immediately is add 1 or more coding exercise in your recruitment process. Start with a simple problem, one  that requires some of the programming constructs and ask them to write code for it. Not pseudo-code. Actual program. Make sure the problem contains atleast 2-4 constructs like conditional logic, looping, modularization, data structure, etc.. as one sees fit. An example could be, from a list of numbers give me all numbers that are divisible by 3. As simple as that.

Look at how quickly one gets to solve the problem. In my experience, good programmers would be solving this the minute you’ve finished your question. Speed is not necessarily a measure of quality but can be treated as an indicator.

This is fine if you need just programmers. How about requiring good programmers? Do you need them? Yes.. ok lets go about doing it then.

Present a problem that involves more programming constructs and add a bit of design into it. You’d like to see how one goes about arriving at a solution. What are the approaches he takes. What are the approaches he doesn’t take, and reasons why. It can be a really exciting experience when you carry this exercise with a real good programmer.

I’d suggest doing this on premise and actually going through the whole process of arriving at solution. Thats the best way to do it.

One of the other approach I’ve seen is sending the problem to the programmer and ask them to submit the code. After submission, on premise, discuss with them about their choices and practices.

If you go with this approach, I’d rather suggest submitting code katas, screencasts.. This would give a nice idea of how a programmer goes about doing his job. How comfortable is one with his editor. What shortcuts does he use to get the job done. What classes he comes up with, etc..

To summarize, to build a good or even decent software organization, you need to focus on the kind of programmers you let inside. Better the programmers, better the kind of services or products you provide.

853679_41125724

Going to office or going to work?

Really, where are you going?

I’ve been thinking about this for quite a while now..

I spend about 1 hour 15 minutes to reach my office from home. That makes it about 2 and 1/2 hours daily.  On a five-day week, this sums to 12.5 hours (equivalent to 1.5 days of work). So as per figures, I lose 1.5 days of work time per week for a totally non-productive thing.

Now add money into the equation, if my per-day salary is about 2k, i’m losing 12k on a monthly basis (which is 1/4th of my overall salary). Thats significant money and time. Quite significant.

Ok. Enough of numbers. So.. why do we then go to office?

I’m of a firm opinion that it is absolutely essential that we utilize this time more effectively. And, it’s not just me. I see more and more companies are realizing this and are offering a alternative plan to their employees. Some even feel that offices would be “history” in few years to come.

We need to make some major changes to our mental setup to change this..

1. Need to identify better ways to measure work.

2. Communication facilities need to improve

3. Need better planning

4. Need to be sensible about collaboration and utilize time more effectively

5. Need to get more self-organized and self-employed style.

Of course, I agree that all nature of work do not permit this. But especially in software, its absolutely perfect. Infact, there’s a whole industry which works on remote communication. It certainly can work and work well..

Let’s stop going to offices. Let’s start going to work.

devcamp_new

My interactions at Devcamp chennai..

Wasn’t a regular saturday for sure..

Last week, on saturday, I was in NDTV office observing the shooting of a show on social media and its influence on the way we interact..  One of the arguments was that People have forgotten the art of social interactions. There are very less real-world communities.

Well, this saturday, this argument was totally written off. At Devcamp, we had 100+ programmers (creators of the virtual world) under one roof and discussing the thing that they love most. Technology.

This is not a recap of all the things that happened at devcamp. Its only restricted to my interactions there..

First mention to few people who I was meeting after a long time. Mr. Dorai Thodla(iMorph), Mr. Suresh Sambandham (orangescape) and Sriram Narayan(Thoughtworks). I admire each of them a lot and for different reasons. Was great to catch up with them and talk about various things..

Next, loved the self-organizing nature of the event. People were free to move around, talk to different people and discuss things the way they liked. Although, I felt the awareness level about Open Space Conferences was fairly low on the attendees. So at times it got a bit chaotic. But taking nothing away from the charm and enthusiasm, it was a nice show.

The presenters, I expected much more live code and variety of styles, which was missing. Most of the presentations were powerpoint stuff. Seriously.. in a devcamp you need to see more code. Editors, syntax, program, they were a little less. Guess, that will improve in the further sessions.

I had a presentation of my own along with Deepan, my colleague and friend, on “Code smells and Refactoring”. Got few techies interested and had a nice time discussing finer details of programming. (I had a full code session. No presentation.)

Next up was lightning talks/fishbowl sessions, which disappointingly had very little participation. So we thought, we’d change the style and invite people to talk based on topics we chose. It was an interesting little session, which really caught my imagination. Some really interesting topics discussed there.. Some of them are as follows:

1. Inspiration as a programmer.. Names starting from Larry Page to Joel Spolsky were mentioned as inspirations for being a programmer.

2. Products that we’ve appreciated.. Stackoverflow, Delicious, Winzip, Hibernate, Gmail, etc. were mentioned.

3. Products that’ll make future interesting.. Google Wave, HTML5 & CSS, Mobile apps, mobile/e-commerce. Here’s a post on it by Dorai.

Apart from these, there were couple of young Entrepreneurs (still in college), who are trying to change the world. Pretty neat stuff.

All in all, Devcamp was a step in the right direction. Though, there’s a long way to go still.

Check out few tweets here

Collaboration

Pairing – Why does it work?

Pair programming is an extreme programming (xp) practice that involved two programmers work together to finish off a task. They typically share the same workstation too.

Well.. the general perception of programming is, you have more programmers you get more stuff done. Now, it seems extremely inefficient to have two folks working on a single workstation. You’re working at 50% capacity in someways.

This is absolutely false.

When correctly used, pairing can be a great productivity boost, also helping in sustained growth in quality.  Let me share my perception on pairing since I’ve used it..

1. Sharing tool.

A team can have its senior folks pair with its junior folks on a regular basis and ensure that knowledge is shared in the best possible manner, at work (inspite of a theoretical session).  Even within a project, knowledge of different modules can be shared with all members of the team through pairing.

2. Dependency management.

By sharing and distributing knowledge with team members, you’re also reducing the dependency on individual programmers/members of the team. Hence reducing the risk of people moving out or overpricing folks.

3. Culture of equality. (No hero worship)

Since the knowledge and responsibilities are divided so evenly, you tend to have less heroics at work. Hence providing a very healthy culture of trust and respect within a team.

4. Reduce Developer Block time.

As developers, we often get into a state where we are blocked with a problem. Either we do not know a solution or we know a couple of them and are not clear which one to go for.. With a third eye always with you, this can be reduced to an extent. Two people thinking about a problem increases the chances of a better solution coming along, since both programmers can bounce ideas off each other.

5. Parallel Code Reviews.

With people working with each other, you are getting reviews done parallelly without hurting each other’s sentiments :). Typically Code reviews happen to be badly done. Most developers hate to accept review comments once they’re done with their code. But since its done while they’re coding, it works fine for both parties.

6. Development of good practices.

There are many habits and shortcuts that can’t be taught in isolation. Sharing small tricks and shortcuts become really easy with pairing. Also when you’re pairing with somebody good, it can really motivate you towards programming.

I’ll have to agree that I did not believe in these things before I started incorporating them in our daily exercise.

It works for me.