Changing an car's air filter is obviously different from driving. Flipping a circuit breaker is like flipping a switch, just for the whole house, and also it happens automatically if you anger the switch by plugging too much stuff in or dropping the toaster in the sink. Both of them make sense intuitively.

Changing a .md file seems like it should be the same thing as changing a .docx or .odt file, since they're all different kinds of formatted text, but for some reason you need an entirely different toolchain.

My resume needs to be compiled using wkhtmltopdf, pandoc, and make. It's deployed using Dokku, which wraps Docker, and the Heroku static site buildpack, which wraps nginx. It's kind of weird that a non-programmer doing the same thing would use a completely different set of DIY tools. It seems like an auto mechanic uses roughly the same set of tools as everyone else, just better versions of them and with greater skill.

* "chng af"

* "tglCB"

I will continue my crusade to fight against this and spell things out until my death.

I think you've got it backwards there. I agree with everything else you said, and hopefully the author was being tongue in cheek, but this is silly. Developers have a specialized skill and get paid specialized wages. The behavior you're describing is not limited to developers..any profession that has a specialized set of skills and a specialized language that only the "in" people understand has the same issues.

Also, normal people don't compose documents with pandoc or use the command line. That's not a secretly-disdainful observation just because it uses the word "normal." People with technical knowledge in these areas are abnormal when it comes to how we use computers. The word "normal" doesn't have inherently negative connotations—if anything, in most contexts it's seen as better to be normal.

> Come down from your soap box, learn real empathy, decide you are a Normal Person yourself and get rid of your condescending attitude.

This is way ruder than anything that was written in the post.

Except we aren't talking about a client relationship, we are talking about someone asking you to do something for free because "you do something with computers" without making the effort to understand literally the first thing about what you actually do.

> the pay we provide to developers was a mistake. It has created a class of people that think they are gods.

Painting an entire diverse group of people with a single brush, that's real polite of you.

> Come down from your soap box, learn real empathy, decide you are a Normal Person yourself and get rid of your condescending attitude.

Perhaps take your own advice?

If you think my attitude is condescending in the scenarios presented, then you properly understood what I was trying to express in the last section.

I didn't want to write it in a way that's specifically attacking the (likely technical) reader, so I put the focus on "me"

I can't tell you how much I loathe the label "normies".

Of course you disagree.

All the examples - installing and using a package manager, running a command line program - are "simple" from a software point of view, but they're not at all "discoverable". To understand the steps you need to memorise a seemingly meaningless sequence of text.

Of course, the programmer has a very strong underlying model of all of this, and so these commands seem straightforward. But even for a programmer, this stuff isn't very discoverable. I'm frequently stumped by man pages, and end up having to hunt down an example of how to use a particular command line application on Stack Overflow. I've been using linux for decades and I still often can't find where an applications binaries or config live, and I still very often have to type some magic incantation I found on Stack Overflow into the command line, because my mental model of some subsystem of Ubuntu isn't complete enough to know it. None of these things are discoverable - I've got more patience than most in searching Google and Stack Overflow, but it's not exactly a desirable way of using a computer. I would prefer it if there was a nice button in the system settings that did what I wanted.

When things aren't discoverable, they become hard. And people don't generally like doing hard things. That's not exactly a revelation.

But this article doesn’t strike a chord with me. The author fails to understand that it seems easy to us because we’re familiar with it. Of course we know how to transform it into PDF or HTML. But this knowledge isn’t basic, and it’s understandable that people want to stick to what they know.

Here’s an example. Say you had 10000 rows of CSV to slice and dice and extract insights and visualisations out of. All of us would go to the tools we’re familiar with - pandas, R, duckDB etc. But I think the median Excel user probably completes this task quicker and better than the median pandas user. And then if the pandas person is told “oh, just pick up Excel, it’s easy to learn and so useful” they won’t listen. And for good reason! Excel is powerful, but it’s not easy to learn. It only seems that way to people who already know how it works.

Don’t confuse the familiar with easy. Just because it’s easy for you doesn’t mean it’s objectively easy.

They just know how to type Java on an IDE, maybe some SQL (using some graphical front end), some HTML/CSS. They can't operate in a Linux dev environment at all, can't use the command line or exit vi or perform any kind of simple shell based automation or use git without a plugin for their IDE.

And they also are reluctant to learn because they are self defined into some narrow field that doesn't include all this ops trickery in our workflow that they don't consider real programming.

