Comment by mlthoughts2018 | Hacker News Reader

Comment by mlthoughts2018 | Hacker News Reader

Parent Full thread

I think you have it very backwards. Coding leadership usually involves nearly zero coding itself. Rather it involves getting the other person to write down RFCs, tech specs, requirements, design diagrams, etc., and guiding them through how to think about macro structure of solutions and outcomes for specific product deliverables and business cases.

Training involves teaching specific tactics of coding, like a new technique of multi-processing, or an approach to refactor a legacy class implementation. Helping someone learn tactics is teaching or training, which is a different thing than leading.

A young person could lead an older, more experienced person. For example, they could drive them to outline a solution in architecture documents that better align with product management. That can be true even if there are no tactics of software design that the younger person can teach the more experienced person. So that doesn’t reduce credibility or anything in the leadership sense.

In general it’s important to separate these: mentorship, coaching, teaching / training, and leading. They are all very different things.

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.

After 15 years as an individual contributor and five as an engineering manager, I have to say, you are flat wrong. Doing the work of implementation is a dime a dozen. Getting quality RFCs and prior alignment on solution architectures is at least an order of magnitude more difficult, more valuable and more rare.

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.

IOW, the "leader" lets the top "coder" do all the work, including writing RFCs, tech specs, design and coding but takes all the credit.

This is an accurate description of leadership or architecture as it is practiced in this industry.

I've only seen leaders who are intellectual vampires.

Reply on news.ycombinator.com