Here's how you can use your past experiences to tackle new software projects as a mid-career engineer.

While many think that they can use their previous experiences to suggest what can be the best way out of a situation, however, the experience has to be vetted against the current developments and need to be overlayed to the latest processes in place. A thorough analysis of existing scenarios have to be done before applying your experiences. What was the process and system when you had that experience could be different situation now and might not be applicable. I talk to my team members especially the ones who are having hands-on experience with the latest technology and trends to understand what needs to be learnt. Experiences only may not help.

When I was with Professional Services at Amazon Web Services, we were told - "We didn't hire you for your experience but for your expertise. Forget all about your experience and help us grow with your expertise." It is very important to reflect, contemplate and externalize your previous knowledge in black and white. You must draw the essence of the experience and uncover insights that are generic principles. Actual experience is very specific and may not be applicable because specifics keep changing. Human nature doesn't change and technology principles need to be codified from your specific experience. Once you have those principles to guide you, you can apply them in newer contexts.

Reflection allows us to improve our personal process effectiveness. This is the same reason scrum does retrospectives: to continuously improve the teams capabilities and output.

Be brave and bold. Switching from waterfall to agile requires a leap of faith. Go all in, assuming the new methodology is valid, as demonstrated by other teams. You will be pleasantly surprised. :-)

Fully agree. There is never a pause in learning and understanding new technology. One can only do justice with her / his experiences if you know what is happening currently. Don't try to suggest a solution through agile methodology, if you use your experience of the waterfall model.

While optimizing SQL queries, a rule of thumb is to avoid queries that result in full table scans as they are expensive in terms of time and resources. However, there are exceptions to the rule where sometimes a full table scan is faster and cheaper. You must develop the intellect to know when to do full table scan and when not to. Hard commandments like absolute Dos and Donts have no place in an every changing world. It is much more effective to be flexible about feedback from reality and change course instead of being married to your opinion and take stubborn positions because of your ego. Ego is the enemy. Ryan Holiday wrote a book with that title. Change strategy based on real world feedback instead of staying the original course.

When you are a Do It Yourself-er (DIY) around your house, you tend to collect new tools and ways of doing things. You might buy a drill, a table saw, a jig saw, etc. The same applies to your coding; you learn new tricks that you can apply to new problems. Also you get to identify things that don't work and look for a better way of doing it. Iterate, Learn and optimize...

Absolutely! If you are not re- using you are not an engineer or a scientist. No one wants a clerk to write software code. Focus on developing new ways and add efficiency while re-using. Cannot afford to do repeated work with current pressure of go-to-market timelines.

Code reusability is of utmost importance. It’s sometimes important to realise that you don’t need to redevelop or recreate what already exists. Anything from previous code implementations to open source code that is relevant to your scope of work should be reused. This increases your productivity and speed in delivering software solutions

Avoid having multiple copies of similar code. This complicates your life as you have to make fixes in multiple places, test multiple times, and generally have more code to maintain. There are many techniques for using code. 1) Add parameters or configuration file. 2) Use interfaces to pass in objects that implement unique behavior. 3) Create a reusable class ...

If you can teach it, then you really understand it. Find people that know what you want to know and work with them. Go to meetups. Build things. Whenever you have mastered something, pay it forward and teach someone else.

Project Management is about risk management to meet a scope, timeline, and cost. If there is something key to your development work that is tricky, think about the fastest way to prove a particular approach will work. Once you do that for all your major challenges, you will have de-risked your development effort.