I have seen this situation weaponized in many corporate environments, not only by engineers, but also by business and legal people: "Oh, you don't know about X?" to shut down a contrarian opinion. Rather than explaining X, it is used to socially shame the other (typically honest and sincere) person into silence.
As a senior developer one of the most important things you can do, once you have credibility, is to say out loud when you don't understand something. This allows more junior engineers to admit this as well, and helps control system complexity in the face of a conspiracy of the imposter syndrome.
> As a senior developer one of the most important things you can do, once you have credibility, is to say out loud when you don't understand something.
Yeah. Sometimes when I say I don't know or don't understand, I'm talking for others, not just for myself. But I have the standing or the self-confidence (or both) to admit that I don't know something without feeling bad about myself.
For me it is approachability and not intimidating by how much coding you do outside of work. I felt like was gonna be fired every day cause my lead would do some crazy shit on his free time with JS, css, and math. I think maybe coding stuff should only be shown off if it's relevant to what's going on or for help. You can tell me all day you don't know something, but when you shows off advanced mathematic calculations using raw JavaScript to draw dynamic maps for a game you made as a "side project," I'm always gonna think you take your job too seriously.
The best lead codes because they're paid. They don't care about the hardcore "best practices" stuff because it really does not matter. Understanding how to do the job does.
I think it is way too long for presenting a simple concept of gate keeping.
What is adding to the damage is coming up with portmanteau "Poelitism" which makes me think that author tries to be forcibly clever.
Check out this:
Poelitism is when you believe everyone had the same path of experience you had when learning the same area of expertise.
Compare with:
Gate keeping is when you believe everyone had the same path of experience you had when learning the same area of expertise.
Well those kind of sentences, as cited below, are off-putting as it also seems like author is trying to be clever, while making x, y, z as broad statements it just makes it unclear. Would be a lot better if he would present specific example.
However, even if it's ultimately true that you have to learn "z" instead of "x", that's not a helpful statement. You can't distinguish if it's right or wrong from the merits of the argument alone.
I claim the opposite. I believe that people who "make most senior devs of FANGAM feel clueless about programming and engineering" absolutely are able to quickly install tools like Node.js because they most likely have done something similar with another development environment already and know that looking into the docs/README is the quickest way to success.
I welcome this introspection but its interesting to place this line of thinking on other fields ; Medicine (doctors), Law (lawyers), Science and even Mathematics.
What part of "Poelitism is when you believe everyone had the same path of experience you had when learning the same area of expertise" applies to those fields as well?
He does mention in the article that programming is different from some other fields in that it is not regulated: "Unlike other fields such as medicine and civil engineering, in most countries, software programming is not regulated." Medicin and Law definitely fall under the "regulated" category. I can definitely apply his point to science and math because just because you know one area of study very deeply, doen't mean you know much if anything about other areas under the same field.
EDIT: Just to add on the regulated point--it can mean that the varying paths to knowledge are narrower with less variation. You're not a lawyer unless you go through a pre-approved 3 year curriculum, and pass a standardized test (bar). This limits he "why didn't you know about this" complaints because most lawyers have had a very similar path to knowledge.
1. System configuration has always been the bottleneck to learning programming, so much so that the first sentence of paulg's learn to program guide is this:
Find a friend who knows how to program. Get them to set you up with a system where you can edit and run programs
http://www.paulgraham.com/pfaq.html
2. Javascript has been good to me, but NodeJS, webpack and the community around it has been particularly bad for this. The move by maintainers towards lower configuration, more opinionated tools is a good step in the right direction, but many people who are general experts in web standards have been shut out of the web's main programming language over the last 5 years or so.
As frontend development has gone towards the "developer fontend", meaning complex technologies that focus on complex state management tasks with complicated configuring workflows, there has been a large number of people with layout, css and design skills that have been pushed out of implementation roles.
Many companies increasingly have workforces that split cross browser compliance and javascript implementation roles - the skill level required for frontend tools like react/redux creates a large barrier for upskilling devs.
ok, got it. I wonder if "skill level" is even the right word: it is a huge time sink to learn it, but afterwards are you actually more "skilled"? I've had to interact with React experts who had no idea how to generalize their understanding to other problems, or understood that React was solving problems that other (non-web) systems have been solving for decades.
Framework devs getting sorted into "high skill" without knowing core web skills is definitely the other side of the problem. By high skill I meant more of a steep learning curve - there isn't much a developer without a significant understanding of the framework can do.
I often say that the hardest program I ever write is "Hello, world".
Once the program is running, I can modify it to make it do whatever I want. I now understand its rules and am in the domain of ordinary programming.
But if a program doesn't even run, the set of things that is wrong is vast. And it's hard to Google, because the symptoms are usually something akin to "nothing happens". I can mess with things all day, many of which will make nothing happen differently.
Installing prerequisites is very obviously one of the worst bits of doing any software development. We've spent decades re-inventing various packaging and containerizing tools to try and make it easier because everyone hates it so much.
It also has almost nothing to do with the actual business of writing a program.
True in Slackware's heyday (and still true of Slackware itself).
Ubuntu does not come with compilers preinstalled, and I believe the same is true of Fedora. Debian might, but it always was a technical distro. The popular ones tend to leave out development tools for the sake of not confusing the mythical Average User.
It's a bit more specific but the Godot game engine is like this and it's a wonderful first time experience.
You download a single binary and end up with the scene graph editor, a gdscript editor, and all the other bells and whistles you need to immediately start.
Another example is "if you haven't memorized the entire documentation, you're too incompetent to use this software".
I don't think it works that way nowadays, especially when software X has dependencies Y and Z, so you'd better cram their documentations as well.
The other day I was reading this little rant about Gitlab and how painful it is to update. According to the snarky responses, it's possible to update it if you've RTFM. Which is true! But it reveals this belief that doing a lot of unnecessary work and retaining a lot of noisy facts somehow makes you a better person.
This post really resonates with me. When I was in high school I was interested in taking a computer science class. So I asked a guy who knew how to program what he thought. He said if I didn't already know how to program I was probably too old because you have to learn a language when you're young. He said I would probably do poorly in the class, get a bad grade, and that would affect my ability to get into a good college. I listened to his advice and didn't take computer science in high school. After all, he knew about programming and I didn't!
A few years later I realized that his "advice" was a really prevalent attitude of knowledge gate keeping in computer science. After all, if you dunk on all the people trying to learn and convince them they're not good enough every time they encounter some minor road block, you get to keep your special status as smarter than and better than.
I thought this behavior was just "high school immaturity" but apparently many people never get over their insecurities because I encounter people well into their 50s still doing it.
"He said if I didn't already know how to program I was probably too old because you have to learn a language when you're young"
Good, now there's more older and experienced people for me to hire in the companies I work. It's amazing how my view is the complete opposite, and I'm just 31 years old.
High school is too old to learn computer science? I don't follow your logic of why it would be a good thing to convince high school kids that they shouldn't learn computer science.
This is why I miss the boot to BASIC days: you could go from zero to programming in no time flat. Someone who'd never touched a computer could be programming in seconds. Their first program may be copied out of a book, and their first original program may be bad. But they'd be programmers right out of the starting gate.
There were boot-to-BASIC systems that ran entire businesses, and I'm not just talking the odd random auto shop that did inventory with a C64 or Apple II. It's little spoken of today, but once upon a time MAI Basic Four was A Big Deal in the industry. Their operating system, BOSS, could support eight users concurrently and even had support for "ghost tasks" (their word for daemons) -- on a 64k minicomputer system. All user programs in BOSS were written in BASIC, and BASIC was the primary command interface.
I've tried to help programmers from that era upskill into more "modern" frameworks and the first pain point they have is installing the framework. I don't know if the industry is aware what a giant monstrous time sink and source of misery installing and configuring your fucking toolkit, just so you can get started, truly is, especially for new programmers to a particular framework (let alone neophytes in general). But I think the author is onto something if "poelitism" (god I hate that term, it sounds like an In Living Color sketch, just call it being a smug weenie instead of thinking you can contribute to the OED) blinds us to that fact.
This article is toxic and divisive. People interested in delivering engineering outcomes are interested in the outcome not their role in it.
If you don't know enough about the toolchain to contribute meaningfully. Stop and learn about your toolchain. If you can contribute then contribute. If your contributions are rejected then try to understand why. There is probably a good reason.
If you think you can do it better then put your reputation on the line. Pick a fence, call your shot, and make a go of it. If you are delivering better outcomes I promise the vultures will come to you. If you come up short find something shiny and point your finger there.
I would love to be away from people who believe "If you don't know X then you're not good for programming", so if it's divisive in that way then that's the post intention and I'm happy with it. Toxicity would be the programmers who believe in that statement, so I'm dividing myself from toxicity.
Uneven distribution of skills and knowledge is a wrinkle that everybody has to grapple with in their careers.
I think what the post is describing is programmers who have a fairly narrow vision in which their particular talents and knowledge take on disproportionate value. I think these programmers tend to be the happiest workers, and they tend to develop themselves to the fullest, because they are fueled by their outsized belief in the value of their particular skills. This can bring a great positive energy, but the downside is that they tend to turn into hero programmers and create codebases that are impossible for others to work effectively in, and they can sabotage the confidence of people around them. If they are so inclined, they can be very effective bullies, but even if they are nice people, if they really believe in the vital necessity of an ability they have that others don't, they won't appreciate the value of others' work. For example, being a prodigy at writing fast, low-level code is a good thing, but if you develop a blanket belief in the importance of code being extremely fast at a low level, you will mistrust and devalue code written by other members of your team. The more important the project, the more you'll feel that you need to write the important parts yourself. Your teammates will notice, in subtle or unsubtle ways, that you don't believe their code is good enough. You'll also fill the codebase with code that only you can properly maintain.
Probably the most dangerous strength for this kind of programmer to embrace is their ability to handle a high degree of complexity. In almost any software engineering context, this will result in the generation of unnecessary complexity that one team member thrives in and other team members drown in. The opportunities to "improve" a codebase at the cost of a little additional complexity are infinite. Other team members' work will have far fewer of these improvements, and this will be painted in a negative light. When people argue against marginal improvements on the basis of added complexity, the hero programmer might feel that they are simply inferior programmers trying to devalue their talent out of jealousy.
In short, working at the absolute limit of your greatest strength and foregrounding that in the work of your team is extremely fulfilling, but a great way to sabotage your team.
At the opposite end of the spectrum are people who are too quick to write off their strengths as an unimportant part of a big whole. They are less happy, and more likely to plateau or even fall off in performance over their career, as their awareness broadens and their own self-assessment shrinks in proportion. When they come into an environment that is shaped by the talents of others, they might feel paralyzed and valueless, instead of believing that the team can and should change to take advantage of their skills as well. These programmers will chronically disappear and underperform.
I think the ideal is not a happy medium between these extremes but rather a change in approach. Instead of foregrounding your strength in the work of the team, can you background it? If you're a performance expert, can you design an application so that others working on it only need to follow a few simple rules to maintain the high performance? Can you make it trivial for other programmers to check the performance impact of their code changes? Can you instrument the application so that performance issues can be quickly identified and diagnosed? Can you turn performance into something that other team members barely have to think about?
This requires you to value other people not knowing what you know about performance, to see that as a cost savings. Instead of thinking, "My knowledge is valuable because I am the only person my team can trust to hack on this system without introducing performance regressions," switch it to, "My knowledge is valuable because I enable my team to confid...
This is at the bottom for the simple reason people cannot do this effectively.
Getting over mental blocks like these may require decades of maturity, if ever achieved at all. Getting to care about others, is rarely part of anyone's developer bubble.
With programming, there's a certain kind of objectivity that disregards what you think or what people say. If you think the program should work, but there's some bug, your misunderstanding becomes significant. Whereas, an incomplete or incorrect understanding doesn't matter if the program behaves well.
You can get away with not-knowing a lot and still achieve results.
But at the same time.. debugging will often be slower if you're not experienced with the domain. Maybe you'll be able to figure it out in a top-down manner.
In terms of gate-keeping? People shouldn't go out of their way to discourage others. Conversely, it's better to be curious, and optimistic about being able to solve problems you encounter when programming.
I don't agree with elitism, but I also don't agree with this idea that you can leverage strong fundamentals and be an expert in an unfamiliar language. Specifically this part :
>However, once they learn how the tools work, they can use their knowledge of fundamentals and their deep experience in related topics to revolutionize the whole development process using those technologies. It can even make the creators of those mainstream tools feel stupid for many of the decisions they made. Sometimes, the tools are getting in the way of producing better outcomes.
In addition, I would focus on this idea that the language, tooling & methodology are largely a means to an end. I think people waste way too much time thinking and discussing tools and languages. Just pick a lane and stick with it. Some programmers I know avoid using mature tech stacks (e.g. C#, Java) in their non-work projects because they feel they're outdated and so they latch on to newer and newer libraries to "remain current" but they never write anything of value that is beyond a couple of weeks worth of code. Just pick a lane and stick with it - go be an expert, the world has enough amateurs.
36 comments
[ 3.3 ms ] story [ 96.8 ms ] threadI have seen this situation weaponized in many corporate environments, not only by engineers, but also by business and legal people: "Oh, you don't know about X?" to shut down a contrarian opinion. Rather than explaining X, it is used to socially shame the other (typically honest and sincere) person into silence.
As a senior developer one of the most important things you can do, once you have credibility, is to say out loud when you don't understand something. This allows more junior engineers to admit this as well, and helps control system complexity in the face of a conspiracy of the imposter syndrome.
At that point, we can mature from knowledge acquisition to knowledge transmission.
Yeah. Sometimes when I say I don't know or don't understand, I'm talking for others, not just for myself. But I have the standing or the self-confidence (or both) to admit that I don't know something without feeling bad about myself.
The best lead codes because they're paid. They don't care about the hardcore "best practices" stuff because it really does not matter. Understanding how to do the job does.
I think it is way too long for presenting a simple concept of gate keeping.
What is adding to the damage is coming up with portmanteau "Poelitism" which makes me think that author tries to be forcibly clever.
Check out this:
Poelitism is when you believe everyone had the same path of experience you had when learning the same area of expertise.
Compare with:
Gate keeping is when you believe everyone had the same path of experience you had when learning the same area of expertise.
Well those kind of sentences, as cited below, are off-putting as it also seems like author is trying to be clever, while making x, y, z as broad statements it just makes it unclear. Would be a lot better if he would present specific example.
However, even if it's ultimately true that you have to learn "z" instead of "x", that's not a helpful statement. You can't distinguish if it's right or wrong from the merits of the argument alone.
Doesn't help that node really is a shitshow.
What part of "Poelitism is when you believe everyone had the same path of experience you had when learning the same area of expertise" applies to those fields as well?
EDIT: Just to add on the regulated point--it can mean that the varying paths to knowledge are narrower with less variation. You're not a lawyer unless you go through a pre-approved 3 year curriculum, and pass a standardized test (bar). This limits he "why didn't you know about this" complaints because most lawyers have had a very similar path to knowledge.
Many companies increasingly have workforces that split cross browser compliance and javascript implementation roles - the skill level required for frontend tools like react/redux creates a large barrier for upskilling devs.
Once the program is running, I can modify it to make it do whatever I want. I now understand its rules and am in the domain of ordinary programming.
But if a program doesn't even run, the set of things that is wrong is vast. And it's hard to Google, because the symptoms are usually something akin to "nothing happens". I can mess with things all day, many of which will make nothing happen differently.
It also has almost nothing to do with the actual business of writing a program.
Trying to jump from there to doing anything with C++ in the days of mingw and Bloodshed DevC++ and Win32 was... not pleasant.
Ubuntu does not come with compilers preinstalled, and I believe the same is true of Fedora. Debian might, but it always was a technical distro. The popular ones tend to leave out development tools for the sake of not confusing the mythical Average User.
You download a single binary and end up with the scene graph editor, a gdscript editor, and all the other bells and whistles you need to immediately start.
I don't think it works that way nowadays, especially when software X has dependencies Y and Z, so you'd better cram their documentations as well.
The other day I was reading this little rant about Gitlab and how painful it is to update. According to the snarky responses, it's possible to update it if you've RTFM. Which is true! But it reveals this belief that doing a lot of unnecessary work and retaining a lot of noisy facts somehow makes you a better person.
A few years later I realized that his "advice" was a really prevalent attitude of knowledge gate keeping in computer science. After all, if you dunk on all the people trying to learn and convince them they're not good enough every time they encounter some minor road block, you get to keep your special status as smarter than and better than.
I thought this behavior was just "high school immaturity" but apparently many people never get over their insecurities because I encounter people well into their 50s still doing it.
Good, now there's more older and experienced people for me to hire in the companies I work. It's amazing how my view is the complete opposite, and I'm just 31 years old.
There were boot-to-BASIC systems that ran entire businesses, and I'm not just talking the odd random auto shop that did inventory with a C64 or Apple II. It's little spoken of today, but once upon a time MAI Basic Four was A Big Deal in the industry. Their operating system, BOSS, could support eight users concurrently and even had support for "ghost tasks" (their word for daemons) -- on a 64k minicomputer system. All user programs in BOSS were written in BASIC, and BASIC was the primary command interface.
I've tried to help programmers from that era upskill into more "modern" frameworks and the first pain point they have is installing the framework. I don't know if the industry is aware what a giant monstrous time sink and source of misery installing and configuring your fucking toolkit, just so you can get started, truly is, especially for new programmers to a particular framework (let alone neophytes in general). But I think the author is onto something if "poelitism" (god I hate that term, it sounds like an In Living Color sketch, just call it being a smug weenie instead of thinking you can contribute to the OED) blinds us to that fact.
If you don't know enough about the toolchain to contribute meaningfully. Stop and learn about your toolchain. If you can contribute then contribute. If your contributions are rejected then try to understand why. There is probably a good reason.
If you think you can do it better then put your reputation on the line. Pick a fence, call your shot, and make a go of it. If you are delivering better outcomes I promise the vultures will come to you. If you come up short find something shiny and point your finger there.
I think what the post is describing is programmers who have a fairly narrow vision in which their particular talents and knowledge take on disproportionate value. I think these programmers tend to be the happiest workers, and they tend to develop themselves to the fullest, because they are fueled by their outsized belief in the value of their particular skills. This can bring a great positive energy, but the downside is that they tend to turn into hero programmers and create codebases that are impossible for others to work effectively in, and they can sabotage the confidence of people around them. If they are so inclined, they can be very effective bullies, but even if they are nice people, if they really believe in the vital necessity of an ability they have that others don't, they won't appreciate the value of others' work. For example, being a prodigy at writing fast, low-level code is a good thing, but if you develop a blanket belief in the importance of code being extremely fast at a low level, you will mistrust and devalue code written by other members of your team. The more important the project, the more you'll feel that you need to write the important parts yourself. Your teammates will notice, in subtle or unsubtle ways, that you don't believe their code is good enough. You'll also fill the codebase with code that only you can properly maintain.
Probably the most dangerous strength for this kind of programmer to embrace is their ability to handle a high degree of complexity. In almost any software engineering context, this will result in the generation of unnecessary complexity that one team member thrives in and other team members drown in. The opportunities to "improve" a codebase at the cost of a little additional complexity are infinite. Other team members' work will have far fewer of these improvements, and this will be painted in a negative light. When people argue against marginal improvements on the basis of added complexity, the hero programmer might feel that they are simply inferior programmers trying to devalue their talent out of jealousy.
In short, working at the absolute limit of your greatest strength and foregrounding that in the work of your team is extremely fulfilling, but a great way to sabotage your team.
At the opposite end of the spectrum are people who are too quick to write off their strengths as an unimportant part of a big whole. They are less happy, and more likely to plateau or even fall off in performance over their career, as their awareness broadens and their own self-assessment shrinks in proportion. When they come into an environment that is shaped by the talents of others, they might feel paralyzed and valueless, instead of believing that the team can and should change to take advantage of their skills as well. These programmers will chronically disappear and underperform.
I think the ideal is not a happy medium between these extremes but rather a change in approach. Instead of foregrounding your strength in the work of the team, can you background it? If you're a performance expert, can you design an application so that others working on it only need to follow a few simple rules to maintain the high performance? Can you make it trivial for other programmers to check the performance impact of their code changes? Can you instrument the application so that performance issues can be quickly identified and diagnosed? Can you turn performance into something that other team members barely have to think about?
This requires you to value other people not knowing what you know about performance, to see that as a cost savings. Instead of thinking, "My knowledge is valuable because I am the only person my team can trust to hack on this system without introducing performance regressions," switch it to, "My knowledge is valuable because I enable my team to confid...
Getting over mental blocks like these may require decades of maturity, if ever achieved at all. Getting to care about others, is rarely part of anyone's developer bubble.
You can get away with not-knowing a lot and still achieve results.
But at the same time.. debugging will often be slower if you're not experienced with the domain. Maybe you'll be able to figure it out in a top-down manner.
In terms of gate-keeping? People shouldn't go out of their way to discourage others. Conversely, it's better to be curious, and optimistic about being able to solve problems you encounter when programming.
>However, once they learn how the tools work, they can use their knowledge of fundamentals and their deep experience in related topics to revolutionize the whole development process using those technologies. It can even make the creators of those mainstream tools feel stupid for many of the decisions they made. Sometimes, the tools are getting in the way of producing better outcomes.
In addition, I would focus on this idea that the language, tooling & methodology are largely a means to an end. I think people waste way too much time thinking and discussing tools and languages. Just pick a lane and stick with it. Some programmers I know avoid using mature tech stacks (e.g. C#, Java) in their non-work projects because they feel they're outdated and so they latch on to newer and newer libraries to "remain current" but they never write anything of value that is beyond a couple of weeks worth of code. Just pick a lane and stick with it - go be an expert, the world has enough amateurs.