Every software firm has but one goal: to hire the best possible developers. As intricately designed as the hiring process may be, the proof lies in the pudding. How are some software developers able to complete projects in a timely manner with expected or surpassing quality standards while others fail without mention? We rounded up some of our star developers to find out what sets them apart, what values drive their decisions and how they make themselves effective. Check out their top tips below:
I actively follow sites such as eweek.com, sdtimes.com to stay updated on technical areas relevant to me as well as the industry in general
While not a practice or a habit as such, it is also crucial to be a part of a challenging project where the team also includes expert developers so that you get constant feedback from your peers and get exposure to good quality code and various architectural patterns
Although it’s important to be specialized in a particular technology, it is also equally important to have high level knowledge of multiple technologies at the same time which can be achieved by following industry experts and reading blogs
Getting your code reviewed by your peers is a great way to learn
Subscribing to video-based educational websites such as Pluralsight lets you explore various facets of software development.
Working on a side project in the area of interest is a great way to grow as well
Sunil Thakur, The Big Word
- I like to read technical books regularly and try to use the concepts in my day to day work. Few books which have improved my coding skills considerably are Clean code, Effective Java and Pragmatic programmer
- I love to take problems head-on even if these are unrelated to the current task and could be ducked. This gives me larger view of the software and adds diversity to my skill-set. Though it requires some extension of working hours, it gives me the satisfaction of having learnt something new
- I strive to learn new technologies/ideas on a regular basis which help me find an optimum solution to a problem. I also spend time keeping myself acquainted with the activities of other team members to understand their work and get new ideas
- With experience, I've realized that it's very important to develop high quality software (clean code) apart from providing a solution to a problem as in the long run this makes maintenance of the software easier. It also saves a tremendous amount of time in understanding/debugging the code
- Whenever I need to wait for somebody's response to move further in a task, I utilize the time in re-factoring my previous code and with every revisit, I eliminate mistakes
- I conduct/attend sessions on various topics selected by team members to share ideas on a regular basis which helps everybody increase/improve their skills
- Reviewing other's code and working on review comments of my code is a great way to collectively improve the quality of the software
- I ask a lot of questions about a task/topic after going through the design document multiple times. This helps in understanding the problem better and in releasing the software with minimal bugs.
- I regularly visit standard public libraries/custom product libraries from where I can pick up pieces of code that are already available – helps save time and gives you access to readable code!
- Before deciding on new technology additions to a project, always research the best options available in market and more importantly, still has an active development program. Evaluate the options first by implementing a Proof of Concept that reflects your real time environment as closely as possible. Decide on an option that gives the best balance with your environment.
- When functionality can be implemented in slightly different ways, always communicate the same with concerned stakeholders beforehand, take their opinion and apply them. This can avoid future changes to the same by stakeholders after delivery.
- When waiting for clarifications on requirements from stakeholders, do not sit idle, you can still continue writing with some mock code for the clarification part. When clarifications are received from stakeholders, just replace the mock code with required code.
- Internal code documentation is important for a developer to explain the logic and code functionality; it is most useful for other developers who would maintain the code at a later point of time. It will also help the code author to recollect about the code written long time back. It is best to write the internal code documentation as we write the code instead of planning it for later, planning to write it later has the risk of getting busy with something else and ignoring the documentation. A big code without internal documentation is like flying a plane in zero visibility
- With source version control, we should update as frequently as possible, even multiple times in a day instead of doing the update in bulk every few days or week. Longer frequency would lead to conflicts putting repository merge at higher risk of getting corrupted. Always make sure the source you are committing is in compilable state
- Smart programming saves lot of time and effort - always be aware of the best programming practices and patterns and apply them to your code on regular basis
- Avoid refactoring or optimizing a code if it requires lot of retesting, why break something if it is already working. Consider optimizing a code only when a new requirement comes for that code and requires retesting as part of project plan
- Clean up code frequently, piling of commented and obsolete code will just add to the file size. As much as possible, depend on automated Unit tests and End-to-End testing, link to a build automation and testing process. It can save a lot of developer time to identify and fix issues faster
- For converting requirements to implementation, when in doubt, always ask the concerned analyst even if you have to annoy them with frequent questions.
- It is best to have clear requirements during implementation than ending up with wrong functional implementation. This will help avoid wasting valuable developer time and overshooting delivery schedules
- Always take responsibility of testing your code and implementations instead of pushing it to a tester; you can deliver your code faster if you test it yourself thoroughly before the tester tests it further
Byju Parameswaran Nair, COAS
- Share information freely with others in team and forums; always maintain camaraderie with co-workers
- Strive for excellence and do everything with integrity
Mohana Krishna Yadav Pallapothu, GAC
- READ & STUDY anything related to technology. I also do code reading of Open Source Projects to absorb different styles of coding.
- During development and bug fixing, I usually spend a lot of time testing the system, to ensure that my changes are not breaking any other part of the system
Saurav Chakraborty, CGR