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/)
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.
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.
1 comment:
True! I sometimes find myself naming the files and folders unconsciously as trainTicket, guruSongs, etc.
Post a Comment