| This statement trivializes far too much the mechanics of code and software. The 'process requirements' like RFCs, tech specs and requirements, are important, but they're not generally that hard. It takes 5 years of being surrounded by 'good devs' to understand the more material aspects of software - and the very long list of more mundane things. It's like an apprenticeship. There's just 'a lot to know'. Basic style, approaches to solving common problems, getting comfortable with the toolchains etc. On mobile, just knowing when to do something in 'native' on Android vs. not. Just getting comfortable with git. Every tech domain has a ton of 'know how', in the above example, it takes 6 months to really be comfortable with the JNI java bridge for example. Good code review etiquette. Being able to compile massive code bases and overcome the invariable problem on the different platforms. Knowing how how to properly approach a bug fix, how much to test. etc. During this time, there's no way a 'young dev' can 'lead' a much more experienced dev. A young person could certainly 'lead a project' but they'll have to depend pretty heavily on the professionalism of the senior devs. FYI - if you're building basic CRUD apps on relatively established frameworks, and never need to go beyond that at all, a lot of this can be compressed. |
Cocksure senior engineers who think, “RFCs are easy, this’ll be quick” are the single biggest source of money-wasting errors that I have to navigate.
I’ve implemented huge distributed applications serving machine learning predictions in global scale ecommerce products, real-time image processing, eventually consistent and SOX compliant billing applications and dozens of other similar solutions in my time as an individual contributor.
Being a manager responsible for not wasting hundreds of person-years on the wrong architecture is way more challenging. It’s not even the same sport.