People who used formatting in any 2000s internet forum know in principle how to use markdown.

That aside, I see it as a problem that tech people fail to anticipate the needs of their peers. I know people like that, who dare to say: "Oh you just need to reverse proxy the port on your server" and they fail to realize the person opposite has a face that seems to be assembled purely out of questionmarks.

Explaining someone what a reverse proxy is involves explaining them:

- what a server actually is (confusingly both the machine and the software)

- how/that web clients communicate with that server (HTTP)

- that on that machine there is software running that communicates a local loopback port (127.0.0.1:7777)

- that a webserver can be configured to grab normal traffic coming to port 80 (http) and 443 (https) and forward it to that loopback port

- that this is called a reverse proxy

Most people are not idiots and will understand an explaination like this. Even if they don't they will be happy that you gave a coherent explaination.

I just tend to remember myself and how unclear everything was to me when I was a teenager. What explaination would that former me appreciate? Sometimes the most important thing to say is something extremely obvious that helps the person to conceptualize the whole thing (e.g. clients communicate with a server and a server has ports).

1. There are a decent amount of software engineers or programmers whom literally aged at the perfect time to organically learn these tools that later became fundamental. If you even touched a computer from the 60s to the late nineties in a engineering aspect at all, you were bound to have worked in a terminal, worked on computers with a single core, worked on computers with very little memory, had to either get comfortable with some lower level tooling or build your own, at some point had to mess with networking or at least understand how packets were being sent and received, seen and gone through iterations of version control and saving your work, automated task using shell scripts.

2. While there is a plethora of knowledge, videos, tutorials and flavors of ways to learn these things; the sheer volume and breadth that presents to newcomers is daunting. Yes you can learn Git, but there are so many ways to do it that it can cause analysis to paralysis. Building on point (1) if you learned it early there were only a few ways it was being done or even shared in smaller communities. Too many choices or paths can lead to just using the way someone showed you without digging 1 layer deeper just because you might not know better.

All of those things you ‘caught’ by being at the right place at the right time are a privilege. Please don’t look down on people trying to aspire to learn or want to enter into this field that haven’t got there yet.

Coming from a family of immigrants and being the first person in my family to graduate college + enter SWE. I cannot count how many times other engineers were rude, made condescending remarks or discouraged me by shoving these expectations in my face as failures instead of taking the opportunity to teach (I was always open to learning).

When you ask your wife to fetch you from work at 5 you don't have to explain:

* That she needs to take a car,

* That there must be enough fuel in it,

* That she has to plan some time for the drive and add extra if traffic is expected on the way,

* That she needs to let you know if there are unforeseen circumstances which will likely mean she won't make it.

And yet for some reason, whenever the topic of doing anything at the computer comes up between us, I feel like I have to start from scratch.

"The printer does not work again. Can you help?"

"Is the printer on?"

"Can you check it, you are better at it"

Checking the printer... of course somebody turned it off.

I think there is a combination of laziness and probably something else which makes some people treat computers as not their problem. For the most part the companies making hardware and software cater to these people making stuff they care about as intuitive as possible. They are fantastic when it comes to activities that make ads pop in front of your eyes.

The trouble is with everything else.

Judged by the standards of a programmer, yes, the suggested solutions are simpler. Judged by the non-technical coworker's standards, no, they are new and therefore scary and harder. You might say, "If they expended even 5 minutes of effort, they would not feel that way." But that's 5 minutes more than just using the thing they're used to.

Often non-technical folk are only interested in "easy" solutions.

Technical folks are more inclined to pick simple solutions.

The perception of simple being hard mostly comes from simple often eliding things like a GUI which is inherently complex and overkill for a good number of tasks. However users have been conditioned to think mouse == easy and keyboard == hard.

> "Why would you do that in the command line? It's way easier using $Program"

A concerning observation that’s slowly dawning on me is that more and more programmers don’t know how computers work. They can write code, build software, and do lots of useful things. But they have no idea how computers work. They’re more akin to lusers as we used to call them than they are to hackers of old.

Fantastic at their specialty and the tools they use. But move a button to an unfamiliar place or throw them into a new (but fundamentally same) environment and they’re lost.

The realization came a few weeks ago when someone shared The Missing Semester of Comp Sci on HN. It’s full of basic things you’d expect any programmer to somehow magically know … but they don’t learn this anymore. https://missing.csail.mit.edu/

