The Accidental Developer

Author: Praveen.V.Nair
Date: 12 July 2007

Send your comments about this article to

I have gone though different kinds of developers during my career. Different skill levels, different technologies, different view ports, different habits. This article is about "How to become a successful developer" for those who are now/going to become a developer from some unexpected accidental situation.

Usually everybody starts their career as trainee/fresher. After that he is converted to a 'developer' -> 'senior developer' -> 'project manager' -> 'team manager' -> etc. (hierarchy differs from company-to-company) Most of the people succeed with this way of progress. But the problem comes when a developer is an Accidental Developer.

What is an Accidental Developer? The one who converted suddenly to a developer because different reasons. Many small and medium sized companies upgrade their employees from non-technical position to developer post when tight schedules or resource shortage occurs. In most cases these people will make problems in their team. But it is not their mistake. The frequency of problems will be high when the project is a half done one.

The major reasons I see are:

  • Less knowledge in technology

  • No experience in analyzing workflow/business logic

  • No proper requirement study

  • Spoon feeding required from other team members

  • Lazy mentality since other team members go fast with their modules

    I am personally against such accidentally transformed developers. The company must train them first. But what to do when a high priority project comes? They are also helpless. But this developer can succeed well if he minds some points.

    How to be successful if you are an Accidental Developer?

    1. Give more time for this project. If you are an 8-hour per day employee, this wont work. For your next project you will not need to spend more time.

    2. Learn technology in parallel. When it is a tight scheduled project, you may not get separate time for learning the technology. So you will have to do it in parallel with the project development. Also, as far as I know – no clients will spent money for your technology learning purpose until it is a rare technology.

    3. Thorough study of requirements. The workflow/business flow of the project you can understand without any technology knowledge.

    4. Carry out technology experiments in other sample projects rather than doing it on the project itself. Many of us are like this. If you are developing a windows based application with Visual Studio, you can open another instance of the Visual Studio and do trials. So that we can make sure the project only holds necessary code. Unfortunately I have seen much useless code commented in many important projects while code-review.

    5. Obey your managers. May be he tell you to prepare test-case document. You may not know what it is. Rather than running away from him, try to learn-and-do. Always experience comes through this way only. From next project you will be perfect. Usually I come to know about these pending tasks only when we check it on pre-release meetings.

    6. Do not try to copy-paste others' code. Try to understand the program flow then adopt the necessary parts only. I have seen many people do this. The unnecessary code, unused variables and even bugs they will copy-paste to the new projects.

    7. Don’t be lazy. Another annoying thing is coding practices. The computer languages follow specific coding standards. Even though all have specific standards we can use it in a generalized form. Like use meaningful words as variables, filenames etc. There is a lot in programming section which is out of the scope of this project. But you can do one thing. If you used one variable “Helllo” and after sometime your found it. Rather than using as it is, correct the spelling of that variable and continue.

    8. Always do backups of existing pages, stored procedures etc. before you make changes. (If you are under source control, then no problem)

    9. Do not expect spoon-feeding always. Your team members will not like this always.

    10. Do not repeat your mistakes once you identified it. Also, it is not good to say “I did what you asked and if there is some mistake, then it is your fault”. You will not grow if your manager hear something like this.

    11. Think like a customer. So that you can trap most of the bugs.

    12. Understand time values. Do not think “I am a fresher; there is no sin in the delay of project completion”. Of course you are also responsible for the success of the project.

    13. Go through sample programs and ask doubts to techies or use internet. If your project is a half done one, then try to understand the coding of all existing pages. This will help you in avoiding repeated coding. Example, there may be a function code already exist which you also need.

    14. You must have desire to become a good developer. It should be your aim.

    15. Dedicate yourself to the project.

    Best of Luck for your project.