Responsibilities of a Developer

I’ve been doing the development now from more than a decade. In my experience I have noticed the following responsibilities of a developer.

Task Ownership

Every developer should take the task ownership, by task ownership i mean the tasks given to any developer are his responsibility to analyze, code, test and deliver. If the task is dependent on any other resource than an excuse should not come as saying my tasks is delayed because i was waiting for others, instead he should keep in touch with others involved in his tasks and help them if required so that his own tasks can be finished as well. In my view the more ownership you will take of your task the better developer you will be.

Real-World Analysis

It is also the responsibility of a developer to do the real world analysis of the tasks given to him. Sometime the requirement he gets doesn’t contain some vital information which if he will not find out will break his code in real world. So, every developer should ask the following questions (not just the ones mentioned below but at least) to himself:

How his code is going to work in real-world? in peak and non-peak hours.
How his code will behave when it will be integrated with others code?
Have I covered all the good and bad scenarios in which my code will run?
Have I put enough debugging information in case anything goes wrong to find out the root cause of the problem?

QA of his Code

Every developer should do the QA of his code but i have seen most of the developers are lazy to test their code. Some of them consider its the job of the QA guys but infact its one of the prime responsibility of the developer to first test his code before handing it over to the QA team. Test driven development is good and saves a lot of time and remove headache of the developer in long run as with proper unit tests and manual QA he can find out so many bugs very early in the life cycle of his code. QA guys don’t know what you have written so they cannot find many potential bugs which you can easily with some concentration on the quality of your code.

Code Documentation

Writing no documentation of your code is the biggest evil of software engineering. In my view before implementing the core logic, you first do two things 1) write unit tests 2) write comments. Code documentation should come in following ways:

1. Class level documentation

Before starting a new class and implementing any methods in it, first write the following in that class comments:

• Purpose of that class
• Responsibility of that class (apply SRP* design principle)
• Usage of the class
• Threading implications

* SRP is a design principle which state that “Every class should have single responsibility to exist. It should does only one thing and does it well.”

2. Method level documentation

Before implementing any method, first write the following in that method comments:

• Purpose of that method
• Method signatures
• Possible exceptions
• Threading implications
• Overriding implications
3. Code level documenation

Before implementing any core logic in any method, first write some comments about what you are trying to solve there as not everyone is smart as you are. So, in order to understand your complex logic they need some help and good comments comes to rescue here.

Support of his code

Support is another very important responsibility of a developer. Whenever there is an issue in production, every developer should be available to provide the support of his code 24/7. Making reliable production systems is not an easy job and there will be times when your support department will call you to assist them as their customers are complaining about some malfunctioning of your code. When that times come make sure you are available and looking to resolve their issues in the best possible time.

Grooming other resources

When you become senior and you have members in your team who are recently hired or not as experienced as you are. Now, its your job to get them up to the speed and teach them about the product they are working on with you, about the tools and technologies you are using, about the best practices you are implementing, about the unit tests you have written, and work with them in harmony.

Refactoring of your code

Time will come when your code will require refactoring on many areas, do not hesitate to do it once you have good unit tests to avoid the possibility of broken code. If you do not have unit test write them first.