These are the compiled list of practices that I believe really help a software engineer to be efficient as well as optimally utilizing the skills and resources.
1. Write the initial plan at the beginning of the day. At the end of the day, update the status of your planned activities. It helps to:
1. Write the initial plan at the beginning of the day. At the end of the day, update the status of your planned activities. It helps to:
- Assess how effective and efficient you are.
- Reduce the number of items (sometimes insignificant) forgotten. [Planning]
2. Give preference to written communication instead of verbal communication. [Collaboration]
3. Keep a notebook with you. Write what you think, what you listen or what you are asked to do. [Planning]
4. Visually represent your idea. Use UML to represent your idea. This would help you to identify shortcoming of your solution and also increase your image to the team members. [Design]
5. While implementing/coding a logic, never derive the business logic from data. Even though it may look like that the change in the data is very unlikely and also controlled through your code, don't assume that it'll remain such down the line. Always use the true business indicators such as "flag", "state", "category" etc. to write your business logic. Some of the dead wrong software logic are: to identify a user as a Sales user, checking the value of the "commission" attribute; if an employee has direct reporting employees to determine if that employee is a manager. Rather, use appropriate flag or indicator if the person is a sales person or a manager. [Coding]
6. Always document your assumptions. Never assume that people will remember your assumptions; you may yourself forget your assumptions in few weeks, if not months. [Planning]
7. When you're asked to provide a ball park figure for the effort of implementing a feature, try to provide a range of effort estimation rather a concrete number; and if you can afford, mention the assumptions that you've made to estimate the effort. [Planning]
9. Never trust that user will provide data to the application in the case (upper case or lower case) you expect. This is specially true when you use the data to compare against a database table or against string literals in the code. The bottom line is to compare in case insensitive manner.
e.g. to check a user while logs in if the user exists, compares the user id in case insensitive manner or convert into upper case on both side of the expression. It will save you days in debugging production issues. [Coding]
10. Testing of software has to be verifiable. This can be identified summarize into the simple statement: Test result should be verifiable. The soul purpose of this principle is to make sure that every steps of testing in the software are verifiable which would have profound impact on the quality of testing. This would alleviate the controversy of "this was working before" symptom. [Testing]
11. Prefer database over file to keep the application configuration. It's always easier to access and modify the database than a file within the deployed application. Some example of benefits of using database are: easy to query, easy to create report, usually doesn't need application downtime (unless designed badly), corporate production environment is less stringent to database change than application file change, etc. [Design, Coding]
12. Never hardcode the deployment infrastructure in the application. You never know what would be the next deployment infrastructure your application would get. Also, never use IP address, physical server name, database server name, etc. in your application. Always use virtual names that could be mapped to that physical environment [Design]
6. Always document your assumptions. Never assume that people will remember your assumptions; you may yourself forget your assumptions in few weeks, if not months. [Planning]
7. When you're asked to provide a ball park figure for the effort of implementing a feature, try to provide a range of effort estimation rather a concrete number; and if you can afford, mention the assumptions that you've made to estimate the effort. [Planning]
9. Never trust that user will provide data to the application in the case (upper case or lower case) you expect. This is specially true when you use the data to compare against a database table or against string literals in the code. The bottom line is to compare in case insensitive manner.
e.g. to check a user while logs in if the user exists, compares the user id in case insensitive manner or convert into upper case on both side of the expression. It will save you days in debugging production issues. [Coding]
10. Testing of software has to be verifiable. This can be identified summarize into the simple statement: Test result should be verifiable. The soul purpose of this principle is to make sure that every steps of testing in the software are verifiable which would have profound impact on the quality of testing. This would alleviate the controversy of "this was working before" symptom. [Testing]
11. Prefer database over file to keep the application configuration. It's always easier to access and modify the database than a file within the deployed application. Some example of benefits of using database are: easy to query, easy to create report, usually doesn't need application downtime (unless designed badly), corporate production environment is less stringent to database change than application file change, etc. [Design, Coding]
12. Never hardcode the deployment infrastructure in the application. You never know what would be the next deployment infrastructure your application would get. Also, never use IP address, physical server name, database server name, etc. in your application. Always use virtual names that could be mapped to that physical environment [Design]
No comments:
Post a Comment