72
The Stupidity Manifesto (insimpleterms.blog)
submitted 10 months ago* (last edited 10 months ago) by canpolat@programming.dev to c/programming@programming.dev

The Stupidity Manifesto

LET’S STOP MAKING EACH OTHER FEEL STUPID. Instead, let’s…

  • ENCOURAGE EVERYONE TO ASK QUESTIONS
  • Lead by example: Be honest when we’re confused
  • Value curiosity over knowledge
  • Prioritise clarity over jargon
  • Remember we all forget stuff
  • Get excited about teaching and learning
  • Acknowledge the broad range of knowledge in our industry, and avoid judging someone if their knowledge doesn’t match ours
  • LET’S STOP MAKING EACH OTHER FEEL STUPID.
all 11 comments
sorted by: hot top controversial new old
[-] bitcrafter@programming.dev 19 points 10 months ago

I appreciate this sentiment a great deal in general, but sometimes it is difficult to uphold when I have to regularly deal with "time vampires" who not only require that I explain the same thing to them over and over again beyond reason but who also show no willingness or ability to actually learn the thing that I am explaining to them; at some point I just run out of patience and start ignoring them to the extent that I am able.

[-] emptyother@programming.dev 4 points 10 months ago

The way I see it, explaining others also helps me understand it better. If its so basic (or too advanced) that I get nothing out of explaining, then I leave it to better suited people to help them instead. Being on these kindsa forums, its supposed to be enjoyable for both the teacher and the student. I don't see any shame in dropping it as soon as it turns frustrating.

[-] SmartmanApps@programming.dev 2 points 10 months ago

explaining others also helps me understand it better.

There's a saying - if you want to learn something then teach it (even to a rubber duck ;-) ).

[-] jadero@programming.dev 3 points 10 months ago

This may not apply to your situation, but I found that most of my problems like this were related to "general vs specific".

Many people have difficulty generalizing from specific instructions so they need help every time something looks different to them. In an extreme case, found a person unable to choose a font in the header of a word processing document because the only thing they'd ever been shown was how to choose a font in the body of the document. It's not even that they were particularly dense, it's that they'd seen so much unexpected and unexplained variation in other areas that they started assuming that everything is an isolated task with a potentially distinct set of procedures. Now that I've switched from Windows to Linux, I'm getting a better understanding of how that happens, with many applications using different hotkeys, not implementing what I think are sensible "tab ordering", etc.

Many people have difficulty going from the general to the specific without also seeing several specific examples in a variety of scenarios. That kind of thing normally requires more formalized training. If their only exposure to your knowledge is through ad-hoc help desk kinds of interactions, there will be no opportunity to put everything together.

[-] SmartmanApps@programming.dev 12 points 10 months ago

I actually was a teacher for a while (Computer Science and Maths), and I still do tutoring. When I started working with Xamarin, with no prior .NET/C#/GUI experience (just shell scripts and programs in DOS and Unix), it became clear as day to me that no-one at Microsoft had the slightest idea how to teach things. That hasn't changed even now. The documentation is horrendous - they don't even follow basic grammar rules like spell out an acronym in full the first time, so first time you hit one and you don't know what it is, now the document is useless (because they haven't linked to any assumed background knowledge either - have you tried Googling COM to find out what it is?). When I told someone there (who I won't name) they said "it's near impossible to cater for all levels". No it isn't - you start with the fundamentals (or link to them) and build your way up to the more advanced.

Microsoft documentation...

Here's my blog on writing a MAUI UI in C# which illustrates how to write a document (though I realised later I missed linking a few things and still need to go back and fix those) - Creating MAUI UI's in C#

It's also an issue with their templates - there's no such thing as a "blank" MAUI app. They stuff a bunch of stuff in there which violates "teach one concept at a time". I was so relieved when I found out how to make my own templates! (shell be gone! XAML be gone!)

Here are the basic rules of teaching...

I would add to that (for documentation) always spell out your acronyms in full the first time, link to any assumed knowledge, have step-by-step instructions, and make sure you cover different uses from basic to advanced (and don't damn well use Foo Bar - use a real world example).

[-] SorteKanin@feddit.dk 9 points 10 months ago

I resonate a lot with the point about teaching. Honestly if it wasn't because teachers are woefully underpaid, I would've become a teacher probably. Instead I am left with being a software developer who gets excited every time I can introduce a coworker to a new concept.

[-] Dagwood222@lemm.ee 8 points 10 months ago

This should be used in all areas.

I used to work in public health and I'd see people who had certifications [not college degrees] talking down to patients, and top doctors who were happy to explain things.

[-] MajorHavoc@programming.dev 3 points 10 months ago* (last edited 10 months ago)

I love this.

Usually when I encounter folks who are tired of explaining things to peers, the issue is with them not having strong teaching skills.

Not being good at teaching is perfectly fine for a regular team member. But on my teams, senior title means doing mentorship. And lead title means doing Mentorship often and well.

I've inherited a team lead who was frustrated with how much of his time I expected him to spend mentoring. (I would not have promoted him to that level, prematurely, but he already had the title when I was hired to save the team.)

My response for him (in private one on one) boiled down to "get good, newbie, or there's the door". Anyone on my team with a senior or lead title is expected to prioritize teaching and mentorship. If they want to spend less time doing mentorship, they can either get really good at it, or find a team that fits them better.

Of course, I rarely hire unteachable folks, and I do fire them if needed. I know we've all worked with someone that makes us think "what about this clown?"

Edit: The ending of my annecdote is that team lead improved at mentorship dramatically, and discovered that his effective influence on the team increased dramatically in lock-step.

[-] SmartmanApps@programming.dev 4 points 10 months ago

Of course, I rarely hire unteachable folks,

There's not really any such thing as unteachable, just people who are too stubborn to admit they could learn a thing or two (or even worse, those who rebel against being told what to do).

[-] MajorHavoc@programming.dev 2 points 10 months ago
this post was submitted on 14 Feb 2024
72 points (95.0% liked)

Programming

17674 readers
52 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS