And what would that be exactly?

For me it's at least the following:

- Attention to detail

- Control of flow (if this then that) mentality

- More binary thinking

- Precision when describing (programming does not allow ambiguity)

- A lot of frustration tolerance :)

That's at least my experience

I would also add classification and focusing on edge cases.

+ focus on identifying and relieving bottlenecks

I am surprised you did not get that from mathematics, so I wonder what level/type of mathematics did you do?

I can get that you usually don't get it from regular high school mathematics, but even there one should learn to deal with proofs and deducing stuff in a precise, non-ambiguous way, and you have to pay attention to detail.

Coding allowed me to build things with my analytical mind liking precision and patterns, so it's the way for my "mathematical" brain to express creativity.

I did not mention that mathematics did not teach me that, but programming pushed that to a limit that maths didn't - probably because I do not spend 8h a day, every working day doing maths :)

> Precision when describing (programming does not allow ambiguity)

Really? Should we count how many bugs happen due to type conversion, precision errors, off by one etc?

Well, I try my best to avoid bugs and be as precise as I can. But hey, I'm only human ;)

You only reinforcing the point that programming does not allow ambiguity; thus: bugs.

No engineering discipline allows for “ambiguity” at least how you use it here, try building a train or a spacecraft with that level of ambiguity at that point the bugs tend to make things go boom.

> - Precision when describing (programming does not allow ambiguity)

Probabilistic programming and machine learning do!

The existence of your reply is a case in point that programming teaches "Precision when describing".

Also iteration.

And recursion :)

+ Learning confirmation and other biases

I'd argue that it forces you to think clearly about problems. You cannot write a program unless you understand exactly what you want it to do. In contrast typical CEO excels at creating tons of meaningless fluff. Perhaps mathematics or philosophy may have similar effects on people's ways of thinking?

This is not a reply to you personally well not just but to everyone else...

A) I think you greatly underestimate what other engineering disciplines bestow not to mention require

B) Really? Have you seen modern software development practices? barely functioning MVPs, vertical slices, pivoting and hacks galore....

Like personally I would wager that most programmers do not understand exactly what they are building when they start, I know I don’t always and I never really met anyone who does so either at least not constantly. You know the general direction then you tend to hack things until they work and optimize and fix edge cases as needed.

We very much can write programs without understanding what we need to do or even how things work otherwise we wouldn’t have bugs that are not hardware errata and even then one can argue that if you truly know what you are doing you plan for hardware failure.

> A) I think you greatly underestimate what other engineering disciplines bestow not to mention require

What makes you think I underestimate those other disciplines? I do not. The other disciplines tend to focus on tangible rather than on abstraction. Programming (if you want to actually be good at it) requires you to tackle abstractions all day long. My theory is that that ability translates (in some people!) to being better CEO.

> B) Really? Have you seen modern software development practices? barely functioning MVPs, vertical slices, pivoting and hacks galore....

You are mixing stuff here. I can guarantee you that if you know what you want to build and have the clarity to make the right choices, the hacky project will turn out better than if you don't. Specific development practices (e.g. hacks vs. no hacks) has no relation to personal ability to formulate clear problem statement.

Nothing here is exclusive to programming, in fact this isn’t exclusive to engineering even.

Formulating a clear problem statement is applicable to essentially every field and I would argue is probably the hardest thing to master and what most people fail at.

At least personally the most improvement I have experienced in formulating a problem statement had nothing to do with actual technical work but rather when I worked in professional services and had to come up with new service offerings, writing up proposals and managing stakeholders.

Formulating a problem is definitely a soft skill that I would say most purely technical programs don’t teach that well, quite often because you are given the problem statement to solve. This is also true for technical work and why some people might find it hard to progress in their careers. I’ve met plenty of brilliant and highly experienced engineers that suffer from major tunnel vision and couldn’t see the forest for the trees.

Electrical Engineering is full of abstraction.

To iterate different embodiments of ideas with people until something gets traction. I do think that is actually something the arts teachers, but I've done none of the arts so no personal experience to compare.