There are some tips I have learnt on how to navigate new projects effectively. I would look forward to hearing what you have to say about yours. And, I suspect there will be more.
- The more experience you get on multiple tools and technologies, the easier it is to move to newer projects with newer tech stacks.
- The more you master one programming language, the more difficult you find adopting another language. Especially if you are a perfectionist.
- The more you expose yourself to various languages, the better you program in all previous languages.
- The quicker you understand the domain of the project, the quicker you understand the code of your project (unless people in your team like naming everything as “data” or “temp” or “value” or “count”, in which case you are doomed, and you should quit).
- Understand the database of your project. The database brings insights into relationships between entities. These relationships will remain permanent for a very long time, while the code on top that manipulates the data, will keep getting refactored. Once you get a handle on the data, the code becomes much easier to understand.
- Pair with QAs. Perform testing. You will understand the domain, and the interdependencies very fast.
- Ask questions, write notes, and volunteer to take sessions on project topics / technologies. Nothing teaches us faster, than the pressure to not look foolish.
- Try and understand the reasoning behind why features are being built, because 60% of the features in all software products are built for the same purpose — each using a different technology or tool. For instance, every corporate website has Search, Page Analytics, Splunk Style Logging, Meta-Tagging for SEO, JS/CSS optimizations for performance, Device & Browser Detection and Cookie Manipulations for Personalization, Responsive design, REST based integration, SSL, etc.
- Follow a user journey in code — to understand all the layers involved, and how they interact. A decent codebase, usually has a few patterns that are repetitively used.
- Use a good IDE for navigating code. They will help you understand code paths, callers, implementors, etc very quickly. I use IntelliJ (Cmd+Alt+F7), and Sublime.
- Read the unit test to understand the class. Of course, I work at ThoughtWorks, and therefore have the luxury of seeing self documenting unit tests. And this means, I am indebted to ensure that readers of my code also get a good unit test.
- Hunt out for project documentation — especially those which pertain to large scale features, architecture, etc — as they summarize information quite well.
- Sign up for devops tasks. They will help you understand the interdependencies between systems very quickly.
- Find out who's who on the project (customer side), so that you know whom to reach out to, for what insight.
- Have patience. It takes a minimum of 3 months to “feel” effective. And then another 3 to be “one-with-the-project”.
I know. It’s not a shortcut. It’s a path.
No comments:
Post a Comment