[cyanoacry]

When I was a little kid, I rented out Apollo 13 almost religiously. Kept watching it, admired the guys in mission control (and the astronauts too, of course).

A little later, in April, I sat in mission control and helped launch a spaceship to the ISS.

Along the way, I realized:

Engineering in the real world is maybe 30% calculations and typical "sciency" work, the other 70% is documentation and communicating to people. The day-to-day in the aerospace industry is way different than the way things are taught at school (from an EE perspective). It's impressive to me how much design happens in everyday back-and-forth conversations, versus the common image of "one guy, hard at work, cranking out equations at his desk".

Being smart isn't enough sometimes -- you need to have discipline as well, and even then, there is a considerable amount of luck in the mix. Getting the timing for a presentation, or a forcing a decision at the right time, can make a huge difference in the success of a program. You kind of have to check all three boxes to max out your success counter: smarts, determination, and luck.

[anotherevan]

> the other 70% is documentation and communicating to people

I still remember my profound sense of shock when I realised software development involved a great deal of communicating with other people and not just cutting code. Fortunately I got over it.

[jkchu]

Yeah, I was definitely surprised when I realized that too. And then when you think about it, almost any type of work involving a large number of people working at the same time should have the same dependency of documentation and communication. Being able to work well on a team is a skill that I feel often gets overlooked (or maybe it is just hard to judge in interviews).

[donw]

> Engineering in the real world is maybe 30% calculations and typical "sciency" work, the other 70% is documentation and communicating to people.

This is why I spend at least time coaching public speaking skills when building engineering teams, nominally in the context of giving tech talks within the team -- followed by specific, actionable, and kind feedback.

Presentation tools exist for good reasons, but are generally disliked because they are seldom used to convey information effectively.

But when you figure out your personal speaking style, and can stand in front of a room and keep them engaged during the course of a presentation... that's a game-changer.

[qwertyuiop924]

>Engineering in the real world is maybe 30% calculations and typical "sciency" work, the other 70% is documentation and communicating to people.

>Being smart isn't enough sometimes

Congratulations. You've learned two things that some people go their entire lives without understanding.

And I make no hyperbole. Erik Naggum didn't learn this, and he's far from the only one.

It's really something that we should put a greater effort into teaching...

[codeonfire]

cyanoacry just learned another viewpoint. If you work in a heavily political environment, a process heavy environment, or one in which the "calculations" are not appreciated, then yes, your viewpoint would be to put down the keyboard/slide rule and just communicate. In other environments, actual working results can silence people that are trying to "communicate" their way to success.

[qwertyuiop924]

True. But in some contexts, communication does matter. A lot.

Some would say that it never matters at all.