[jacobsenscott]

Deeply nested if/else logic, very long functions. Imperative logic that could be better written by higher level constructs like function composition, complicating code with micro-performance hacks, etc. In general inflexible code.

Of course not all of this is because I leaned C first. A lot of it was simply due to being a new programmer. But this kind of code is more prevalent in general in the C world. Just browse some opensource C projects.

I believe a lot of this stems from the "systems programming" mindset that goes along with learning C and C++. The requirements are very precise and well known, and don't change often. There is often a fairly precise "right answer" for how to do something where the "right answer" is some combination of performance metrics. Compilers are like that, file systems are like that, tcp/ip stacks are like that, etc. The programming boundaries tend to be very bright.

The "systems programming" mindset is a liability when writing business apps where a sales person can blow up every assumption and design decision and boundry in one day. The "right answer" is not clear, and not easily measured. The "right answer" has more to do with writing code that is flexible and easy to change. That is hard to measure and a totally different way of thinking.

[stcredzero]

But what you are citing here isn't a problem with learning C and C++. It's a failing of a generalist education. You might have known enough to avoid the gotchas of concurrency, but just out of school, you didn't know what you didn't know about business application development.