I'm more of a wordcel than a shape rotator myself. It's not that I can't, it's more so that I get terribly bored when doing it. The last time I can remember being excited about it was in elementary school, where I was tested for spatial reasoning and put in some gifted mathematics class. Incidentally, my verbal skills were very poor at the time, I tended towards being very quiet and keeping to myself.
As I grew older and my verbal skills improved, I switched to the abstraction that comes with language. I also became more outgoing; I'm still an introvert but nowhere near what I was when I was a child. I suspect if you took a random Masaai hunter, they would do very well at these kinds of spatial reasoning tests.
Even in my career as a software engineer, I still tend to rubber duck a lot and really excelled at pair-programming. That's why I really enjoy using LLMs when programming now. When I transitioned to engineering management, I learned over the years to get out of the way of my directs who performed better alone; many times I wouldn't even meet with them for a month, and that made them extremely productive.
The issue with a lot of organizations is that they don't account for the variety in problem-solving techniques and abstractions that engineers use. Engineers are not some monolith that always need to be managed from the top-down; you should always play to their strengths and support a variety of problem-solving styles.
> many times I wouldn't even meet with them for a month, and that made them extremely productive.
That's an interesting idea. Since I feel like it's same for me. When I meet with people they have their ideas, suggestions and requirements that they put out and I feel like I have some sort of social obligation to meet them and eventually it might not fit very well into what I had planned and then I start to overthink related to how I can fit their ideas into what I was planning to do and it derails a lot. If I ignore the ideas I might need to justify it later or at some point, or argue immediately, but then so much energy will go towards justifying and debating, it will derail what I was to do anyway. It just I have this very strict big picture idea of what I'm planning to do in my head, and it feels impossible to share it with people without actually going through with it. Even if I wrote a massive document it wouldn't help I feel.
I've actually got feedback in my past that I should consider other's opinions more when doing something, but then it just breaks down everything I was to do, and I feel like I could execute really quickly.
I have trouble with group meetings as well, e.g. where people are going through tasks by splitting them down into subtasks, then discussing subtasks one by one, while I feel like I have a big picture thing, where I do not want to divide things into subtasks, since it's everything supposed to work together, and they can't be discussed individually. Although it's considered common best practice to divide and conquer, I feel like it's not how I best think. And I have idea for each subtask, but it's all coming from that "big picture" idea, and if I propose it I will have to start explaining the whole big picture I have in mind, and it would derail the whole thing, so I usually just let people discuss things out, because I can't explain the whole thing anyway. I can never be in sync with people in group meetings, so I'll just try to come up with things to pretend I'm being an active participant.
I'm obsessed with this big picture idea, and excited about executing it, but everything around it demotivates me and kills the excitement.
One thing to consider is that your code will be hard to maintain by others if you can’t at least communicate your big picture. And ideally, everything should be subdivided into modules with clearly defined interfaces, so that each module can be independently reasoned about based on (only) its interface definition. This increases maintainability because things can be reasoned about locally. People also differ in how much detailed context they can hold in their head at any given time, so the smaller the required context can be made for reasoning about any given piece of code or part of the design, the better.
Yeah, but I think my brain just doesn't work like that, I kind of have to work around that. I've never managed to change this with 10+ years. I do feel guilt around it all the time when working with others.
As I grew older and my verbal skills improved, I switched to the abstraction that comes with language. I also became more outgoing; I'm still an introvert but nowhere near what I was when I was a child. I suspect if you took a random Masaai hunter, they would do very well at these kinds of spatial reasoning tests.
Even in my career as a software engineer, I still tend to rubber duck a lot and really excelled at pair-programming. That's why I really enjoy using LLMs when programming now. When I transitioned to engineering management, I learned over the years to get out of the way of my directs who performed better alone; many times I wouldn't even meet with them for a month, and that made them extremely productive.
The issue with a lot of organizations is that they don't account for the variety in problem-solving techniques and abstractions that engineers use. Engineers are not some monolith that always need to be managed from the top-down; you should always play to their strengths and support a variety of problem-solving styles.