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.
I'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.
documentation 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
The 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.
I 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.
> 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.
I 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?
You 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.
If 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.
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 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.
That's the thing. 99% of programming is Big Data (and windows, thereof), so everyone is on about that.
I tend to write stuff that is on a much more humble scale, like device control software, or systems that are used by thousands (not millions) of people.
I guess that I could say that "Any programmer should know about ring buffers," as that was a staple of my device driver stuff (I came up through hardware). In point of fact, only low-level drivers need concern themselves with ring buffers. Even programmers dedicated to writing device control software don't have to mess with them. The same with hardware handshakes, IRQs, etc.
We tend to view everything through the lens of what we know.
> In point of fact, only low-level drivers need concern themselves with ring buffers.
As a side point, ring buffers are also useful in some high-level, high-performance code that is multi-threaded or using multi-processors.
io_uring is an example of this used to speed up Linux kernel-userspace communication (although it's not a great example for illustrating the general principle because it's so specialised).
DSPs use ring buffers extensively. Mainly for signal data, but sometimes for communicating tasks and messages between coprocessors.
Heck, I’m using ring buffers in some high performance image processing stuff right now. There’s non-constant-time processing in the pipeline, and dropping frames is acceptable if we hit some kind of pathological case where the image processing stuff can’t keep up. Pseudo-real-time is more important than processing every frame, but processing as many frames as possible is still desirable. By adjusting the size of the ring buffer relative to the input rate, we can put a bound on the maximum age of a buffered frame (camera runs at a fixed fast rate) while guaranteeing we’ll never exceed N*frame size memory usage.
I agree that programmers should know about (the existence of the concept of) ring buffers, hardware handshakes, interrupts, synchronous vs asynchronous and serial vs parallel data communications, error detection/correction systems, grey codes, Karnaugh maps and logic glitching, split clock domains, etc.
If you tell me “I don’t want to know about anything that I don’t need clearly and presently to accomplish my next task”, you’ve told me something important.
The parent is not wrong, coming up on two decades in this industry(and much more to keeping before that), the number of times I've encountered a binary tree is near zero. Only thing close was BSP trees in some engines we've licensed. There are parts of CS that get heavily over emphasised and parts that are neglected but super important.
It's also been my experience that the hardware things you mention are not well understood by most developers(it's a level of abstraction that honestly they don't need to worry about unless you want the last bit of performance from a piece of hardware).
Never, for me, but I am sure that's because of the type of programming that I have done.
There's a chance that it may have been used in some of the convolution filters we developed, but I was no longer coding pipeline stuff (manager), by the time we got there.
> If you tell me “I don’t want to know about anything that I don’t need clearly and presently to accomplish my next task”, you’ve told me something important.
Oh, wow. I'm busted. I guess I should just sell my computer and take up turd farming.
Except...
> "I'm also constantly trying out stuff I don't already know."
That might indicate that "clearly and presently to accomplish my next task" keeps changing.
In 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.
> I give my team shit if they should know better about something but legitimate questions are taken as seriously as possible.
The thing is everyone has gaps in their knowledge and is missing stuff "they should know" or perhaps have forgotten about. Getting "shit" for asking a question will lead to team members clamming up and pretending they're on top of something when instead they need a hand and some review.
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.
> 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.
I 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?
I 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.
I 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.
I 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.
I 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.
I 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.
One 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.
Tried 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..
> 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.
Perhaps 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.
Fear 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.
What politicians know that the authors of this study don't seem to realize, is that if we are told the same story repeatedly for long enough, no matter how absurd, we'll start believing it. If you throw in some scary outcome if we don't believe the story, we'll come around sooner. It seems that fear will cause us to re-examine our beliefs and values.
I agree with you a 100%. Your bike should help you maintain good riding posture even when you are becoming road tired. Just be careful about who you pay to fit the bike. Most shops claim to be experts, but I have had bad experiences with some shops. It doesn't show until you've ridden a great many miles.
Read as much as you can from Robert A. Pease. He was the guru to contact when it came to analog design. The column he wrote for Electronic Design can still be accessed on line. If your luck you can find one of his books used. Look him up on Amazon.
Tacit knowledge is what I've always thought of as "intuitive feel". As you grow in experience in a field, you start getting this feel for what will work and what won't work. This can be a great advantage, or a great disavantage. I had occasion to work with a fairly bright scientist. He said the reason that most great discoveries were made by relatively young people is because they hadn't developed these prejudices yet, so were unaware that it wasn't suppose to work this way.
My best suggestion is to develop another skill that could be distantly related to the skill you already have. In my case, before I retired I was good, not great at circuit design and was good, not great at developing firmware in C. With those two skills, I did not go unemployed. As far as boredom goes, most professions/vocations have long periods of boredom. I once asked a helicopter pilot if he ever got bored. His reply was that flying helicopters entailed long hours of complete boredom interspersed with moments of shear terror.
I suggest you look for more than just arthritis related information. The amount of mechanical wear it causes is significant over time.
That is not to say it doesn't have benefits but to suggest the entire population can haul their arse on a bike doing a 20mi round trip every day for 40 years and be hopping along nicely is a dream.
Not to mention the incidental injuries of which my colleagues suffer from, and myself going back a few years (hospital wasn't much fun)
No, come on, provide something concrete. Searching for "cycling joint wear" just provides unreliable sources saying you don't use your joints up, but it doesn't provide unreliable (or reliable) sources saying the opposite.
It is easy to avoid incidental injuries, and everyone would much rather the trauma of an incidental cycling accident than the trauma of a highspeed car crash. Mentioning them in just scaremongering. Ride at a safe speed on a proper path and look where your going. If you can't look where you're going, you're going too fast; slow down. (You can't say "proper paths don't exist", because we're talking about the dreamland in which they do, therefore, by definition, they do.)
20 mi round trips are unlikely. You get long trips in cities developed for cars.
This is 20th century nonsense that has been debunked. Your body is not a battery that you use up, use means regeneration. Not using your joints for strength production is more harmful than biking everywhere.
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.