So you have been hired into a software development organization and are wondering what (besides being a super programmer) do you need to keep in mind to be successful? Here is a list of things that I have learned over a period of 15 years that should answer the question:
-
Understand the problem that the product is solving : This is key to being really good at your job. It is surprising how many very smart developers actually overlook this when doing their job. Knowing why you are doing something will help you make wise decisions on usability, interface, correct use of domain terminology, test case development, user documentation, and choice of data structures and algorithms.
-
Determine the access points to the application: How many ways can you launch the application? Does it launch through an API call, through some UI, command line or a combination of them. Depending on the answer, the initialization environment should be understood and tested for compatibility and consistency.
-
Keep the initialization dependencies to a minimum: This is related to the above point. For example, say an application can be launched from command line and through an API call. You need to ensure that the environment dependencies that you plan for initialization are repeatable and consistent across both access methods. For example, say you need the LD_LIBRARY_PATH (or path in windows) set in a certain way to run your application and you have it set when the application is being launched from the command line. However, when launched from an API, it is possible that the calling application may have set the LD_LIBRARY_PATH in a way that conflicts with your requirements?
-
Understand flow of information in and out of the product: Does your application read in data from some upstream application? Is the output of your application read in by some other application for downstream processing? If yes, then spend time to understand the formats and their consequences. Sometimes a trivial change in your opinion may have significant domino impact in downstream tools impacting customer productivity.
-
Study competing products and business environment: I cannot emphasize this enough. Know what your competitors are doing and how the business environment is evolving. This knowledge will go a long way in your ability to add value to the product and the organization.
-
Know your data set size: This is a tough one, but knowing what is the datasize that you are going to operate on helps you in determining what data structures and algorithms to use.
-
Know your customers: Are you developing for non-tech savvy customers? Or are your end users engineers? If the former, focus on usability. If the latter, you may be better served by focusing on extensible frameworks (and associated APIs) so that your end users can extend the system (not at the expense of usability though ) An excellent by-product of developing with framework mindset is that it results your software being embedded very deeply in your customer’s DNA making it very difficult for them to move to a competitor.
-
Know your delivery media: In the age of multiple delivery mechanisms, including a mind boggling variety of portable devices – spend some time understanding the target media devices and their strengths and weaknesses. This will help you design user interfaces and functionality in a consistent and predictable way.
-
Use open source wisely: There are a large number of open source libraries and solutions available that you can download and integrate with your products. However, there are legal implications to that. Understand your company’s policy on open source and take the effort to get a legal sign off for any integration (even if you are certain that the integration is not violating any policy).
-
Build debuggability: Build into your software the ability to generate special logs if a certain environment variable is set (or application is launched with some special switch). This is particularly useful when you have to do a remote debug because customer environment is causing the application to not launch or work correctly. A good example is to use assertion in Java programs.
-
Understand legal implication of gathering data: A natural tendency of any organization would be to improve its products on the basis of user feedback and usage data. Be very careful on how you gather this data and get it back from user environments. Several organization have very strict policies on what (if any) data can be shared with outside vendors, even if it is essentially benign in your opinion. It is best to make a full disclosure on what you would be getting from the user and have it legally signed off.
- Consider possible differences in end user environment: This one was shared by a friend of mine who is a rockstar coder. In one particular customer environment, the product (Java based) that he had developed was working in exactly the opposite way that it should have worked. After several hours of debugging, he figured out that the reason. This was because he had developed using the standard Oracle (then SUN) issue JDK and tested in the SUN JRE. However, the customer site was using an open source JRE and one of the APIs in use had a different implementation as compared to the SUN JDK/JRE. Just in case you are not aware – Java is essentially a specification, and SUN/Oracle JDK/JRE is one reference implementation. So in general, they should all work alike – but there is always that one crazy corner case to drive you nuts.
Source: Linkedin