Seeing that link shared connected the dots in my mind. I’ve been wondering for months ”Why does everyone at work have so many random local environment issues all the time?” … it’s been working fine for me for years. Same code and hardware. ¯\_(ツ)_/¯

Maybe I’m just getting old and grumpy. I’m sure folks older than me thought “wow kids these days know nothing” when we came on the scene …

Most people receive the training where opening up Word is not difficult, and then once they've done that, there's no step up. They press "a", an "a" appears on the screen. They have buttons that do things like italicize. The first few steps are easy.

It may be the case that after that there is a brick wall in the difficulty curve, whereas the programmer-favored solution is a smooth easy curve for quite a ways. But that first step is sufficient to block most people, and people are often happy to just give up in the face of the brick wall.

This is not unique to programmers. A lot of the "maker" disciplines have a similar step curve. A lot of times it's just that first step that is the hardest overall. But it's enough.

I wish "normal" people were more tech-literate. I don't think they realize just how much of their autonomy they've given up by choosing to use Microsoft Products/Reddit/Twitter/Spotify/Facebook/TikTok/Apple Products/ etc.

We're at a point where now the average person depends on several layers of technology that they can't even conceive of, and often the companies building that technology don't share their political interests. But then the average person expresses frustration at having to use open-source alternatives (which is completely understandable when the open-source alternative is definitively worse!).

Basically, for me not understanding how technology works when it's so central to our everyday lives just seems baffling. I suppose someone could say the exact same thing to me about not understanding how my car works, or how to grow my own food. Maybe technology seems easier to learn than agriculture? But then of course it's easier for me, I'm a professional programmer. So I try to have a lot of empathy for everyone who doesn't understand technology, especially my mom when she doesn't know how to convert a PDF.

