3 ms·

Similarly, many non-programmers can do tasks that some programmers must hire a professional for (like repair drywall, install a ceiling fan, basic car maintenan

Similarly, many non-programmers can do tasks that some programmers must hire a professional for (like repair drywall, install a ceiling fan, basic car maintenance, etc). Empathy is one of those skills that is as, or more, valuable than any particular programming language.

pas 4y ago
Empathy, but also boundaries. 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.
- bdcravens 4y ago
  For sure, that's true of all relationships in life. I'm sure abuse of professional's time unrelated to the task being paid for is common in many fields. "Sir, your total is... But hey what about...."
agloe_dreams 4y ago
This is probably one of the most on-point comments on this. The Author in the blog seems...rather insufferable...to the point that they know it. 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.

pas 4y ago

Empathy, but also boundaries. 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.

bdcravens 4y ago
For sure, that's true of all relationships in life. I'm sure abuse of professional's time unrelated to the task being paid for is common in many fields. "Sir, your total is... But hey what about...."

agloe_dreams 4y ago

This is probably one of the most on-point comments on this. The Author in the blog seems...rather insufferable...to the point that they know it. 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.