>> it could be argued that our engineer had taken >> seven years to accomplish this task, it's just >> that they had worked six of them at a prior company Th

>> it could be argued that our engineer had taken >> seven years to accomplish this task, it's just >> that they had worked six of them at a prior company Thats a great line - I think it reveals a lot about the impact relevant experience has on productivity. Its truly awesome when it works out but change the problem or the technology and the 40x engineer becomes a 0.2 engineer in the short/medium and sadly sometimes the long term too. I see two main problems that prevents experience always compounding positively - technology churn whereby a master carpenter has to switch to metal every two years and the unspeakable variety and flexibility of the software medium. I see software engineering as a collection of 1000 niches rather than a homogenous whole. RT embedded vs. data center vs. client-side vs. 3d vs. mass consumer and hitting market first vs. 10 year continuous improvement vs. safety critical etc. there is only so much overlap between them. In one niche, killer productivity might be unlocked by leveraging libraries, in another by reducing dependencies. In one niche highly defensive programming may be the winner, in another rapid iteration might be the secret sauce. In one you need to master the theory, in another you need to abandon it. We too easily learn lessons in one niche and don't realise they are not generally applicable. This is also why comparing two engineers is pretty tough. You can test them on the same problem but this will only ever be a narrow view of their comparative strengths.