10 years in software industry - What I learnt?

What's this post about

As of  7 Nov 2015, I have completed 10 years in the software industry. I have started as developer support engineer and now working as application architect. Currently in my third company, working places range from Chennai, Kochi in India and New Jersey, US. Worked in products and projects. Lacks pure consulting. Technologies are mainly Microsoft, little bit of Android and HTML,JavaScript & CSS based web.

Just thought of scratching my learning and some advise to other fellow developers. These are solely my views. You may agree or disagree. Sometimes will have entirely different opinion.

• Programming
• Design - every programmer should create/have minimum design before typing.
• Hardest thing in programming is naming things. Spend some time during design at least for public classes, methods etc...Private things we can change at any time to a meaningful name.
• Do no think when coding. Do not code when thinking.
• But these activities needs to happen in short cycles. eg: Think and design for 15mins and code for next 15 mins and commit your changes.
• We can never build a generic generic program. If it was possible world does't had these much programmers.
• Think about generic mechanism and patterns, if something is repeating 3 times.
• Design API by first writing client/consumer apps. Better test from 3 different clients/scenarios before finalizing.
• Problem solving
• If struck on a problem for 30 mins, take a break. It will clear our bias and help to think out of the box.
• If the above is not helping explain the situation to some one who may or may not understand software. 90% of time, during the explanation new idea will pop up in our brain. Brave people can try rubber duck debugging also.
• Defect fixing
• Fix code by eliminating code not by adding code.
• More code, more defects.
• When testing team reports a new failing combination, try to add that in unit tests when fixing.
• There are some defects which will never get reproduced in development. But had to fix by looking/reviewing the code.
• Always write down debugging steps, so that you can restart from where you stopped after attending call from wife or girl friend.
• Code quality
• There is no perfect code. After spending days to finalize one class, a new person seeing that first can suggest improvements. Need to balance to meet the release time.
• Do not refactor for the sake of refactoring. Refactor as part of new features or defect fix. But make sure those are different commits to source control.
• Achieving SOLID is difficult. At least make sure your functions are doing one thing and write pure functions.
• If possible get the review done via writing unit tests.
• During day job, often the priority goes to meeting deadlines and developer will be forced to write bad code. So develop personal projects or participate in open source projects to write perfect code where there is no deadline.
• It is not possible to meet a deadline without any hacks. The quality should be maintained by fixing it immediately after the release. In case, its single delivery, try to fix before completion.
• Coding practices
• Assembly language era is over. JavaScript has got many minification utilities. So let's program for fellow developers to understand. They are going to maintain the code in future
• There was a misunderstanding that writing unreadable, complex code will keep the job safe. But that is not true as the new generation developers are writing code way earlier than us and they are smart to take over. 
• Keep state in one place. Make 90% of classes / code stateless.
• Do not keep different scenarios, you thought during coding in your head. Document as test methods. Else after some months you cannot understand why you wrote.
• Communicate what code does via proper variables,functions, classes and component(dll) names. 
• No comments for explaining logic. This is because when next person changes the code there is no guarantee that he will update comments.
• API documentation is fine. Eg: xml comments in .Net
• Source control, build & deployment.
• Commit your changes within maximum of 30 mins. If you are not able to complete something after 30 mins, go back to thinking/planning and split the tasks appropriately. First step can be creating the source folder structure / test classes and committing those.
• Do not comment the code for using in future by uncommenting. Its there in source control. If your company is not using source control quit immediately.
• Architecture
• Tough task is to balance between delivery timeline and quality. Should never go to extremes.
• 90% of the time it is not built. Its evolved.
• Do not stop coding. If you do so your design will be just boxes to developers.
• Spend time to validate whether code is following arch. Sometimes change arch to the way code is going.
• Try to avoid third party libraries as much as possible because each library is adding one more dependency on your plan.
• Have an idea/capabilities about all the known technologies at high level. Dig deep only when required.
• Think how architecture is going to be coded, tested, deployed and maintained before finalizing. At any point a developer, tester, infrastructure or support guy may come and ask how to do something in detail.
• Learn buzz words / technical jargon to talk to different people.
• Communicate to different level of people in different levels of details. To a client/stakeholder a holistic approach, to business don't use technical words, to managers only about deliverables and developers only in terms of programs.
• Project management
• Follow the below principle in Agile
• Get it done - Demo
• Get it right - Put into QA
• Get it optimized - Production and maintenance.
• Do not plan more than one sprint.
• Create a new branch in source control start parallel development only when its really necessary.
• Setup a CI & CD at any cost. Manual build and installation is old story.
• If there is no test cases, do not push to production via CD.
• Try to get code freeze at least 1 day during the build & release days.
• Let the developers fix the hacks during the code freeze. But do not let them check in to main branch on which the build activities are going on.
• When every project is starting customer will have a fixed goal. Its us who should throw new ideas,improvements towards them and keep continuing the project.
• Make sure those ideas are business related and towards cost cutting for client to improve their profit. When client's profit increases our profit will also increase.
• As a team member
• Ask others to review your code and accept the good parts. Even ask juniors to review your code.
• Do not just say its not working to your technical lead without a proper description or screenshot of exception or some links saying its defect. They will think that you don't know, didn't do debugging and google.
• If you are taking a hack or shortcut, add the details with web links as comment in source code. So that future developers will not blame you. Do not keep it in mails, because the new members into your team will not get the mails.
• Always give suggestions to business analysts requirement documents, proposed user interfaces. Most of the time they may not be knows what are the capabilities of technology.
• Try to be truthful to testing team. When they come up with inconsistent help them to reproduce by understanding the code.
• Team management
• Always have one meeting in the morning and let the team explain what went yesterday and what is the plan for today.
• Try to reduce the time required for your team to send reports. Get the details from task/project/work item management systems such as TFS.
• Always look at the code your team is producing. To your superiors its your code.
• Keep quick access to release dates, number of features and defects total and pending. if you can remember some showstopper/high priority defect ids, you will be a star.
• Do not let project depend on one person. The show must go on at any cost.
• Give ownership of tracks/components to single person or teams for fixed time say 6 months. Rotate the members to different teams in every 6 months. But never replace everyone in track in single shot.
• Quality in software engineering
• If you are clicking everyday as part of testing app, try to bring automation or look for next company.
• Enterprise Application Development
• Most normal things won't work in enterprise. Many things done there doesn't have any common sense. But have to do to keep the project moving.
• It is very difficult to bring a change in enterprise.
• Self learning and carrier improvements
• Read others code.
• Debug for others. 
• There are many who can type code. But very less who can debug code.
• Try to look into third party libraries. If its unmanaged, it will be difficult but in all the other cases its possible to view the source code of third party libraries. Obfuscation makes it little difficult though.
• Learn one new language every year
• Read at least one technology book every year.
• Improve searching/googling skills. A best programmer needs to be a best googler.
• Never waste your brain memory for language syntax. Google can give it in seconds from internet. Instead free brain to keep the capabilities and think freely.
• Do not spend much time on learning short living frameworks such as Silverlight. Instead spend time on long living concepts such as http 2. 
• Try to create and publish reusable libraries. There are very good library management infrastructures now a days such as nuget, npm etc...At least contribute to libraries. If there is no time to fix defects report the defects in the libraries.
• Learn how things are working end to end. From business analysis, design, coding unit testing, functional testing, business testing, build systems, continuous deployment, application support and how to work with patches.
• If you want to become a good business analyst you should be knowing what are the developers problems and how developers interpret the requirements document. For that best way is to work as developers. Similarly if you want to be good developers, you should know how QA tests your app. Again better way is to know is to work as QA. QA may not catch all the defects but its caught in application support. So to do better testing you should be knowing how the users use the system and best place is to work in support. To me an ideal career path is Application support->QA(manual + automation)->Development->Business Analyst. Join as support and climb the ladder, If there is no chance to climb in current company change the company.
• When to leave company
• Evaluate your activities in your company at least once year other than performance appraisal. If you feel you got only salary in return, leave the company.
• If you feel you are the ultimate authority of something and everybody depends on you as you are the king, leave the company, because your growth is over there.