My experience, is that this is usually a defensive shell around personal insecurity.
On the outside, it looks the same, but internally, insecure people can be reached (not easy), whereas truly arrogant folks (a lot more rare than you might think) cannot.
My experience is that most difficult people are actually decent folks, that we can enjoy working with, but we need to adjust to them, and they need to adjust to us.
> The Kindle runs stripped down Linux with a React Native frontend along with Java backend applications.
Honest question: what exactly is wrong with this setup?
There's the OS, there are services and user land apps written in java and misc native code, and from the link there's a single component where Lua was used as bridge code.
The GUI is React Native, which is just a framework to simplify the design and implementation of native GUIs.
Well, I have found that finding things in common with people is usually a great segue into improving relationships. Learning more about them, also helps a lot. Find the things they care about. It can be surprising.
I have learned to make the first move, myself. It doesn’t work, if I insist on them doing it. Also, I need to accept their value system. If they truly have values that I can’t deal with, I usually “compartmentalize” things, so I don’t deal with them, in those areas.
I’ve spent my entire adult life, getting along with people that don’t play well with others. I haven’t always been able to get through, but I’ve had more success than failure.
> Also, I need to accept their value system. If they truly have values that I can’t deal with, I usually “compartmentalize” things, so I don’t deal with them, in those areas.
It feels like working with all sorts of people (and sometimes working around them) is an important skill that’s not usually focused on enough, which is how you get people that might be brilliant but also are really hard to work together with.
Not OP but: destigmatize admitting failure (by doing it yourself), normalize admitting ignorance and asking questions (by doing it yourself), find someone they look up to and demonstrate healthy collaboration dynamics with that person, explicitly labeling things which you value, as they happen (e.g. "thanks for saying you're not sure, or I would have thought that you were and it would have made me value the statement differently", "thank you for not taking the feedback on the code personally, the result is a better codebase for everyone"). And do the same with them whenever they imitate any of that, without dwelling on it any further or treating it any differently.
TL;DR: Normalize healthy dynamics by example.
Obviously just my 2c and every case is different etc.
- Share credit and be generous with sharing
- It is better to error in the direction of over sharing credit than under sharing (taking credit for yourself)
- Slow down, say "I don't know" (good to follow up with "but I'll find out")
- Saying "I don't know" is often a better answer than guessing
- Guesses are fine, but should be prefaced and be clear that you speculate BUT will follow up and verify
- Not knowing is the first step to knowing. You've turned an unknown unknown into a known unknown. That's a big step! And often one of the hardest!
- Encourage juniors to speak up and not be afraid of raising issues, even if those senior to them disagree.
- Either the junior provides valuable feedback that was missed (everyone is fallible) or it is a learning experience for the junior and //we invest in juniors//.
- Seniority does not make the dev, the logic/ideas/thinking does.
- Mentor more. I think we often want to send juniors to their corner so we can concentrate on our work, but you have to train those who will later on become your peers.
- There are no graybeards without noobs
- Encourage more collaboration
- Especially when there are complementary skill sets
- Drive culture that recognizes that ones ideas are not a reflection of their value. What I mean is that it is okay to be wrong. The idea is distinct from you, and you are more than just one idea
- We're all wrong, it is just a matter of "how" wrong
- Having a "bad idea" or "wrong solution" doesn't mean /you're/ wrong/bad.
- Recognize that we're all on the same team. Criticism is constructive
- A critique is not a dismissal, it is because we are all on the same team trying to make the best thing. An outside view is often helpful to finding issues. We work as a team, so criticism is debugging as a team, just as you criticize your own work when initially formulating ideas (you reject some ideas, find limits, and formulate plans. Criticism is the collaborative version).
- This means also be careful how you hand out criticism. Ensure it is always constructive. It always contains an explanation and a path forward (as much as possible).
- Competition can be beneficial, but it can easily create tribalism. Fight the natural tribalism because we're all on the same team (helps to have team mixing)
- Make time for learning
- The job always involves learning, no matter how senior you are. If there is only time for "doing" and no "learning" then you will only gain debt and you especially are teaching juniors the wrong lesson.
I would state that the first point can be a bit tricky. I've worked in some environments where one or two people follow the point and no one else does, so this ends up with those people being seen as "non-productive." This is more representative of poor management though and I'd push back against the toxicity to the extent possible.
For managers: the last point is really important. Your coders shouldn't always be sitting in front of their IDE or terminal typing code. They should be spending a fair amount of time reading docs, writing docs, and googling. Writing docs is actually important as it helps communicate ideas, which also serve as reports to YOU. This communication also helps de-abstract the ideas and often leads to finding issues. It is an important step to debugging. (It is often a good idea to have juniors build or append docs when they are onboarding. Dual serves as the intro to the codebase)
One of the best ways for me to learn, is to explain.
That's a very old pattern.
That's one of the reasons I write stuff that no one reads[0]. Writing up a technique forces me to research it, and break it down into its simplest components.
> One of the best ways for me to learn, is to explain.
Kinda The Feynman Method[0] or even Rubber Ducky Debugging[1]. I found that teaching in grad school has immensely helped. Not only do you have to solidify concepts to a much higher degree but you revisit stuff too. I think there is a big difference between the level of expertise needed to be comfortable working with some knowledge vs what is needed to teach that knowledge. The former is much more personal. But when learning any topic there's always things you had to table, that you didn't answer, because you had to make general progress. But if you don't revisit these, then they always remain unknown. Revisiting often brings new insights and thinking that you probably didn't expect. Any time I've revisited a topic, even ones I know quite well and have revisited many times, I often find that there's still more for me to learn. There's infinite depth, so always keep your eye out.
My experience, is that this is usually a defensive shell around personal insecurity.
On the outside, it looks the same, but internally, insecure people can be reached (not easy), whereas truly arrogant folks (a lot more rare than you might think) cannot.
My experience is that most difficult people are actually decent folks, that we can enjoy working with, but we need to adjust to them, and they need to adjust to us.