|
|
|
|
|
by annie_muss
1257 days ago
|
|
I must admit, for most of my career I've been a "quiet bullshitter". I start with the best intentions but quickly get into situations that are far too difficult for me so I spend a lot of time covering up my problems with work for fear of being fired. ADHD plays a big part too. So I go to the meetings, I talk the talk at the job interviews and then fiddle with my computer getting nothing done all day. I've gone 6 months or more without shipping a line of production code. My code is generally quite bad and I don't know how to fix it, and now I'm in a more senior position it's too difficult to ask for help for extremely basic programming tasks. My advice: many "quiet bullshitters" want to do better, but lack the tools, support and ability to do so. They're not trying to take everyone for a ride, but they feel backed into a corner with no way out and they can't ask for help without great personal risk (either real or perceived). |
|
Things can get very difficult very quick if a company has most of their knowledge stored in people's heads, and the main mode of spreading knowledge is meetings.
Having little documentation is common Having a high meeting culture makes this work for a part of the company, for a while. But even the good listeners at some point aren't sure enough about their knowledge that they would write about it. Making the problem worse.
AD(H)Ders will not be able to process any of this knowledge, because it's all dependent on listening to people. At some point they'll feel ashamed that they are in the project for years now and can't contribute properly.
If you do want to stay in this company, this strategy can work to make your life better:
1) Document everything, for yourself. Since you're ashamed of your lack of knowledge write up in private what you do know, or think you know. Since you keep it private nobody will see if you have something wrong.
2) When you need to something, you can test if this knowledge actually works as you wrote it up, you can refine it.
3) Once refined you can contribute it back to the main knowledge base.
4) If you don't know something, and can't find where it's documented, ask people to show you where it's documented. If it's not it's not a bad thing for a senior engineer to ask where it is documented. This saves face, and improves documentation.
Also: always ask people to write you emails if they want anything from you. Verbal is worthless.