[rowanG077]

You are implying that if you can communicate but have nothing backing it up that's worth 95%? If anything code can still be taken as is and understood by someone else. So to me it's always most important to be able to produce anything before being able to communicate.

[bayindirh]

In a sense, yes. I'm contributing to a small but crucial part of a big project, as a coordinator of a four person team. The dynamics of the project form the team as "band of equals", in other words, everybody has approximately the same capabilities, and roles are divided organically, and I ended up as the "project manager" for that group somehow.

Even before we started coding, there was an RFC written by us. We have talked about it, discussed it, ironed it out with the chief architects of the project. When everything made sense we started implementing it. Total coding hours is irrelevant, but it's small when compared all the planning and it's almost finished now.

The code needs to tap and fit into a specific place in the pipeline. Finding and communicating this place was crucial. The code is not. Because you can write the most sophisticated code in the most elegant way, but if you don't design and implement it to fit to the correct place, that code is toast, and the effort is a waste.

So yes, code might be the most enjoyable (and sometimes voluminous) part, but it's 5% of the job, by weight, at most.

[sophacles]

Once your proof of concept gains traction more time is spent in meetings with other teams responsible for the systems you'll be interacting with - making sure you do it "right" rather than scrappy. Once your initial release starts getting popular you spend more time looking at metrics and talking to operations folks to make scaling easier and not waste resources. Once your product starts having customers who depend on it, you spend a lot of time working with product to figure out features that make sense, advise on time estimates, mentor new team members, and advise teams who use your product/services as a dependency.

These are all engineering tasks, and the longer you spend on a team/in a company, the more likely it is you provide more value by doing this than by slinging code. You become a repository of institutional knowledge to dispense.

[coldtea]

>You are implying that if you can communicate but have nothing backing it up that's worth 95%?

If you can communicate it can be 99% of the value. Getting someone to write something to back it up is trivial in comparison.

[rowanG077]

    "Talk is cheap. Show me the code."
    - Linus Torvalds

[hnaccount_rng]

Think about it the other way around: How much code is written and never used? How much code is written and would be better if it were never used? How much code is used only to then notice, that it doesn't solve the business problem that it was intended to solve? How much code is run and it's never noticed that it doesn't solve any business problem?

All the while: You are correct, being able to produce anything that solves a problem is much more valuable than being able to talk about it. But in order to unlock the value (beyond solving your own problem) absolutely requires communication

[seba_dos1]

It's more like writing the code is just the first step on a long road. You won't go anywhere at all if you don't take it, but if that's the only thing you do, all you did is the first step.

I have written plenty of code that's stuck on this first step in my life, including some that went to the very same LKML we're talking about here right now. Some of those things have already been independently written again by other people who actually managed to go further than that.