6 ms·
For most of my career I worked with a small group (20 to 30) group of highly educated and mostly brilliant people. I barely graduated high school. As the years
by TopHand 6y ago
For most of my career I worked with a small group (20 to 30) group of highly educated and mostly brilliant people. I barely graduated high school. As the years passed and we all began to age, I realized that the amount of knowledge we all had obtained during our tenure was an irreplaceable resource for the company. In order to help the younger incoming people bypass this learning curve I set up a wiki where group members could publish articles that they thought may help others not to have to re-invent the wheel. What I discovered was that most of these brilliant people would not share a lot of their knowledge. I often wondered if even these brilliant people suffered imposter syndrome and that they didn't share this knowledge for fear they would be found out.
What I did learn from the most brilliant members of the group was to never be afraid to ask a question, even if it sounded ignorant. Never be afraid to expose a gap in your knowledge. If you don't, your missing an opportunity to increase your learning.
- tomrod 6y agoImposter syndrome or job security? I've seen both.
- TopHand 6y agoI learned a long time ago that if you share your knowledge freely with your co-workers that only increases your job security. I postulate this plays off imposter syndrome. Your co-workers think to themselves, if this person is willing to share that knowledge, what are they holding back?
- tomrod 6y agoI learned the same, and follow such. I've also seen orgs where there is no version control because the culture encouraged people to consider themselves as sole sources of indispensable knowledge, irreplaceable. Those tended to be toxic places, but as such they show a counterexample where their specific job security was from not sharing their knowledge and experience.
- klenwell 6y agoI agree and have wholeheartedly embraced this idea as a manager. At the same time, I once had a manager who dinged me in an annual evaluation for asking too many questions and not knowing as much as I should about our applications as a senior developer. When I pointed out that I had written most of the documentation for those applications in our wiki, he replied, "That's not knowledge. Knowledge is what is in your head." The obvious lesson: avoid organizations like that.
- realbarack 6y agoI don't think this has much to do with imposter syndrome. A person who can scale their knowledge across an organization is simply a more valuable employee than an equally-skilled person whose knowledge is mostly not shared.
- ck425 6y agoI agree but I'd place more of it on the fact that people like people who help them. I've worked with a few engineers who have been incredibly helpful and gone out there way to share knowledge with me. I consider every single one of them to be a great person. If anyone ever mentioned them in a conversation I'd like say 'oh they're great, I love working with them' or some variation of. When it comes to office politics, like it or not, it exists and likeability is important.
- draw_down 6y agoPerhaps they found the task of turning their brains inside out unappealing for other reasons. Maybe it was just more work, for example. Maybe they didn’t need their “brilliance” to be validated. It’s also not really a straightforward thing to do, there are all sorts of questions around how best to structure info for the purposes of those it will be used by. All of this is a pretty big undertaking. The more I think about it the more I’m unsurprised people didn’t just hop to it.
- ecocentrik 6y agoFear of redundancy might be another reasons technical skills would not be readily shared by skilled employees. It's not something you typically see in startups but large corporations are full of people who actively protect themselves from perceived redundancy by obfuscating their skill set.
- draw_down 6y agoMaybe but incentives get to the point a lot faster and don’t require the silly pop-psychology angle that all this other stuff does. It likely just didn’t make sense for them in terms of incentive structure. Look up thread at the person who spent a lot of time training juniors, without much to show for it. That’s how this works in real life. Some guy going “hey I started a wiki so it’s easier now” doesn’t change anything about that. Imagine this same story when the person telling it is the boss of the other people.
- WrtCdEvrydy 6y ago> never be afraid to ask a question, even if it sounded ignorant On the mentoring side, never make fun of someone asking a legitimate question. I give my team shit if they should know better about something but legitimate questions are taken as seriously as possible.
- jstummbillig 6y agoIn fact, let's just not make fun of co-workers (in contrast to friends you work with) as a rule of thumb. We are too quick to legitimize all kind of questionable practices as soon as we start making that the prerequisite.
- ChrisMarshallNY 6y ago> should know better about something It's been my experience that this is quite subjective. For example, the standard leetcode binary tree tests. When I mention that I'm not particularly good at them, I will usually get some variant of "Well, this is basic stuff that any programmer should know." –often delivered quite condescendingly. But I've been writing ship code for over thirty years. I have a public portfolio with hundreds of thousands of lines of ultra-high-quality code, dozens of articles on software development practices, and multiple shipping apps for years (I write code every day –my GitHub ID Activity Log is solid green). It's just that I started as an EE, and have been primarily self-taught. Since I have never encountered a binary tree in my professional experience, learning them has not been a priority. I'm certainly not interested in spending time learning impractical (to me) stuff, at the expense of learning what I consider the important stuff. I'm also constantly trying out stuff I don't already know. It makes life interesting. I write about that here: https://medium.com/chrismarshallny/thats-not-what-ships-are-built-for-595f4ae2c284 https://medium.com/chrismarshallny/thats-not-what-ships-are-...
- sokoloff 6y agoI don’t care if someone can bang out working binary tree on a whiteboard with the fluidity of Bob Ross, but I do care that people know that data structure and associated algorithms exist and could implement them given a dev environment, google, stack overflow, and a day or so.
- formerly_proven 6y ago> I often wondered if even these brilliant people suffered imposter syndrome and that they didn't share this knowledge for fear they would be found out. I don't consider myself brilliant by any stretch of the imagination, but between self-doubts along the lines of "does anyone actually care about this?" or "people who really know this stuff might think I'm an idiot for stating things this obvious" and the time/effort required to actually make a good resource I've kept away from publishing almost anything. For employer-internal purposes I never had a problem writing docs and by all I've been told they weren't half bad, but the questions of who cares (or at least gets paid to pretend to care) and who needs it are much clearer, which also makes writing technial texts much easier.
- x87678r 6y agoI've seen a lot of people waste time on writing documents that just sit there unread. No one wants to RTFM, esp one written a few years ago that is likely not accurate.
- jklehm 6y agoI think there's value in docs from a level setting perspective...it's usually way quicker to talk someone through what's changed since the last update than from scratch.
- andrekandre 6y agodocumentation has to be actively maintained, but even old and innacurate documentation can serve as a starting point (and be update to be accurate) when something needs to be investigated/refactored etc without any documentation, all you have is word of mouth, and when people quit, the organizations knowledge DECREASES over time > people waste time on writing documents that just sit there unread. No one wants to RTFM documentation is hard... most documents that i have seen are mostly brain dumps, very badly formatted, just very hard to follow... one thing i think severely missing in school and otj training is how to write documents people WANT to read
- throwaway_pdp09 6y agoThe most valuable thing in software is knowledge. That comes either from experience (slow and painful, the jagged little pill), from other people (if you're lucky enough to have a local expert, I often don't) and from books/docs (easily available, if a little time-consuming to read). I go straight for the docs. They give the biggest ROI I can easily get my hands on. Really knowing your tools gives you a lot of power and it's a shame people don't seem willing to spend time on them.
- bsder 6y agoThen that's poor documentation. Documentation, like comments, is most useful when it answers "why" sometimes "how" but rarely "what". And "why" changes much more slowly. It's why I find API documentation to border on useless. I need examples and rationale, not variable names.
- yourapostasy 6y ago> What I discovered was that most of these brilliant people would not share a lot of their knowledge. Is that "would not" or "it isn't a priority"? In a consultant role, a lot of what I initially saw as my value was transferring as much knowledge as possible to my clients' staff. I prided myself on how much I was able to boostrap a team to self-sufficiency and how many years it was before I ever heard from them again. I was mostly wrong. For the vast majority of my clients' staff, my value lay in achieving some deliverable for them, and the value stream ended "dead right there". For technical concerns, it was way faster for clients' staff to treat me as a DSL Google for the particular problem space I was parachuted in to assist with, than for them to read the material I wrote for them. I did a long stint as a technical writer to put bread on the table while sharpening my coding/design skills in college, did a few user and developer guides for commercially released products that were well-received, so I am pretty sure the written material I leave with them is not lacking, as I re-use those skills weekly in my sales activities. It is an incentives and culture problem. People are heavily incentivized to short-term results, and long-term cognitive wealth is heavily discounted. It takes an active, conscious effort by an individual to work against that pressure and actually go beyond the process described in documentation if they get good procedures that not only explain what to do, but in a manner that doesn't interfere with streamlined procedure-following, the reasoning behind what they are doing so they are equipped with a model to handle edge cases that come up during operation of the procedure. In most average IT offices, there's probably 1 out of 10 who are like this to varying degrees, from the curious intern to the Free Electrons. They're a delight to work with and share with. The best part of sharing: I get to learn and push my own boundaries as I get to play with a new friend in the model space to discover new corners I missed earlier. I like feeling I'm the dumbest bloke in the room in a creative atmosphere when there is no pressure on to fix something quickly; that's when I learn the most, when my mind is on fire. I can see for someone like those on your team of brilliant mates, it can be hugely demoralizing over time to write and try to actively share, only to realize that only the rote part of it is ever used by the majority. That evolves over time into de-prioritizing that sharing to just the rote parts, and then as other teams ignore even that finding it easier to open incident tickets and loop them in, making only half-hearted attempts at sharing the rote parts.
- x87678r 6y ago> What I discovered was that most of these brilliant people would not share a lot of their knowledge I'm someone who has spent a lot of time training up juniors. TBH I dont have a lot of show for it. I really wish I spent my time trying to learn things myself, many of the people I've trained have much better careers than I do. I'm guessing your group of successful smart people are that way because they don't waste time trying to share their knowledge.
- the_af 6y agoI hear what you're saying. Though the feeling of helping someone else is wonderful (regardless of whether you later end up with "something to show for it", job wise). Don't you think that trying to teach someone something ends up helping you solidify your understanding, maybe even making you question what you took for granted?
- abellerose 6y agoYou're delusional if you believe that.
- the_af 6y agoIf I believe what? That explaining something helps me with my own understanding? Plenty of teachers and professors report the same feeling, so I'm not alone in this. If what you meant is that helping people understand something doesn't feel wonderful to you, then of course you're entitled to that opinion. One really can't argue with subjective feelings.
- aarpmcgee 6y agoEmpathic, not delusional. This person has a different set of values and I resonate with what they expressed.
- x87678r 6y agoYou are right, do you do learn when you have to teach something. Often though you're teaching how a internal system or codebase works, so you're learning/teaching stuff that isn't useful for you anywhere else.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- cosmodisk 6y agoTried my best left and right telling people I can help them to learn x,which would most likely double their income in a couple of years. Nobody was interested. I try my best to ask as many questions as I can even if I sound completely stupid. Had enough of these meetings where 8 people sit quietly for an hour and then silently admit they had no clue what was everyone talking about..
- agumonkey 6y agoReminds me of a tiny anecdote: in junior high, a new guy straight from africa asked to play tic tac toe with us, he never played. So we hustled him a little bit, and quickly he went into open curiosity mode, wanting to know all the rules. He went away for an hour and after beat us all mercilessly :) I'm very sad about how adult life chaos makes most people turn on stealth enemy mode, or stealth anxious mode.. it require us to become 'hungry' (not to say sharks) to ensure reaching our maximum efficiency.
- tonyarkles 6y agoOne of the things that I find really hard to do is to figure out where to start. I started programming when I was 8 years old, in BASIC, on a Vic-20. We were too poor to buy many games, but I discovered somehow that the public library had books that had game source code printed in the back. I learned how to type so that I could get free games quicker. Then I started understanding how the games actually worked and figured out how to change the code to cheat. Then... started making my own from scratch. A couple years later I got a C compiler (Mix C) that came with a fantastic reference manual. This was on the family’s shared XT, so I started optimizing my computer time by writing code on paper and then typing it in when it was my turn. I started figuring out how to debug on paper too, so as to further optimize my computer time. Then when I was around 12 we got a Pentium 1. Windows 95! This was really cool, but the C compilers for Win95 were either expensive or extremely hard to use (GDI in DJGPP? Yeesh). But I heard about this thing called Linux, and downloaded just enough Slackware packages to get going. From there, learned Perl, made money through high school doing web development, and started a CS/EE dual degree in 2002. Anyway, that’s the long prelude to the problem: employees that work for my clients often enough ask me “how can I get better at Linux and lower-level software development?” I have no frickin’ clue what to tell them. I know the path that worked for me, but that path started a decade before I took my first university course. There’s this huge deep well of experience that I didn’t learn for the sake of learning, but rather because somewhere along the way it solved a problem for me. Easy example: debugging something weird in giant source trees (eg the Linux kernel). “How did you figure that out?” “Well, I used find and grep to figure out all of the files that referenced that constant, and looked through each one of them to figure out which one we were actually calling.” “What do you mean when you say ‘find’? And what’s ‘grep’?” It’s like that joke about “to make an apple pie from scratch, you must first create the universe”. I have absolutely no clue how to figure out how much of a universe a reader might have, and I’m almost certain I’m going to be making a bunch of incorrect assumptions about “common background knowledge” that will just further bewilder the reader.
- dorkwood 6y agoI didn't feel like I had anything worth sharing until recently. Something I've discovered is that it's often the stuff we consider "basic knowledge" that is the most useful to others. I think that perhaps one of the reasons skilled people don't share basic things is because they don't think they have to. Once you get over that initial fear of being patronizing or talking down to people, you're able to really start communicating the things they most need to know.