None of these details are meant to be personally identifiable. And I don't represent them (obviously).
Also worth noting that anything negative, or positive, may have changed since I worked there.
- It is astonishingly easy to over-engineer and over-complicate a codebase by following OOP patterns (from the 90s to the early 2000s).
- Domain Driven Design seems to be a good idea on paper, but what happens is the code is organized strictly to follow an (arbitrary) taxonomy, without regard for what the data demands, and without even following the terminology that business follows (the actual point of DDD is to do this part, to communicate).
- Even a small team can make itself drown in process.
- A technical product requires a technical business person. The CEO not being willing to become aware of the technical details betrays a fundamental tenet of being successful with people under you: you need to be the top honcho, lest you get fooled.
- Stay out of office politics.
- When everything is remote, you need to over-communicate, a lot.
