Popular Elitism In Programming

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.

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.

    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

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.

>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.

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?

Trying to jump from there to doing anything with C++ in the days of mingw and Bloodshed DevC++ and Win32 was... not pleasant.

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.

It also has almost nothing to do with the actual business of writing a program.

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.

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 confidently hack on this system without agonizing over performance."