the cognitive load of explaining
Posted by selfimprovementkink@reddit | ExperiencedDevs | View on Reddit | 60 comments
this is mostly a thoughts post. i have been working as a developer for close to 5 years now. this is the only job i've had - so maybe i have a limited world view. i feel like software engineering jobs involve constant explaining. i don't know how other jobs are and to what degree are tasks simple/complex, but where i work i find that i (or people i work with) are constantly explaining things.
-
code review. code change touches this non-obvious change thaf has been around for ages. spend time explaining said behaviour to the reviewer.
-
production issue happened. overall simple, but it's a side effect of something that the codebase has been carrying around for ages that we only discovered now.
-
environment is broken. spend time explaining to the other team WHY their component is not set up correctly or needs to be pointing to some endpoint.
idk, there are various degrees of explaining, but i find that in this job i am always explaining. i feel like its mentally taxiing a lot. because one thing is doing the job, the other thing is condensing it to explain it to a second person- who nearly never has any background or context. i dont know if anyone else feels it
i'm sure an elemnt of it has to do with the workplace, project and culture but wondering if anyone else feels the same
DrStrangelove0000@reddit
Coding is just explaining humans to a computer.
break_card@reddit
Stealing this
eraserhd@reddit
Also, good code explains humans to humans.
megalogwiff@reddit
As my team's low level person, I spend more time explaining computers to humans.
poralexc@reddit
Not just explaining, but knowing your audience and code switching appropriately.
Describing something to another engineer is way different than someone from support which is different than a VP, etc.
mmcnl@reddit
It's mentally taxing because you don't realize it's an important part of the job. And if you're doing it a lot it's probably because you know your stuff. So embrace it.
sorderd@reddit
If you are feeling mentally taxed, are there any specific individuals who are taking advantage of your good nature and willingness to explain?
A lot of the stuff you mentioned is normal and could be ameliorated with more documentation and establishing DOD and DOR. But, if someone is overstepping bounds then you might need to handle it by involving stakeholders. I have had several narcissist type people get very weird with me, doing strange things to try to get me to explain things to them. With these types I close off free info and ask them to set up a meeting and provide an agenda and force them into using the established processes.
powerofnope@reddit
Sure thats what dev is about. Explaining computer to yourself (usually called understanding) and others and on the reverse explain humans to the computer.
libre_office_warlock@reddit
Technical communication is one of the most valuable skills any developer can hone, and most companies don't know what they've got until it's gone when it comes to an engineer who is as good at communicating things as they are at coding.
cougaranddark@reddit
It's cool, communication is only a part of the job when we're not code monkeys just paid to type. It's part of what makes us more valuable than chat bots.
When things like this bother me, I keep it in mind the next time I get out of the house. I see the guys working on the highway laying tar at 1am on a 90 degree summer night. I see the cashier at the store, having been on her feet for 5 hours at a time dealing with customers who pay in pennies. And they get to explain things to idiots all day, like why their expired coupon didn't work, or why the price on the shelf was different than what they paid.
Then I realize I'm getting annoyed by something when I get to wake up, go to my own desk, enjoy coffee while explaining things to people over Slack, and through a magical combination of keystrokes and mouseclicks, make the balance in my bank account jump every two weeks.
General-Jaguar-8164@reddit
Problem is many places including lead/architects treat you as code monkey
So_Rusted@reddit
yes, it is but you should develop your "style of communication" both written and verbal.
I try to speak in similar style every time which is not super technical, but dumbed down and specific.
I find the hardest thing is to communicate and confirm a complex combination of multiple switches of "OR" and "AND" and to translate into a simple verbal language. It is a different style than writing it in the code.
Spoken language pretty much uses "AND" and "OR" as replacements of each other so I have to keep that in mind. But I also have a "system" for that
Swimming_Search6971@reddit
Our job is not to write code, is to think what we need to write. Our main tool/resource is thinking, and it's normal we all have to express/explain our thinking.
Assembly line workers don't need to explain they're work. There's a procedure and there is nothing to debate about. We don't have a procedure, we have to create that procedure hence the need to explain.
nutrecht@reddit
Our job is 90% communication. You're not a "programmer". You're a software engineer.
thekwoka@reddit
The main purpose of the code you write is not to tell computers what to do, but to tell other humans what the code is supposed to do.
local_eclectic@reddit
Explaining is great. It exposes gaps in your knowledge and helps you to strengthen it. Be thankful for every opportunity you get to explain things to interested parties.
selfimprovementkink@reddit (OP)
i guess you're right. it's just that - it isn't what i had in mind 100% when i enjoyed programming. i see how it is one of the most important skills for an engineer, and i can do a reasonable amount of explaining. but lately it's just felt like spoonfeeding everyone. i need to be better at it for sure. but. it. is. exhausting.
dank_shit_poster69@reddit
For high speed / high risk projects we typically only put the people with previous deep and wide expertise together to zoom forward on the project so they cut the cost of educating down.
Education/explaining costs can rack up significantly when you do more deep technical focused projects. Small senior only teams avoids the stopping/s tarting the car again cycles and lets them cruise at full speed on the freeway to get to their destination in a reasonable time. People sometimes don't realize how much time is wasted due to traffic (explaining/educating others on significant knowledge differential topics).
Not to say it's not worth explaining/educating. That's also very important, but typically reserved for when you the time / money / slower paced projects. Like educating the manager by teaching them in your week long course on whatever it is. Sometimes as a dev you have to be a professor for a semester. Typically larger companies are the only ones that can afford this though.
su_blood@reddit
If it is exhausting it probably means it is just one of your natural weaknesses. Keep at it and it will become easier. For me, explaining has always been the fun part and that’s how I learned that’s one of my strengths.
kerrizor@reddit
This is one of the reasons why non-traditional engineers (without a CS degree or who additionally have LibArts backgrounds) tend to see career acceleration later in their careers.
SoulSkrix@reddit
Out of interest, as someone with a CS degree, what makes you say that? (Especially the lib arts part)
rump_truck@reddit
Early stages of the career are usually about improving technical skills, which obvious CS majors have an advantage there. But the later stages are about aligning people to do things bigger than what you can do on your own, which leans a lot more into soft skills that liberal arts people tend to have an advantage in.
SoulSkrix@reddit
Ah thank you, that makes sense.
kerrizor@reddit
It can often be more difficult for new engineers with “only” a bootcamp experience (or self-taught) to break in; they don’t have access to internships, hiring fairs, networks you established in college, etc. They also tend to have skillsets focused on performing on the job or what interested them, so they are more likely to struggle when posed with the gatekeeping nature of most interview questions. They tend to find employment easier with smaller companies, projects, and firms, and can take a few years to assemble a resume compared so someone with four years of compilers and algos who lands the AMZN gig and immediately has “a name” on their CV.
SoulSkrix@reddit
Internships are not really college accessible, they are just general things you apply to like jobs, hiring fairs sure enough - though you get into debt for the privilege. As for skillsets, compilers and algos are a lot more theoretical than practical, I wish I could say it really helped get a job - but practically I do not believe so. The little paper at the end that says “I committed to hard work for 3-4 years” is doing the heavy lifting. As for Amazon, well.. an extremely small fraction (< 1%) of students come out of University working for such a big name. Most students still do the “small companies” thing.
loctastic@reddit
you’re five years in. Think how you’ll feel ten years from now!
selfimprovementkink@reddit (OP)
i dont know if youre implying i'll get better or worse 😂
loctastic@reddit
Buckle up, buttercup!
selfimprovementkink@reddit (OP)
this aint fr me
RespectableThug@reddit
Be careful what you wish for lol
marvlorian@reddit
It's definitely a lot of work to explain things to others. It's also extremely important work. The better you get at communicating and empowering others with shared understanding the more successful everyone will be. The more people understand the WHY around things the more people will be able to make informed decisions that make things better rather than worse. I contribute a lot of code and process rot to failures of not effectively explaining WHY which prevents people from making safe changes or changes at all.
600lb_deeplegalshit@reddit
but it’s maybe one of the most important skills and it also gives you project estimation super powers if you can sense how long it takes people to learn things
cougaranddark@reddit
Someone's downvoting reasonable replies like this, which is very odd
600lb_deeplegalshit@reddit
lol yeah i have an advanced degree and spent a lot of time in stem classrooms
difficultyrating7@reddit
you’ve got it backwards. the second part IS the job. you’re paid to work on teams and in companies with others, which means you have to learn how to effectively knowledge transfer or set systems up where this is less burdensome.
Efficient_Sector_870@reddit
As a recent staff engineer, aiming for principal some day, this is refreshing to hear.
dashingThroughSnow12@reddit
Do you work for a company where principal is above staff or am I misreading what you wrote?
Heffree@reddit
Principal is above staff
dashingThroughSnow12@reddit
Neat. Every company I’ve ever worked for, principal is below staff. Sometimes significantly below staff.
Heffree@reddit
I think you’ll find that’s not the norm, but I believe it exists, not sure how many companies you’ve worked for, but even 2 is surprising tbh. Maybe it’s a regional thing?
dashingThroughSnow12@reddit
I worked for two Fortune 50 companies who had this (principal five levels below staff) 🤷♂️ I think startup (principal below staff) and worked for one consulting company where principal was two levels below staff.
Heffree@reddit
I wonder what was wrong with them. Just sounds wrong to me lol. I’ve been googling looking for anyone mentioning that hierarchy and struggling a bit, but I don’t think that guarantees it’s more common.
dashingThroughSnow12@reddit
Until today, that seemed perfectly normal to me. I can confirm from all my Bing searches that staff does seem to typically be below principal.
ParticularAsk3656@reddit
Communication is largely all that separates truly great engineers from mediocre ones. The value of clean code and even architecture to a certain extent diminishes as you rise.
jkingsbery@reddit
You don't have to explain the whole problem to someone who has context. I see a lot of engineers earlier in their careers do this, and you're right, that is exhausting. Instead, mostly people want to know, (1) how does the thing effect me? (Project date needs to move or business metric will be effected by X%), and (2) why is the thing hard?
Also keep in mind that you didn't have any background or context at one point.
Junior jobs require some amount of explaining, but senior and staff+ require more and more explaining of different issues to wider groups of people. It comes with the territory, and one of the reasons why some people decide not to pursue promotion to senior or staff+.
Other jobs also involve lots of explaining. White collar jobs are mostly a loop of explain problem -> go learn some stuff -> think about that stuff -> create an explanation -> explanation leads to next problem to explain.
safetytrick@reddit
It gets easier as long as you keep trying.
skidmark_zuckerberg@reddit
Breaking complex things down into words that another person will understand is the job. Doesn’t mean I don’t let out a sigh right before I start typing out an explanation, because sometimes it’s hard to put something into words, but you got to do it and accept it’s part of the job.
I usually judge a developer based on their elegance when explaining something technical to someone who is not on the dev team, but also to other developers. Being a Senior level developer, soft skills are more important than coding abilities. You can be a mediocre developer but an amazing communicator and go further than the good developer who wants to work in a bubble.
vansterdam_city@reddit
Yes and the higher you move up the more importance will be placed on your ability to communicate effectively to increase the value of the output of others around you.
Frankly the coding is almost always the easy part.
TheOnceAndFutureDoug@reddit
Learning how to communicate clearly to different people at different levels of authority and technical capability is a big piece of what separates juniors, mids, seniors and leads.
As a lead I need to be able to walk into a room of engineers and explain very technical things in concise, clear language so we all know the game plan moving forward. I need to then be able to walk out of that room and go next door to a room full of stakeholders like PM's and executives and have the same conversation but in a way they can understand.
This is a skill. It takes a lot of time to cultivate and like all skills not everyone can be good at it.
Also, every job of sufficient technical depth has this problem. Design has this problem. Finance has this problem. Imagine being a doctor... If the thing you're doing requires education and/or training it has this problem.
Fury9999@reddit
It's normal to be explaining lots of things. Where I tend to get frustrated is if I feel like I'm the one doing the explaining/teaching to those around me, but I am never the recipient. This isn't the case currently, but I have been in places where the flow of knowledge was heavily weighted in one direction, which leads me to a place where I start to become frustrated that there's nobody who can teach me anything new or interesting. I guess it's like.. would you rather be a big fish in a small pond, or a small fish in a big pond. If I start to feel like I'm the big fish in a small pond, I get antsy. I want to be able to learn and grow from those around me just as much as they learn and grow from being around me.
throwaway1736484@reddit
It’s part of the job and I keep a .txt of bullet notes to record a quick explanation. At some point in the work process I will have to know the answer and It saves brain cycles later bc it will come up.
On the other hand, sometimes people push too hard or too often in contexts where it’s not relevant or appropriate. Sometimes it’s innocent, sometimes adversarial, always annoying. Those situations need management or avoidance.
The_KillahZombie@reddit
Srs explain it well and break it down. Jrs and regular engineers do the bulk of the button pushing. Leads connects all the parts intelligently.
At least that's how it's typically supposed to work.
maclirr@reddit
The cognitive load, and the way it's considered "free" by the people asking for the explanation. And the power dynamics behind who has to explain what to whom.
Efficient_Sector_870@reddit
I spent my early childhood and early career asking questions and not getting answers. So it's refreshing when I meet people at work who are good at explaining things. I also love explaining things, but have to try and stop myself from
1 explaining unsolicited
2 over-explaining
It's become one of my greatest strengths for working with management, product, other devs of all levels.
To your question of "the cognitive load of explaining": we're not the same person, but I don't find explaining very taxing. What I find taxing, and what I think you may find taxing, is context-switching rather than explaining. I've found context switching to be the most taxing thing I have to do cognitively.
Calamety@reddit
1 year at my current job and I would say 50% of the time we spend talking is usually explaining the way some module works. I think it’s fine that way when something goes wrong or when we’re expanding a certain functionality we all know about it
levelworm@reddit
That's the natural of any work I think. You should take this as part of the (any) job. If you want to feel a bit good, ask the other teams to explain things to you too. If they refuse, you now have a legitimate reason to refuse explaining things to them too.
pborenstein@reddit
It's been like this everywhere I've worked. The first two are caused by technical debt. The third is a consequence of design decisions.
Sometimes I could get away with saying, "Oh that was a bad call Nick made ten years ago. I'll send you an email. Anyway…"
A lot of times people don't want to know the details. They want to be assured that there's a good reason and that no one is doing anything stupid.
Clavelio@reddit
Explaining things is part of the job to me and a skill I value, and something I expect from others. I’m not sure how the job would be without explaining or seeking explanations. I’d say my business domain is complex but is a good habit even for the simpler tasks. That’s how you knowledge share and build rapport when WFH.
Now, it seems your issue might be some lingering tech debt.
theyellowbrother@reddit
I have no problem having to explain. Of course, many people don't have context and that is the point of having to explain. If a service goes down, it is just common courtesy to answer the "why." Likewise, if something I use goes out, I expect a common courtesy of an answer as well.
To me, this is a nothingburger.
This has nothing to do with this industry either. Other jobs, you need to explain X,Y,Z predicament as well. Every job, if there is a question, there should be an answer.
PayLegitimate7167@reddit
Oh yes and taking hours to understand a service because it was written by cowboys