They know that engineers (and programmers) are in the same rough class as all the other professionals. These conversations showcase the confusion as they try to figure out what problem programmers are there to solve. Other engineering disciplines also suffer from this - engineering is a subtle art. Nobody knows what we actually do except the rest of the brotherhood :(.

The first example is a really good showcase. They really don't want to be walked through how to solve their problem. The point of the specialist is supposed to be that they solve the problem in exchange for payment. They don't understand that programmers are really all about adjusting the cost of taking action rather than acting directly.

Programs like Microsoft Word are amazing, even Richard Stallman himself has praised it. So there's nothing wrong with Microsoft Word, but some people just feel like a GUI is a bottleneck.

I'm speaking for myself here first and foremost but I know there are literally dozens of us. ;)

Why choose markdown over Word? Why choose CLI over GUI? Why choose Linux over Windows? Because it's just quicker, it allows me to get my ideas out faster than the alternative.

But I'm not saying we don't have some work to do on inter-personal relations and how to deal with end users and clients. We definitely do and I work on that every day.

I think it comes down to memory capacity. If you can remember several languages, or command line syntaxes, or programming languages, then you can use that to get the same results as any GUI program, much quicker.

Empathy is one of those skills that is as, or more, valuable than any particular programming language.

BTW this can happen to any field, not just tech. It can happen with intellectuals, philosophers, medical doctors, blockchain lingo, AI lingo, devops lingo, telecom lingo....

Fortunately! Now we have AI which is insanely good at summarizing and explanning anything like I'm 6y/o so that little expert trick just got massively nuked and has its days counted.

And yet this isn't so.

The reality is that peoples problem solving skills are absolutely atrocious. They don't even try to figure shit out. The maximum number of inferential steps the average person is willing (or able?) to make before throwing their hands up and exclaiming "this is impossible" seems to be somewhere between 0.5 and 2.

There seems to be just enough stuff you can do without having to ever really think for yourself that people are content with not understanding.

This is so far away from my own experience that I really struggle with understanding it. Obvious knowledge gaps and noticeable confusion are two of my biggest motivators. I cannot stand not understanding. It feels like giving up agency.

Wow. I got quite angry there for a second. I guess I need to examine that frustration a little more.

And I find myself wondering if I’m beginning to serve technology rather than the other way around.

Normal computer users want programs with dropdown menus and they are faster with those than we are when we have to look up a command or function that we rarely use. I know people who can filter & pivot a complex dataset quicker in Excel than I can in SQL.

I think it is safe to say that most programmers occasionally encounter something they need to Google for and dig through some stack overflow posts to find the syntax. That would be necessary almost constantly for a non-programmer and it's just not an efficient use of time.

two things; - I think it boils down to people not having 'poked around'. I grew up on DOS / early windows, when messing about, learning commands, configuration files was needed to install and run games (or new hardware). New game, new challenge. This learning process was part of the use of a computer to me. It gave me enough confidence and knowledge to 'try things' in later Windows or software if things were not working. To most people i'm a 'computer guy', yet when it comes to Linux / unix / mac I have no idea how to get around.

- being overwhelmed / debilitating alienness (for lack of a better word), when they dont have adjacent knowledge & confidence. It's not just the transfer of knowledge, but often a çomfort of familiarity that is needed. My wife was a basic computer 'user' who would panic or blank out when she got simple technical instructions or something went wrong. I quickly learned that it was more helpful to show her we can just poke around, and it's ok to not completely understand something. We talked about how to communicate computer problems, and effectively use google. She got over the 'deer in headlights' syndrome, and now actually welcomes any new computer topic - while working in IT service desk!

It's easy to forget how many countless hours I spent learning how to Google for the right command line args and picking up little tricks here and there to chips at problems until I've solved them. Take a deep breath and give everyone else who can barely use their keyboard and mouse to do their work a break alright. Not everyone enjoys bashing their head against the wall to solve these things the "easy" way.

As a programmer I sometime prefer the world of clickety-click GUI instead that of command line. Doing something in a visual way, requires no knowledge. You just discover how to do things as you do them. Using the command line requires me to learn paths, steps, command line arguments, the order of the command line arguments and also memorize them.

Some times I prefer the command line.

I know that for some folks VI or Emacs is better and more productive and faster, but for me Visual Studio is that and more.

Maybe there isn't one objective truth, and for some persons the command line and text editors is better and for other folks the visual stuff is better.

I don't have a solution, but I think we have two big problems: the rigidity of the GUI (it's difficult to combine operations, in some cases impossible) and then arbitrary gatekeeping of features for dollars (why can't the free Acrobat export PNG files?). For every tool like Excel, we have another "simple" tool that is nearly only one possible workflow.

For example, you can theoretically know how to change a tire, or how to use Photoshop to replace a color in an image, or how to troubleshoot a printer. But you only run through that series of steps occasionally, when there's a specific problem to solve.

https://cushychicken.github.io/python-guis-for-heretics/

Might find it interesting.

this right there.

except, it IS easy to learn actually. it's visual, you can click around and find out. if you forget the spelling of some formula, no probs, there is a help button.

the interface is what makes it easier, markdown is also an interface. except it's not AS exposed to the user as excel is.

people dont want to read manuals or consult documentation, they want to hit the ground running.

> the median Excel user probably completes this task quicker and better than the median pandas user

Some might complete it with catastrophic effects.

> A million-row limit on Microsoft's Excel spreadsheet software may have led to Public Health England misplacing nearly 16,000 Covid test [1]

[1] https://www.bbc.com/news/technology-54423988

With Excel you mostly need to know about cell addressing, =, dragging corner of selection, $, ranges and some basic formulas (that currently are much easier to explore than when I was first approaching the subject). That is, I think, around 80% of Excel as it is used, maybe even more.

This may be true in a general sense, but probably not when you talk about the programmer picking up Excel. I often find I can use it for more things than people that spend their whole lives in excel simply because I have a reasonable mental model of what it should be able to do.

That said, I want to talk to whoever made the abomination that is VLOOKUP and ask them why.

[0]: http://www.visidata.org

Learning to sew was a never ending sequence of small steps that required lots of looking up to actually grok.

Thread the bobbin then put it in the bobbin holder, then swap in a denim needle, thread the needle from your main spool, switch to a straight stitch with a wide length, and adjust your tension disks appropriately while practicing on a sample patch. Place your main garment in, do a backstitch, and sew your lines.

All of this is super simple, but if you're just getting started, each step requires a manual (and it even glosses over a few really important parts like making sure to put your presser foot up or down while sewing).

I'm inclined to agree, for the display of some text, it's one of the better choices that I've encountered!

I actually recall working on a system where HTML instead of Markdown was chosen for the storage and display of user messages (think along the lines of a chat/e-mail app), which came with a plethora of complexity and problems - everything from various editors across apps formatting things differently (sometimes breaking WYSIWYG), to the formatting in the database becoming inconsistent as the apps and libraries are updated but old messages weren't affected, any sort of manual parsing and migrating this data being difficult, as well as sanitization concerns and security challenges.

The Markdown suggestion of mine was shot down, but as far as I know there was just problem after problem with using HTML before I took a break from that org and took a bit of a sabbatical. Then again, migrating between different formats like Markdown and HTML is needlessly complicated if you have pre-existing data, so it's better to make the "correct" choice on day 1.

Pandas are free; Excel is not.

For me, I have been developing for several years in several different contexts and consider myself a decent software developer who focuses a lot on proper design and implementation, readability, maintainability, speed when needed, etc. However, I am relatively weak on all the various Unix tooling (I know the general basics of course) and am currently trying to address that. Reasons for this are that I worked professionally for a long time in a Windows environment. Any scripting done was via PowerShell, which is a quite powerful tool and language and something I actually often prefer given the readability, if not verboseness, of the commandlet names or via the programming language used. My more Linux oriented roles or projects are more recent and have used languages like Elixir or F#. Since both of these languages have built-in scripting, any scripting was done with the languages themselves. Elixir has such powerful tooling that, for whatever reason, I just rarely found that I needed the Unix command line tools for what I was personally responsible for or working on or what wasn't provided by Elixir or my editor in VS Code. Elixir allows you to build custom Mix commands, which is also nice. However, now I'm in an environment where many of these tools could be very useful, so I am trying to pick them up. And it's always possible that I was missing out, so it's important just to be willing to learn as things present themselves.

Just stating this because context is everything.

#1. They are just stupid.

#2. They don't care about work other than bare minimum to not get fired. They have better things in their life to care about.

#3. They are as smart as you are, but they put their efforts elsewhere that you don't directly observe. May be they don't know how to operate Linux environment, but they spent days reading about DSP math and they can apply this knowledge to optimise some signal filter. May be they don't know HTML, but they spend that time to learn Spring internals and can compose really beautiful code out of it or solve very hard problems.

I think that specialisation is not that bad. It's everywhere. Some people in IT are generalists, they know a bit of everything. I consider myself one. I'm trying to build an embedded Linux distro right now, few days ago I was writing parser for PDF to extract some information (real parser, byte after byte), few weeks ago I tinkered with STM32 program, few months ago I wrote Java service, next week I'l continue to work on React web app which is going to run on embedded device. I do everything, my knowledge helps me immensely to quickly dive into new area. But i'm absolutely far from expert and sometimes I'd spend lots of time when I lack a knowledge. For example I spent two weeks trying to start graphics on i.MX8MM board and I failed. I need to debug kernel but I just don't have that kind of skill in Linux internals. But there are people who prefer to specialise and that's fine and they would probably solve that problem in few days.

Who want to use old versions of eclipse, on win8, install new copies of the same for diff projects, want the new associate level engs (23yo, first job, etc) to write plugins for that old eclipse so the shipped plugins that break due to age still work. Because they dont know svn command line, or how to merge without the plugin.

Won’t migrate to git from svn - though that’s ok, we don't “need” distributed vc. They still think git history is so mutable its “spooky.” Though I’d love to make branches while working from home and not on the vpn…

In short, and it’s just one story, really: this kind of thing happens at all levels and is really a management issue, imho. They should be pushed to expand knowledge as a priority in the workweek.

Often we’re just tossed into “fix it ship it” mode and before we know it we’re 60 and cranky and yelling at clouds.

There may be some of this, but I think there is also the part where it can be really hard to learn.

Typescript is my preferred language these days. Not for technical reasons, but because it lets small teams share language across the entire stack. At least in my area where React is basically "front-end" and it's tiny rivals are also Typescripted.

But a lot of the eco-system is admittedly sort of silly. Say you want to use environment variables. A lot of people will use dotenv, we do too, but you can use it in many different ways. You can require(), you can import, and then you can use process.env.VARIABLE in your code. Which is fine, but really, what we consider the best practice way of doing it, is something a kin to having a config.ts file, which exports all the configuration as javascript objects. This way, you can use dotenv like this:

node -r dotenv/config dist/app.js

Nobody is going to tell you how to set these things up however. Well that's not exactly true, because EVERYONE is going to tell you how to do it, and in this myriad of options you're most likely going to end up with something that isn't great. React and other major frameworks with build tool will be opinionated and do it for you. React does it similar to how we do it, likely because having all your process.env.VARIABLEs exported as const means they are typed which makes it easier to debug. This doesn't mean developers necessarily pick up on it though. I've seen many React developers who don't use dotenv the way React does it, despite them having been exposed to the benefits of the react philosophy.

So I think it's more than just reluctance. It's simply hard, and the internet or the community sort of makes it harder. Because you and I both know exactly why these React devs used it differently, they did it because the first 2000 100 word blog articles that you get when you google "how to dotenv" tells you how to do it "wrong".

Then once these young developers venture out of their comfort zone, their impostor syndrome gets additional power when they do it "wrong" and someone calls them out on it in a less than friendly way.

I've noticed something with boot camp programmers too.

Something that may have changed is that newer graduates may have studied programming because "it pays well", and not because they were computer hobbyists before deciding what to study.

I've been on meetings with some programmers that didn't know how to use a gui ftp client or how to manually upload a file to a server. Because most of that stuff is abstracted now.

It's normies all the way down.

Sure, I graduated from college almost two decades ago but all those "can't"s were very much part of the standard CS curriculum then. You needed those skills to pass CS 101.

The new grads I work with now at are fine on the terminal. They only complain that they didn't learn how to use more "advanced" features of debuggers and IDEs in college. Exactly the opposite.

> They just know how to type Java on an IDE, maybe some SQL (using some graphical front end), some HTML/CSS. They can't operate in a Linux dev environment at all, can't use the command line or exit vi or perform any kind of simple shell based automation or use git without a plugin for their IDE.

> And they also are reluctant to learn

Sounds like you are hiring wrong. The point of a good engineering degree is to teach someone how to learn. Any degree worth something will include non-trivial coursework and projects, so they should already be familiar with some of the tooling.

Your problem might be where you get your fresh out of college developers, you may get them from prestigious universities, but it says absolutely nothing about whether they actually love programming or not, or they are just in programming because of the promise of a fat paycheck.

We were talking about a recent problem he was having, getting his IDE and build server and virtual environments talking to each other, and it became immediately clear to me that if he knew what an environment variable was, he’d have solved this in about 5 minutes. Instead he’d been stuck for days, kind of just flailing.

I also suggested spinning up a dev VM or container so that he can make snapshots, nuke it and start over, etc as he makes progress figuring it out. He flatly stated that that “wouldn’t work” for reasons he couldn’t articulate.

I am almost obsessively curious about how computers work, and that curiosity led me to Linux and a nearly 100%-CLI workflow. That more than any other skill has paid off, even if viewed completely dispassionately: at least half the tools you’ll be using will have been written from this same POV, where a CLI-centric workflow and Linux are both first-class citizens.

A lot of people just want to “write code” but seem to completely ignore the reality that that doesn’t happen in a vacuum. You’re using tools, and those tools very often require some understanding of the computer they’re running on.

There’s some meme floating around out there about how “easy is hard” —- exercising is hard, but enduring the effects of not exercising is harder, etc. Now that I’m on the other side of it, I absolutely believe that working in the command line, ideally on Linux (but macOS will do fine as well), is the best way to pick up all the “glue” knowledge that allows you to reason your way through just about any situation you find yourself in. We do ourselves quite a disservice by calling most of these skills those of “sysadmin” or “devops” or what have you —- to me it just seems like it’s “knowing computers,” and when you’re spending your days writing instructions for computers to perform, that can surely only be a good thing.

Highly agreed. This seems to be common among all programmers, but most prominent in products that have little input from non-programmers (e.g. open source projects).

Most people would understand your explanation ... given the effort. But they don't care, they just want it to work. And that sometimes involves going with an expensive proprietary solution over a FOSS one because the first screen provides a better introduction.

"Do I look like I know what a Jpeg is?".

I got her hooked on markdown for note-taking, I just had to find the right editor to convince her to let go the few hours of Word she 'learned' at school.

Thank to all Joplin SWE, managers and designers. Great product.

And BTW, I still think org-mode is overall better, but sometimes worse is best, and to me Markdown won.

I tried my hand at blacksmithing, and had to learn (what seemed like) a lot of metallurgy before half of what my mentors were saying made any sense at all.

Sometimes it's on the expert to make it clear to the non-expert. Other times it's on the newbie to learn the basics so they understand the answer to their question. .

I can agree that people tend to quickly get condescending ("just google it") instead of giving keywords ("I think you are looking for X, Y, Z, try to read about them and come back when you have specific questions"). IMO the latter is constructive, the former is discouraging. The point here is: don't be condescending, try to give advice/keywords.

This said, many beginners think that their first project can be a complex application even though they don't know how to write code. The constructive comment for them is "start small, learn the language first", but of course many beginners don't take that as an answer. Beginners need to accept that learning software engineering takes time and dedication.

Finally, some devs tend to think that they are so smart that if they don't grasp something in 2 seconds, then that something is bad. I disagree with that. An experienced developer should know how to learn a new tool. If they don't like it, they can try another one, write their own (and see if a community follows them), or just accept that they don't have a choice. That's how it works.

I know the feeling of being looked down on. And vice versa I’ve been just as guilty of doing so when I was younger.

Both fundamentally sucks and doesn’t lead anywhere.

Managing our ego is hard, but even just the attempt goes a very long way.

The physical existence of a car gives a lot of indications of the function of a car. People deal with computers through arbitrary idiosyncratic curated interfaces that for business purposes often plot against their users.

Whereas "the car won't start" is equivalent to "the printer isn't working."

Many people know how to diagnose and resolve simple car issues, like a dead battery, just as many people know how to fix a printer that isn't working.

It's not preinstalled on most computers and costs money, it won't run everywhere (running Word on a school provided Chromebook is a world of fun), for decades it had version compatibility issues, and the current version has an UI that would make an airliner pilot feel right at home.

To me most people in the corporate environment are highly technical and have arcane knowledge of crazy complicated tools and workflows. Just not _our_ tools and workflows.

And yes, I also don't want to go buy an Office license, install Word, learn how to deal with the commenting options, what format I should save the file back, when some random person sends me a Word file. So we're all pretty alike I think.

I do feel somewhat jealous though that these resources are now available for students to learn in a structured, borderline spoon-fed way when this stuff took me a number of years and hacking around to build up and gain muscle memory over. Still, I think the knowledge you struggle to learn yourself sticks around a lot longer than knowledge that was fed to you from school. :shrug: I could see it either way.

This would help them understand how OSes work under the hood, from squashfs and bootloader right up to a graphical GNOME install.

You don't have to do it all the time. Just once, to understand what you are using all the time.

I think that a huge difference between generations is also the appreciation of "how easy" things got to be, because tooling has come so far.

I mean, look how easy golangs cross compilation pipeline got...and compare that to 90s C development where you had to recompile libraries on your target machine all the time because linkers were glitchy and uncompatible, and header-only files weren't a thing yet.

Hard to say if it’s any truer now than it is today, but the kind of work we do and tools we use have certainly changed over time.

I graduated college without ever running a version control command, except for copy-pasted CVS commands to download software from sourceforge.

For the vast majority of people, understanding technology is simply not worth their time. They have other, more important things to worry about.

You don't know nor care to understand how telephones and cars and electricity work. Nor how and where the food in the supermarket comes from. Water comes out of the faucet because faucets dispense water. You have more important things to worry about, like computer technology.

Much like those aforementioned things are merely a means to an end for you, so too is technology merely a means to an end for most people; their ends lie elsewhere.

Or to TL;DR: Life's short, ain't nobody got time for computer.

I don’t know. I appreciate the sentiment and would also like more tech literacy, but there are lots of areas central to our lives and I think it’s unrealistic to expect a good understand across it all.

I think it’s on us to be able to adequately communicate and understand the needs of those that ask us for help.

Just as you would want a doctor to explain what your condition is in a way you would understand.

Having buildings to live in is pretty central to most of our lives too, and we have some knowledge and intuition of what looks safe and can be used, but most of us leave the engineering to someone more in the know.

Farming too, I rather people in the industry work on maximising yield to feed us all with tools made and tailored for them.

I think when people go to the quickest solutions for them in tech (i.e. Ms 365, Spotify, John Deere, ABC MRI Scanner etc), I’d rather have them focused on the details of their trade than learning how to use a terminal, jailbreak a tractor or replace a magnet in an MRI scanner.

Those that want to, great, but I think most don’t have the time or interest to take on that kind of deeper learning.

Markdown is incredibly accessible to people who know how to drag files around on a file system and open them with a click, and every laptop/desktop operating system includes a fast and reliable text editor.

But many people don't have one of these "real" operating systems. Most non-technical people I know would need to build the mental modals of having "files" existing on a "file system" before they could even begin to create, organise and edit text files. Even as I describe this I wonder If I am parroting the xkcd...

Life is short but long enough to become specialized in deep wells and to have cursory knowledge in others. Understanding that what is easy to you is daunting to others is critical to knowing the places you are daunted by. I'm an engineer, I will be the first one to tell you that I can't tell you by memory every dev pattern known to man. But I also empathise with normal people. People just want normal, consistent solutions that work without needing to learn unrelated details.

To a non-dev type, telling a person to run a program in a terminal after updating their package repos is like telling them to till their garden with a backhoe. "First, learn to operate a backhoe, it's easy and so much faster. Then..." This means this user has a garage full of normal garden tools..and then a backhoe. To a normal gardener, who isn't on a construction crew, this obviously is nonsensical.

Helping people means helping them on their terms, not yours.

Side detail:

A few years back, the company I work for (B2C) held a poll in the Eng org that asked "What excites you most about your work?" There were poll options like "Solving hard technical problems", "Building great solutions for our customers", "Using new technologies", etc.

"Building great solutions" was dead last with less than 5% of votes. We now are a product led organization with a focus on customer experience and I would say 75% of everyone in Engineering were replaced over the past two years. We just shipped one of the first actually UX-focused products by the company. It is so brutally clear why we wouldn't make progress in the past. Every choice was self-centered on what tech was flashy and cool rather than actually shipping.

If someone asks for help it's important to tell them that sure, we can help, but "IT support" tends to be a lot less like "help me assemble this furniture from IKEA", and a lot more like "sure, let's install the ceilig fan, but oh it turns out the ceiling is cursed and now we have pierced the heavens and for 30 days every midnight you'll be visited by the mailer daemon, also we need the address of your first born, just a mere formality, you know, no biggie".

People has to recognize that in many cases there are no easy solutions for "them", even if it's easy for "us", because it depends on their willingness/ability/capacity to learn new things, which in general is a hard thing in tech.

At some point it might be worth installing a distro on an old-ish laptop you may have lying around - Pop OS is the least problematic in my recent experience. Then actually use it.

You will accidentally irretrievably trash everything numerous times, WSL lets you backup & restore distros easily so do do that. With full installs, just remember to have copies of your config & data.

That said, as the sibling comment by sanitycheck mentioned, start using it. WSL2 is pretty okay.

Oracle is heavily promoting its cloud services by offering a pretty beefy free tier (24GB RAM, 4 vCPU aarch64, 200GB SSD, +1 IPv4 address)

I'd start with self-hosting a bunch of stuff. Just for fun. Whatever interests you. Try things with and without Docker. Write a Dockerfile, build it, run it. Write a systemd unit file, enable it, start it, stop it, disable it, mask it, etc.

Buying a (second hand?) laptop and installing Linux on it instantly provides a ton of interesting challenges. Which distribution? Which version of the distribution? How to partition the disk? Encrypt my files? Only my home dir or full-disk encryption?

Try KDE, try Gnome, try Xfce. Try Ubuntu. Try Arch (because it's hype, also it's a rolling distro, also pacman - its package manager - is pretty nice) ... I don't like RedHat-based distros, but ... millions do. Who knows, maybe you'll like it. (Try Fedora.)

Okay, you set up your Linux desktop. For you it's definitely the Year of the Linux Desktop. Congratulations! You're irrevocably one of us now. (I'm typing this on a shitty Windows 10 laptop, while a feet away a newer, but even worse Win11 laptop sleeps and ... I've been using Win10/11 on my big "dev" box for years (for playing 5+ year old games, obviously) ... but ! finally got fed up with BSODs and ~6 weeks ago I've installed Linux on it again ... then I moved and it's still in a box in storage :(((( )

Oh, yeah, this reminds me. Try Wine! Definitely try Lutris. (StarCraft II is free now, works great on Wine.)

... also, ask questions! (There's even a guide for asking questions! http://www.catb.org/~esr/faqs/smart-questions.html Oh this reminds me of the howtos. So backin the day there was this https://tldp.org/HOWTO/HOWTO-INDEX/howtos.html :) before youtube videos took over.)

That's it! Absolutely nothing else. No need to learn shell scripting, no need to open the terminal, no need to know just enough python to be dangerous. No need to know what's DKMS, nvidia drivers will just work. Everything just works! Bluetooth headsets and network printers too!

(ps. I lied, sorry!)