![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
In a previous post, I asserted two points which can be developed further.
The dichotomy between a performance engineer working on a product and a consulting performance engineer like myself is not quite accurate. I was writing that a consultant's life is more interesting, and an expertise is wider. (May be not too wide as there is still even further specialization, e.g. telco dataplane, high load web, HPC, embedded, HFT, etc). However there are performance engineers who work on a single product and still have a very wide expertise. That usually happens when the product is a popular middleware platform: a virtual machine, a database engine, a business intelligence/CRM engine, etc. These guys are real monsters (I won't list lj/habr user names here :))! The only expertise they may be lacking comparing to consultants is commercial foundation (stuff like GTM strategies, estimating synergies between product development plans combinations, and other MBA-esque stuff).
I was also writing about iterations of the optimization cycle, that each new iteration is similar to the previous one but a bit harder. In fact there are very different types of iterations: looking for performance improvements at Algorithm/domain level, System level, microarchitecture level. The product performance team folks usually excel at algorithm/domain level optimizations. As a consultant working for a platform vendor, I am deep in u-arch level and somewhat good at system level. I need to improve in algorithms, but it is futile: in actual customer engagements there is very little need for it, I don't know why. In theory it should be the most important part of such work, but in practice there is a difference between theory and practice :)
The dichotomy between a performance engineer working on a product and a consulting performance engineer like myself is not quite accurate. I was writing that a consultant's life is more interesting, and an expertise is wider. (May be not too wide as there is still even further specialization, e.g. telco dataplane, high load web, HPC, embedded, HFT, etc). However there are performance engineers who work on a single product and still have a very wide expertise. That usually happens when the product is a popular middleware platform: a virtual machine, a database engine, a business intelligence/CRM engine, etc. These guys are real monsters (I won't list lj/habr user names here :))! The only expertise they may be lacking comparing to consultants is commercial foundation (stuff like GTM strategies, estimating synergies between product development plans combinations, and other MBA-esque stuff).
I was also writing about iterations of the optimization cycle, that each new iteration is similar to the previous one but a bit harder. In fact there are very different types of iterations: looking for performance improvements at Algorithm/domain level, System level, microarchitecture level. The product performance team folks usually excel at algorithm/domain level optimizations. As a consultant working for a platform vendor, I am deep in u-arch level and somewhat good at system level. I need to improve in algorithms, but it is futile: in actual customer engagements there is very little need for it, I don't know why. In theory it should be the most important part of such work, but in practice there is a difference between theory and practice :)
