A Good Developer

What it makes to be a good developer? This question keeps popping now and then in my mind especially when I hear complaints from managers and leads saying their developers are not good enough. In Sun Tech Days couple of years back, there was a session according to which below are the 7 best habits of a good developer.

1. Understanding the Problem
2. Use appropriate tool
3. Strive for Simplicity
4. Keep your code clean
5. Learn to debug
6. Leverage whatever available
7. Plan ahead

Lets discuss these in the context of general projects in Indian service industry

1. Understand requirements. This doesn't mean developer must have domain knowledge and understand business requirements but at least they must understand what should be done on click of Submit, click on Cancel, what formatting and validations need be done etc

2. Tools should have been decided before development start so lets not dwell much on this

3. 'Think Simple' - I keep telling my developers. Your performance is not measured based on number of lines you code or how complex your logic is.

4. Learn to code lean and clean code. This is possible only when following coding standards becomes a practice rather than compulsion. Also developer should emphasize on learning programming than programming language. I don't mean we don't have to learn any language but if you don't know how to solve a problem and write a basic algorithm there is no use of becoming an expert in Syntax of any language. Again you don't have to solve complex issues. Take for example age validations, if you don't know how to calculate age is there any use even if you know whole Date API in Java? Also emphasis more and more going in getting things done than on how? If developer gets a function point implemented that's enough, we rarely see leads reviewing for algorithm or developers caring to analyze their logic. No one to blame because of time lines but if you want to become a good developer your logic and its performance does matter a lot. Remember the Algorithmic subject thought in college and the order of executions?

5. Debug the code - No one writes a perfect code in one shot. With the latest IDEs and plug-ins debugging is easy than coding.

6. Leverage whatever available - Most of the things we do these days we are not the first ones doing them (Unless you are lucky like me). Refer organization's reusable repository, colleagues experience or online community to get the code. God had given us Google and a brain to use it.
7. No need to stress about time lines... Think and plan ahead. One of my professor used to emphasize to have complete algorithm written on paper and analyzed before even writing single line of code. Plan should include similar thing.. plan what to be coded and how to so that you wont end up with rework or stuck in middle.

To summarize, to become a good developer first thing to learn is problem solving (say analytical skills or whatever). Learn from all possible sources (read open source code, online material etc).

As Brian Kernighan and Dennis Ritchie say.. "only way to learn programming language by programing in it".

Any training can teach you API but not thinking.....

HTTP Session Managemet - Restricting approach

HTTP Session management - a frequent discussion point in many projects and frequent reason for performance issues in the projects. Recently I happened to review a project which takes nearly 5 mins to load a page that contains a table data. And after visiting this page application becoming slow. Reason is, application retrieves all data in one call and stores it in session scope and is not removed after traversing out of the page.Time and again managers feel need for design that controls session usage. Recently I initiated a discussion on IASA forum to gather ideas from community. I always felt HTTP session proper usage should be more of guidelines than framework. But if session timeout is more than usual 20mins, we might have to go for policing policy. Based on responses in the forum and my experience I think of below solution.

1. Applications cant totally avoid session but should limit the usage. So while design identify the objects required to be maintained in HTTP session. Create a Class which will act as place holder for all data to be kept in session. This will be POJO with the objects that require to be kept in session as fields. So only objects that have setter method on this object can be set to session.


2. Add a Session Listener. This will be a class implementing HTTPSessionListener. This need to be configured in web.xml. There are three methods in this interface. One of the will get executed whenever an attribute is added. This method in listener implementation should remove the added attribute excepting the predefined ones. (Apart from the object of above class, application container will keep some objects in session. Listener should discount them too. This will restrict the HTTP Session usage)


3. Container object created in step1 can have a public method to calculate the size of itself (which means size of objects in session). Application can use this method for auditing like displaying http session data from application on a special page etc.


4. Above solves one part of the problem, application still need to take care of clearing the data (by assigning null to the field). This can be taken care by application code. If need to be part of framework you can provide a configuration file which defines permitted data for each action/module. Define a some Intercepting filter that will examine the Container object and remove the unwanted data.

Its easy to implement and maintain. As every one agree its good design and implementation adhering to design that will result in good application