[HN Gopher] Understanding people matters more than understanding...
___________________________________________________________________
Understanding people matters more than understanding tech
Author : mooreds
Score : 99 points
Date : 2023-03-06 16:57 UTC (6 hours ago)
(HTM) web link (letterstoanewdeveloper.com)
(TXT) w3m dump (letterstoanewdeveloper.com)
| drewcoo wrote:
| The author sees technology as something mutable but doesn't
| consider humans/relationships to be that. He can either work with
| inflexibly, unalterably "good" or "bad" people (as measured by
| skill or motivation).
|
| I would hope that understanding people would mean seeing them
| with a bit more depth.
|
| (Also, he doesn't really make a case for his thesis.)
| mooreds wrote:
| Author here. Thanks for the feedback! I think that different
| people can be good or bad in different roles, organizations and
| times in their lives. Sorry if that didn't come through.
|
| This is a blog devoted to new devs, and one thing I've seen new
| devs focus on (myself included) is technology as a solution to
| all the problems. I was hoping to illustrate through this post
| that the technology matters less than people (their problems,
| their strengths).
| catiopatio wrote:
| New developers have the most to learn about technology.
| Teaching them that technology is less important than "people"
| is counterproductive and harmful unless you anticipate them
| moving to a PM, managerial, or technical sales track.
|
| Furthermore, as someone who just replaced a roof, "I did not
| care one whit about the shingle type" is frankly insane. As a
| homeowner, you are your only advocate. If _you_ don't care,
| you _will_ be taken for a ride -- either by someone actively
| malicious, or purely incompetent.
|
| Applying the point more broadly, somebody trusted in a
| position of authority must understand the technology, or
| you'll get poor technology. Developers are supposed to be
| that somebody trusted in a position of authority.
|
| I looked up your title -- "Head of Developer Relations". Of
| course people matter more than technology for you -- you're
| not a developer! People are literally your job!
| mooreds wrote:
| > Teaching them that technology is less important than
| "people" is counterproductive and harmful unless you
| anticipate them moving to a purely PM or managerial track.
|
| I intensely disagree with this statement. Of course
| technology is important, but so is (for the vast majority
| of tech jobs) working with people. I'm not talking about
| managing people, I'm talking about understanding customers
| and/or team members.
|
| Teaching new developers that they need to not only be
| concerned with the tech they are using, but how they are
| using it and to what (human focused) goals, is critical to
| people's careers.
|
| > Furthermore, as someone who just replaced a roof, "I did
| not care one whit about the shingle type" is frankly
| insane.
|
| Different strokes for different folks. I found someone
| who'd done work for others that I could ask about, checked
| his references, and trusted his advice. I don't want to
| have to become an expert on everything, I want to delegate
| that (as other comments mentioned).
|
| > Applying the point more broadly, somebody trusted in a
| position of authority must understand the technology, or
| you'll get poor technology.
|
| Absolutely agree. But you can also say:
|
| "Applying the point more broadly, somebody trusted in a
| position of authority must understand how to apply the
| technology in such a way as to benefit people, or you'll
| get poor results and unused technology."
|
| That's my core point. As technologists we have a deep
| rooted understanding of the importance of technology. But
| we (myself included) often lose sight of the actual purpose
| of the technology and its use.
| flyval wrote:
| This is trivially untrue:
|
| - median hr salary: $61k
|
| - median software developer salary: $111k
|
| Maybe what you're trying to say is that the average junior dev
| doesn't spend enough effort on people. But that's a very
| different statement than saying that understanding people is more
| valuable.
| croes wrote:
| He doesn't say valuable, he says it matters more.
|
| Didn't the pandemic show that those jobs that matter aren't
| well paid?
|
| BTW The median salary in the NBA in 2021/22 is $4,347,600, so
| NBA > Tech
| jrm4 wrote:
| This comparison is exceedingly bad. In one, you deal with
| people in a specific context, in the other you ALSO deal with
| people, just in a different context.
| commandlinefan wrote:
| If it were true, software would be replete with "people people"
| and not us introverted nerds who understand the technology but
| shy away from people. Understanding people is a useful nice-to-
| have, understanding technology is an essential requirement.
| That doesn't fit the definition of "matters more".
| notShabu wrote:
| It's like choosing between a pro photographer who only has a
| phone vs a beginner who has the latest full frame DSLR.
|
| The technology is important, but it's impotent without
| foundational understanding.
| azangru wrote:
| > If you were trying to solve any problem with software, which
| would you choose?
|
| > A unmotivated, unskilled team with the best technology...
|
| How do you get an unmotivated and unskilled team with the best
| technology? Who has picked up the technology? Who has set it up
| and got it working?
|
| What you frequently see instead is a: -
| motivated unskilled team with a mediocre technology (e.g. a bunch
| of recent bootcamp grads armed with react), or: -
| unmotivated skilled team with a mediocre technology (mature
| developers who have found themselves in a trough of
| disillusionment, a journey accelerated by business requirements
| that made them torture their initially beautiful code into an
| unrecognizable mess, and produced ever-growing resentment)
| mpweiher wrote:
| Hmm...the title contradicts the content.
|
| "A motivated, _skilled_ team with the worst technology "
|
| A _skilled_ team is one that _understands_ tech.
| nuancebydefault wrote:
| It could be that the skilled team was given crappy tools due to
| company culture
| szundi wrote:
| This is so true. My company uses an Excel-Macro like tech in the
| product that empowers our customer-care and presales people to
| actually create features themselves for the user - it is awesome.
| Not because of the tech itself, but because they understand and
| can make it so much simpler, faster and iterate 5 times with the
| customer through the first week of the pilot. For the cost of
| _asking_ a developer how long it would take to do. What do you
| think, who gets the contracts even with better margins?
| sublinear wrote:
| Maybe I missed it, but what does the author even mean when they
| say "understanding people", and what is it that devs don't
| "understand"?
|
| What I tend to see is junior devs having inappropriate levels of
| confidence (either too high or too low) and their superiors
| taking advantage of it for their own gain. Is that what we're
| talking about? Because otherwise I don't see social awkwardness,
| but fear being mistaken for "passion".
|
| The majority of the time a dev wants to talk technical details is
| because they want validation or expect a certain level of input
| from the rest of the team, especially leadership. It's perfectly
| reasonable for such a person to become frustrated when that
| doesn't happen. This isn't a lack of understanding from the dev,
| but maybe a lack of communication and a few naive assumptions on
| their part.
| mobjack wrote:
| It is understanding that leadership doesn't care about the
| technical details. Devs are expected to figure out these
| details on their own.
|
| Instead try to understand what others really care about and
| frame the discussions around that.
| Loquebantur wrote:
| Autism spectrum disorders are characterized by challenges in
| social interaction, verbal and nonverbal communication, and often
| the presence of repetitive behaviors and restricted interests,
| according to Wikipedia.
|
| Remarkably, understanding people does matter to a degree
| _dependent on the social context_.
|
| Explaining _how to_ more easily understand people might have a
| greater benefit than berating them about their shortcomings. And
| would show social competence.
| mooreds wrote:
| > Explaining how to more easily understand people might have a
| greater benefit than berating them about their shortcomings.
| And would show social competence.
|
| Author here. That's a great idea. Maybe I'll tackle it in the
| future. I do have a post about how to engage with people when
| you don't know them that uses a technique I've found helpful:
| https://letterstoanewdeveloper.com/2019/02/25/use-a-conversa...
|
| Sorry if this came off as berating people. I have been the
| person overly focused on tech in the past and wanted to make it
| clear to readers that, at the end of the day, the people the
| tech is helping really matter. Appreciate the feedback.
| jasondigitized wrote:
| The hardest programming language to grok is human language.
| reidjs wrote:
| English is not a programming language, but it is the language
| of most programming language's documentation and syntax.
| karmakaze wrote:
| > Or, to be more precise, in a "jobs to be done" sense, we wanted
| shelter from the rain and snow and protection for our belongings
| from anything coming from overhead. We wanted it to be durable,
| easy to repair, and hole-free.
|
| > I did not care one whit about the shingle type.
|
| The way this post is posed is very misleading and
| counterproductive.
|
| In this example, you very much do care about shingle type, it's
| what makes all those things you care about an actuality. What you
| don't care about is learning about it and defer the expertise. In
| this sense tech certainly matters to developers as that's what's
| being deferred to them.
| aero142 wrote:
| Exactly. Good products and companies are abstractions that
| allow a homeowner to not have to learn about shingles. The
| roofer should definitely understand what shingles are going to
| provide rain and show protection in the customer's environment.
| The roofer doesn't have to know everything about the chemistry
| and material that is in the shingle though. That abstraction is
| provided by the shingle manufacturer. They need an expert that
| knows about adhesives and gravel and how many years of sun
| exposure they can handle.
|
| I think this article is bad because it empowers a lot of people
| to dismiss expertise as unimportant rather than knowing where
| that expert is. I think the important thing for companies is to
| have clear understanding of what abstraction your product
| provides your customers, and which portion of creating that
| product are you the expert in. You should then delegate the
| portions that you don't want to be the expert in, and make sure
| you hire and retain the experts that DO know about that. "The
| most important thing is understanding the customer." is bad
| advice on its own. "The customer wants a flying car." Well, do
| you have an expert in making cars fly? If not then
| understanding the customer isn't that valuable.
| tensor wrote:
| Did you read the same article I did? It explicitly said
| expertise is more important than technology choice. From the
| article:
|
| "Think about it this way. If you were trying to solve any
| problem with software, which would you choose?
|
| A unmotivated, unskilled team with the best technology
|
| A motivated, skilled team with the worst technology"
|
| This is saying that skilled people with worse tools will
| still create a better product then people with the best tools
| but no skills. In the roofing analogy it would be someone who
| uses the best shingles and hammers and other tools, but
| screws up the installation and the roof leaks anyways, vs
| someone with less good shingles but installs things so well
| that its still a good roof.
|
| I think this lesson is extremely relevant in technology. For
| example, there are some developers who are more interested in
| the technology choice than solving the user problem well, and
| the result is a long development time with subpar user
| experience. On the other hand I've used excellent services,
| stable, fast, good UI, built with tech that I'd never
| personally choose. I can only imagine that those teams have
| great developers despite having to work with tech that isn't
| as good.
| mips_avatar wrote:
| There's a common complaint among developers that they wished
| their PMs were more technical. When I started as a PM I
| incorrectly took this feedback to heart and leaned into my
| technical strengths. This was a mistake, as much less technical
| PMs who focused on people had much more success than me. I was
| exhausting myself understanding the technical details of the
| projects and aligning execution, when in some cases I was missing
| out on what the customer really wanted. It's great to be good at
| everything, but I'm not going to let myself get distracted from
| listening to what customers/partners have to say. And if you're a
| developer who thinks your PM isn't technical enough, you may not
| be correctly appreciating what they're bringing to the table.
| dgb23 wrote:
| The best PMs involve devs early and trust them to make
| technical decisions - including saying "no".
|
| A PM who cannot do this _has_ to be on a higher technical
| level. That's why we sometimes think we want that. But what we
| really want is trust and agency.
| HeyLaughingBoy wrote:
| > But what we really want is trust and agency.
|
| Yup. One of the best PMs I've had the pleasure of working
| with secretly thought we were doomed, but she still gave us
| what we asked for and supported us all the way to success.
| When people trust you like that, you do all you can to not
| let them down.
| ldehaan wrote:
| [dead]
| mattgreenrocks wrote:
| I get what the author is saying, but it still feels like it
| devalues tech skills.
|
| There's some weird vibe the past few years where programming is
| mostly seen as a stepping stone to get to the things that really
| matter, be that Creating Business Value, funding, more money,
| career success, VC attention, GitHub stars. (Note how they're all
| extrinsic measures.) It's like caring about the act of
| programming is seen as vulgar.
|
| The trope of siloed programmers is real, but the rest of us
| continue to suffer unduly for the fact that a few devs choose to
| remain unengaged with the larger context of their work.
| tristor wrote:
| I get what you're saying, and I've observed this too. I think
| there is a divide that few people consciously point out, which
| is there is a difference between programming as an artform and
| programming as a career. From a career perspective, all of
| those things matter, as an artform they're likely not important
| at all. It's not that caring about programming is vulgar, it's
| that most people are focused on career so the majority of the
| conversation is optimized around the metrics that matter for
| careerist goals.
| tstrimple wrote:
| If you value tech skills and want to get certain standards
| implemented, you need to be able to navigate the people side of
| things to get agreement. If you strongly believe a certain tool
| should be used to solve a particular problem, your success in
| getting that tool selected is directly proportional to your
| relationships and ability to navigate in the circle of folk who
| can get that accomplished. If you want your new architecture
| implemented, you have to know how to sell it up the chain of
| command. It's not that the tech doesn't matter. Far from it.
| But those ideas have to be sold in a context that other
| stakeholders can understand. If you want to have that level of
| influence on your career so that you're not suffering unduly,
| you need to put yourself into a position to influence
| organizational level decisions. Otherwise the decisions will be
| made by the people who can navigate those circles regardless of
| their technical ability.
___________________________________________________________________
(page generated 2023-03-06 23:01 UTC)