This is the last part of a 3 part series on creating a performance engineering trajectory for yourself. In Part -I we looked at how to start shifting your approach towards performance engineering. In Part -II we addressed some of the tactical challenges that performance testers face. In this part we will talk about how to build a learning path for yourself.
Irrespective of the opportunities that you are offered through your projects, you should create your own learning path. In this section I provide some guidance on how you can setup some short and long term learning goals.
To be a good performance engineer, you have to be a good well rounded engineer. You can't be just a performance engineer.
Take charge of your learning path. Don't just rely on your job/projects to provide the learning curve. One project at a time is too slow a pace to grow.
When you study the architecture of an application there will be a lot of terms/tech/products that you will not understand. Research them. Get to the WHY a particular tech/product is being used.
For Example say you see Memcached in the architecture, read about it. What is its purpose in an application design? What problem does it solve? How have some other folks used it? What are the best practices around it? Are there other similar solutions in market? And if possible try to find out how this product performs and scales. You complete the whole learning cycle. Now, you understand how caching solutions work, what are the types of solutions available and how applications typically implement/leverage them. Next time you see another architecture and see Redis, you already know what it does.
Now come back to your application architecture, look at it with this knowledge you have acquired. You will understand things a bit more than you did last time. Move on to the next term you don't understand. Repeat!
Once you have done this for few different applications, you have automatically increased your tech vocabulary. And this is what helps you mature as an engineer(not just performance engineer).
I have found this to be the single most effective way to learn. You have to have the passion to learn technology. Because it can get difficult when you have 15 complex load runner scripts to complete on deadline :)
If there is one thing that you take away from this write up. It is this!
As you read about new tech, make sure you also do it through the lens of performance. You should find out the performance/scalability characteristics of the product. Few pointers to doing this - Understand how its runtime works, check for datasheet or any published scalability numbers, see if people have reported performance bugs on git or product forums, are there limits to how much it can scale, are there conditions in which it doesn't work well(ex. high latency) etc. This is a long list and one that you will hopefully develop an intuition for over the period of time.
Setup an environment for yourself where you can do your experiments. This is your way to not slow down due to "lack of access".