Code is Beautiful

If you ask me what is the difference in me as a programmer from the time I left college, I would say it is my view of coding. At college, I loved algorithmic problems. It used to be a favorite post-lunch past time at college; a bunch of us huddling around the Bodhi tree right outside our department building and have a go at some wacky problems. We also used to have rapid-fire coding sessions where we used to code in-order to verify the ‘correctness’ of the algorithms.

Nowadays, as well, it is the same intensity with which myself and few of my colleagues solve problems, but when it comes down to coding them, well, there’s a big difference now….

A simple example, to give you an idea,

int x, y, z; // in college days

is nowadays,

int noOfVertices;
…
int noOfEdges;
…
int edgeConnectivity;

and that too, in different portions of the program, i.e. closer to the context where they are used. Guess you are getting the point.

This love for coding started with the exposure to real-neat enterprise scalable code in the organization. It was not love at first sight though. The very first time I saw how many lines of code change you needed to do something which took about one line of code at college, I was a bit aghast. At first, it gives you the feeling that this is probably some rule of conduct in the industry that classifies it as ‘enterprise’ code.

But very soon the dynamic nature of the software requirements and functionality hits you in the face and you realize the beauty of those lines of code that looked so abstract early on.

Welcome, to the world of design patterns. These nifty set of tips and tricks take the pain of software maintainability away from software developers. But it is important as well that they do not overwhelm you. Two points in this sense are to be noted:
- Inappropriate use of design patterns.
- Overdoing of design patterns.

A few books that are worth mentioning in this context that help you avoid the above pitfalls are
Effective Java (http://java.sun.com/docs/books/effective/)

Agile Software Development, Principles, Patterns, and Practices (http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445)

So one of my favorite questions at industry interviews is to ask the person to write some really simple recursive code. Recursive code in-spite of not being the optimal solution in many cases still catches my imagination because of the magic in the way it works. It’s really amazing how a few lines of code can neatly portray the solution to a really complex problem. Potential hires come up with neat and concise code. It also pays to observe the gleam in their eyes as they explain the solution to you. You know that you have a good candidate.

Will cover the “Art of Interviewing” separately in a later post. It’s a cool and very responsible art of sketching the character of a person in half-an-hour.

Signing off.

Management - What it should really be

If you are looking at some really good discourse on management and software practices, then please move on to http://www.joelonsoftware.com/Archive.html.

This post is from a yankee who landed in the industry in 2004 right out of college looking for some really challenging techie work. Must say that my career here so far has provided me with lots of those, but interestingly, it has also taken me through a roller coaster ride on how exactly do you lead a bunch of people.

Even though at college, we had learnt the principles that make a single guy at the top to manage an extremely large organisation with thousands of employees under him - Hierarchy and Delegation. All that sounded very nice when we learnt it, but once in the industry, the reality bites you hard. How I just wish delegation just meant transfer some of your responsibilities to a person below and get the work done. Probably, it might work fine in software design where-in high-level modules delegate their work to low-level modules. But it is just not the case when individuals are involved.

To get to the point, Management, in short, is about,
- Respecting the individuals under you.
- Trusting the individuals under you.
- Caring for the individuals under you.

[probably I reiterate the term "individuals" often as against "people" but that more goes to say the stress am laying on it]

Management is in reality all about relationships with individuals. Management is personal. In another sense, management is about listening. The more you listen, the more you understand the individuals under you and the better you can care for them.

That is why, people, ahem, sorry, 'individuals', more often don't leave their jobs; they leave their managers. So the key to building a great place to work is not about having great paychecks or great perks for employees. It is just about having a mechanism in place that ensures that managers care for those under them. Any organization that achieves this, whether it be a mammoth organization with thousands of employees or any run-of-the-mill organization with half a dozen employess, is sure to be a great place to work.

Another common misconception in many employees mind's is that once you rise to management levels, all you need to work around with are schedules and deadlines. So when it so happens that such employees do permeate to higher levels, the life becomes tough for those down under.

I would like to sign off for now with the role of management as defined on this site (http://www.fogcreek.com/About.html), [the CEO of this company is the guy who writes the JoelOnSoftware blog (link in the first line of this post), it is one of my favorite sites, so please bear with me if I keep getting back to this site in my future ramblings.]

" ... management, not coding, is the support function. Management is not here to make decisions, but to get all the furniture out of the way so that software developers can do great stuff. ... "