9 ms·

Important non-programming skills for programmers

91 points by IncRnd 6y ago

Brajeshwar 6y ago
On a similar topic of programmers needing to know non-programming skills, I'd suggest the book, "How To Be A Programmer"[1] by Robert Read. I read it about five years ago, and I liked it. Talks about the essential technical skills -- managerial skills to manage a team of programmers, ethics of working as a programmer, and being part of a team. I remember loving the topics on how to talk to non-programmers and deal with difficult people. 1. https://www.amazon.com/How-Be-Programmer-Robert-Read-ebook/dp/B00PP5FA00/ https://www.amazon.com/How-Be-Programmer-Robert-Read-ebook/d...
- abatilo 6y ago
  I loved reading through this even as someone with a chunk of years in the industry. It puts pen to paper on a lot of topics that we usually deem "obvious". You can read it for free online here: https://github.com/braydie/HowToBeAProgrammer https://github.com/braydie/HowToBeAProgrammer
  - mangamadaiyan 6y ago
    One thing that this book mentions (and which many people swear by) is "self documenting code". In my experience, I've found that: (1) good "self documenting code" is typically written by programmers who care enough about documentation to write at least a high-level description of what their code is trying to achieve, what problems it is trying to solve. (2) programmers who swear by "self documenting code" usually write code that is anything but self-documenting. Their output is usually so gloriously complex that nobody apart from them can easily read and understand their code.
MaxBarraclough 6y ago
Not a single mention of the word requirements. Software developers generally have two jobs: to figure out what to make, and to make it. They have to build the right thing, and to build the thing right. I don't put much stock in an article like this that doesn't even mention requirements engineering.
- MattGaiser 6y ago
  Whether this is part of your job probably depends on how your team is structured. I have yet to be on a team where the part about building the right thing was the engineer's role. There was a product owner or project manager for those decisions.
  - onion2k 6y ago
    There's two sides to requirements. There's the functional "what is required to fulfil the user's need?" part which is very much in the product owner's domain, but there's also the non-functional requirements like "The feature must not compromise security" and "Performance metrics can't fall below X". Those parts are defined by the engineering team. Building the right thing is product, building it the right way is engineering, and they both feed in to defining the requirements for a feature.
    - Natsu 6y ago
      It seems to me like you basically need a programmer who has experience doing the actual job to specify what's needed. I've seen things get morphed from what the users need to what management wants and end up badly misaligned. You're also right that there's a gulf between what users ask for and what can be sensibly implemented due to security, etc. considerations. E.G. wanting SSL to just work and ignore all cert changes magically just isn't ever going to be secure.
  - temac 6y ago
    You can, and should, write requirements and in more general all kind of specifications / high level pictures / architecture diagrams, for when you won't be around anymore, or even just for your future self. Maybe even more for your future self than for when you won't be around anymore, given that will impact you if you don't even if you are selfish, whereas you could just quit and not care anymore about remaining or new people. Of course you should not be selfish, but even if you are, write requirements.
- marcosdumay 6y ago
  Hum... Empathy, problem solving, communication, creativity, patience, humility and self confidence... What else is lacking for requirement gathering? I can't think about anything else. In fact the article is so generic it could fit any job. It basically says: be a well rounded person.
XargonEnder 6y ago
In my career the thing I was hurting most from missing the first decade was negotiation skills. Learning a few simple ones has changed my life.
- yboris 6y ago
  An excellent book on the subject is Getting to Yes: Negotiating Agreement Without Giving In Had specific advice with examples. I think it's been helping me all my life. It is based on the work of the Harvard Negotiation Project. https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Without/dp/0143118757/ref=sr_1_1?dchild=1&keywords=getting+to+yes&qid=1600957605&sr=8-1 https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Wit...
- swader999 6y ago
  Negotiating is huge. There are likely several ways to achieve a feature's goal. As a programmer you have to negotiate the solution with the customer or product owner and even the rest of your team. It allows you to pursue solutions that can save time and result in better architecture. Be sure to ask and understand why a feature is needed. Knowing the why let's you shape the what.
NoWuckersMate 6y ago
Yet another "It's 2020, buffer overflows don't matter any more because something, something, racism, sexism, diversity and inclusion."
- kuhzaam 6y ago
  How did you come to that conclusion? Do you not consider preventing buffer overflows to be a programming skill?
illuminated 6y ago
I'd add two more: - estimates: ability to balance between showing off when estimating the skills and technologies you know well and then underestimating the process ahead and overestimating the unfamiliar territories. - fast typing: I could never relate to developers as senior, no matter the years of experience, if I see them shooting the keyboard with two or four fingers. Despite my subjective position on this, fast typing "releases" your brain to think only about the problem you're solving or achieving the goal you have without dialing 911 to "find that letter". EDIT: I've used a wrong phrase in my second point. I meant "touch typing" instead of "fast typing".
- jmpman 6y ago
  Early in my career, I also thought fast typing was important. Then I worked with a severely disabled engineer, who could manage to type at probably 3 words per minute. Even at this snail’s pace, he could produce as much as anyone else on the team, and his work was of a higher quality.
  - scarface74 6y ago
    Are you sure he produced as much in the same amount of time and didn’t work longer outside of office hours? No judgement, I also have a disability that only allows me to type with one hand.
    - mistersquid 6y ago
      > Are you sure he produced as much in the same amount of time and didn’t work longer outside of office hours? I wonder if due to reduced typing speed the developer in question had a higher ratio of kept code to deleted code. Someone only able to type 3 words per minute may have developed patterns of thought and deliberation that maximize those 3 words rather than follow development habits of faster typists that might be prone to generate code which never sees the light of day. I type quickly and have no qualms about deleting entire stanzas of code and rewriting them when things don't work out. If I could only type 3 words per minute, my approach to writing code would radically change, perhaps for the better.
nikanj 6y ago
Based on the people I've seen during my career: The skill to stop procrastinating and start programming. Being able to pick up tasks reliably is way more important than technical bravado.
- pif 6y ago
  > Being able to pick up tasks reliably Based on the people I met, this usually comes with a great talent in completing tasks within the imposed delay, by putting in the least amount of effort as possible (especially with regards to understand the task), providing a solution that is only acceptable at a very shallow level, and forgetting everything about it as soon as possible. Basically, the developers who are most appreciated by box thicking managers are usually the culprits of overall project slowness or plain failure.
4cao 6y ago
Since this is in huge part about ethics, not skills as such, there was a related submission recently: the ACM Code of Ethics and Professional Conduct. It didn't gain much traction (perhaps it was discussed earlier) but the document is very comprehensive and well worth reading through: https://www.acm.org/code-of-ethics https://www.acm.org/code-of-ethics Link to HN submission: https://news.ycombinator.com/item?id=24533181 https://news.ycombinator.com/item?id=24533181
ionforce 6y ago
I want to see "The Most Important Programming Skills for Non-Programmers"
- onion2k 6y ago
  If I made a list the first skill would be 'Explaining the bug you're seeing without saying "It just doesn't work."'
  - kps 6y ago
    0. What was your goal? 1. What did you do? (Report the steps exactly.) 2. What did you expect? 3. What happened instead? (Report the messages exactly.) 4. What are your wild speculations about the causes and solutions?
- kspacewalk2 6y ago
  Documentation reading comprehension.
- mariodiana 6y ago
  The most important "programming" skill for non-programmers is simply knowing when a programmer could automate some tedious, error-prone task that the non-programmer spends a lot of time doing. I remember when I worked second-level support. Most of us had no programming ability. I did. A coworker used to spend hours—when he had many other things he should have been doing—on some ridiculous task that a bit of text processing could have automated. When I found that out, I wrote him a script and told him, "Be on the lookout for things like this. Don't ever waste your time with something like this again. Ask someone who knows how to program if there is something that could be done." I'm guessing there is a lot of that out there.
- 908B64B197 6y ago
  6.0001 [0] Seriously. One simple intro to CS class will allow a non-programmer to more easily differentiate between what can be done easily and what can't [1]. [0] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-0001-introduction-to-computer-science-and-programming-in-python-fall-2016/ https://ocw.mit.edu/courses/electrical-engineering-and-compu... [1] https://xkcd.com/1425/ https://xkcd.com/1425/
bitL 6y ago
"Be likable" is the most important skill. Everywhere.
- zigzaggy 6y ago
  As my college professor told me many years ago, "people do business with you because they LIKE you more than any other reason. Continue being likeable and you will be successful." I will say that this is true more for entrepreneurs that for Corporate America. I had many successful years as an independent consultant where being likeable was more profitable than being most other things. But I learned when I took the corporate job that it really seems like assholes get ahead more than anyone else. Or as I say, "the biggest bully wins." (Unfortunately, I am not a very good bully.)
darkhorse13 6y ago
Writing documentation for your code/library/framework/project should be another one of these skills. I have written a lot of documentation for a project [1] recently, and it has made me realize the importance of this skill. It is often overlooked by programmers, myself included, as before this project, I never wrote proper documentation. Sure, you can get technical writers to do it for you if you have a big team, but a lot of small, open source projects suffer from the lack of proper documentation. [1] https://www.gethalfmoon.com/docs/introduction/ https://www.gethalfmoon.com/docs/introduction/
- robocop556 6y ago
  I agree. Out of curiosity, what was this project?
  - darkhorse13 6y ago
    I edited the parent comment with a link to the docs.
- rawburt 6y ago
  Halfmoon look real nice, as does the documentation. Kudos
- agumonkey 6y ago
  on a similar note I've always been shocked by linux distros wikis. you can have: - near nothing, good luck - debian, ultra structured, .. hard to digest / boring - gentoo / arch, barely structured, just enough content to get the gist, yet precise, and a lot more tips for funsies. this is an art
  - cashewchoo 6y ago
    fwiw I find the arch approach the best tradeoff of practical and useful. Usually when I go to a distro wiki, I'm not really going there to learn in-depth what it is. I'm going there because I have a problem or a question. So having low-structure (easy to contribute to), high-signal (too much low-interest clutter info tends to contribute to documentation decay) tidbits seems to work out well. I particularly like that if I have an issue, and I figure it out, I can just pop a quick line in there. h4:"Issues snafucating while running nvidia proprietary driver". Body: "you get this error message. <snip>. This is due to <snip>. Run this command to fix it." And it's already at the quality that people expect.
anm89 6y ago
Strongly agree with empathy at number one. After years in consulting I would say most project failures I see are failures of empathy.
- darkhorse13 6y ago
  >most project failures I see are failures of empathy That is quite the statement. Would you provide some examples of situations that made you come to this conclusion?
  - watwut 6y ago
    Lack of empathy toward user/client made him replace us. Real story. Lack of empathy toward programmers led to imppssible schedule. Real story. Lack of empathy between team members who were supposed to lead cause spectacular dysfunction of team I am in right now.
  - anm89 6y ago
    Very few software projects in my experience fail because they were too technically difficult and/or that the people involved were incapable of working through some technical problem. When I say failures of empathy, I'm not even saying that that was the failure of a single person to empathize, but that at the end of the day the collective parties could not understand enough about what all the other parties needed to create an actionable plan and put the people in places to do it. This can be: A software developer failing to empathize with someone in the c suite and understanding the direction the project needed to go in to be considered a successful project The c suite failing to empathize with the development team in terms of understanding what skills and abilities they are offering and what resources and direction needed to be given to them to properly convey their goals Failures of the dev team or executives to empathize with their users in order to create a thing that is actually wanted in a way that will actually be used. Failures of technical teams to empathize with budgetary and business concerns and the reverse. All sorts of other failures between people in the middle to empathize in terms of being able to understand priorities and goals and allocate energy accordingly and understand the hierarchy among those goals. Failures within a dev team to empathize with each other leading to all sorts of various breakdowns. People are generally not very good at mapping out complex webs of incentives and goals and the ability to empathize is what underlies that in my opinion. I've sat in on an absurd number of projects where whatever silly stuff they thought was their roadblock was so far away from what was meaningful to the higher level goals of the project that they were absolutely doomed from the start. You can have projects like that go on for years in enterprises where they never even get on a viable path to creating anything productive. It generally ends up as some sort of battleground for internal politics in that case. At the end of the day, the ability to think in terms of hierarchical goals and incentives and escape the concerns of your personal silo is a majority of the time what could avoid this in my opinion.
baron816 6y ago
I see a lot of these that basically say the same thing. I think someone should write a blog post about the non-programming skills you need to be a staff/principal engineer.
Bodhisattya 6y ago
Maybe I am nitpicking, but which of these skills would not be relevant for a non-programmer? Or for that matter, which of these skills would not matter or be important to a regular, non-coding person in general?
- themarkn 6y ago
  They are definitely good general human skills. The article highlights the relevance in programming because it’s easy to assume that strong technical skills are enough and that this baseline “dealing with humans and solving problems” toolset is not needed as much. Whereas “the job” you have as a programmer requires these baseline transferable skills in order for you to be effective, even if you’re super good at whatever technical skillset.
  - Bodhisattya 6y ago
    Agreed. It is easy to forget the human elements of your job. More so when you are very technically focussed.
asciimov 6y ago
I was hoping one of these would cover personal care and hygiene. It seems that taking care of oneself is a problem for at least one person on every team. Either they don't regularly bathe, wash their clothes, or they smell (either due to smoking, drinking, or body odor). In my experience half of these people are suffering from mental health problems such as depression.
- scanny 6y ago
  What sort of ratio do you think you have experienced of one group to another? I have never encountered anyone like that here in Australia during my time as a dev. It must be <5% of people surely?
mesaframe 6y ago
And the ability to sell themselves. Anyone got a good read on how can one sell oneself?
- IncRnd 6y ago
  https://news.ycombinator.com/item?id=24582151 https://news.ycombinator.com/item?id=24582151 Just posted!

91 points by IncRnd 6y ago

On a similar topic of programmers needing to know non-programming skills, I'd suggest the book, "How To Be A Programmer"[1] by Robert Read. I read it about five years ago, and I liked it. Talks about the essential technical skills -- managerial skills to manage a team of programmers, ethics of working as a programmer, and being part of a team. I remember loving the topics on how to talk to non-programmers and deal with difficult people. 1. https://www.amazon.com/How-Be-Programmer-Robert-Read-ebook/dp/B00PP5FA00/ https://www.amazon.com/How-Be-Programmer-Robert-Read-ebook/d...

abatilo 6y ago
I loved reading through this even as someone with a chunk of years in the industry. It puts pen to paper on a lot of topics that we usually deem "obvious". You can read it for free online here: https://github.com/braydie/HowToBeAProgrammer https://github.com/braydie/HowToBeAProgrammer
- mangamadaiyan 6y ago
  One thing that this book mentions (and which many people swear by) is "self documenting code". In my experience, I've found that: (1) good "self documenting code" is typically written by programmers who care enough about documentation to write at least a high-level description of what their code is trying to achieve, what problems it is trying to solve. (2) programmers who swear by "self documenting code" usually write code that is anything but self-documenting. Their output is usually so gloriously complex that nobody apart from them can easily read and understand their code.

MaxBarraclough 6y ago

Not a single mention of the word requirements. Software developers generally have two jobs: to figure out what to make, and to make it. They have to build the right thing, and to build the thing right. I don't put much stock in an article like this that doesn't even mention requirements engineering.

MattGaiser 6y ago
Whether this is part of your job probably depends on how your team is structured. I have yet to be on a team where the part about building the right thing was the engineer's role. There was a product owner or project manager for those decisions.
- onion2k 6y ago
  There's two sides to requirements. There's the functional "what is required to fulfil the user's need?" part which is very much in the product owner's domain, but there's also the non-functional requirements like "The feature must not compromise security" and "Performance metrics can't fall below X". Those parts are defined by the engineering team. Building the right thing is product, building it the right way is engineering, and they both feed in to defining the requirements for a feature.
  - Natsu 6y ago
    It seems to me like you basically need a programmer who has experience doing the actual job to specify what's needed. I've seen things get morphed from what the users need to what management wants and end up badly misaligned. You're also right that there's a gulf between what users ask for and what can be sensibly implemented due to security, etc. considerations. E.G. wanting SSL to just work and ignore all cert changes magically just isn't ever going to be secure.
- temac 6y ago
  You can, and should, write requirements and in more general all kind of specifications / high level pictures / architecture diagrams, for when you won't be around anymore, or even just for your future self. Maybe even more for your future self than for when you won't be around anymore, given that will impact you if you don't even if you are selfish, whereas you could just quit and not care anymore about remaining or new people. Of course you should not be selfish, but even if you are, write requirements.
marcosdumay 6y ago
Hum... Empathy, problem solving, communication, creativity, patience, humility and self confidence... What else is lacking for requirement gathering? I can't think about anything else. In fact the article is so generic it could fit any job. It basically says: be a well rounded person.

XargonEnder 6y ago

In my career the thing I was hurting most from missing the first decade was negotiation skills. Learning a few simple ones has changed my life.

yboris 6y ago
An excellent book on the subject is Getting to Yes: Negotiating Agreement Without Giving In Had specific advice with examples. I think it's been helping me all my life. It is based on the work of the Harvard Negotiation Project. https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Without/dp/0143118757/ref=sr_1_1?dchild=1&keywords=getting+to+yes&qid=1600957605&sr=8-1 https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Wit...
swader999 6y ago
Negotiating is huge. There are likely several ways to achieve a feature's goal. As a programmer you have to negotiate the solution with the customer or product owner and even the rest of your team. It allows you to pursue solutions that can save time and result in better architecture. Be sure to ask and understand why a feature is needed. Knowing the why let's you shape the what.

NoWuckersMate 6y ago

Yet another "It's 2020, buffer overflows don't matter any more because something, something, racism, sexism, diversity and inclusion."

kuhzaam 6y ago
How did you come to that conclusion? Do you not consider preventing buffer overflows to be a programming skill?

illuminated 6y ago

I'd add two more: - estimates: ability to balance between showing off when estimating the skills and technologies you know well and then underestimating the process ahead and overestimating the unfamiliar territories. - fast typing: I could never relate to developers as senior, no matter the years of experience, if I see them shooting the keyboard with two or four fingers. Despite my subjective position on this, fast typing "releases" your brain to think only about the problem you're solving or achieving the goal you have without dialing 911 to "find that letter". EDIT: I've used a wrong phrase in my second point. I meant "touch typing" instead of "fast typing".

jmpman 6y ago
Early in my career, I also thought fast typing was important. Then I worked with a severely disabled engineer, who could manage to type at probably 3 words per minute. Even at this snail’s pace, he could produce as much as anyone else on the team, and his work was of a higher quality.
- scarface74 6y ago
  Are you sure he produced as much in the same amount of time and didn’t work longer outside of office hours? No judgement, I also have a disability that only allows me to type with one hand.
  - mistersquid 6y ago
    > Are you sure he produced as much in the same amount of time and didn’t work longer outside of office hours? I wonder if due to reduced typing speed the developer in question had a higher ratio of kept code to deleted code. Someone only able to type 3 words per minute may have developed patterns of thought and deliberation that maximize those 3 words rather than follow development habits of faster typists that might be prone to generate code which never sees the light of day. I type quickly and have no qualms about deleting entire stanzas of code and rewriting them when things don't work out. If I could only type 3 words per minute, my approach to writing code would radically change, perhaps for the better.

nikanj 6y ago

Based on the people I've seen during my career: The skill to stop procrastinating and start programming. Being able to pick up tasks reliably is way more important than technical bravado.

pif 6y ago
> Being able to pick up tasks reliably Based on the people I met, this usually comes with a great talent in completing tasks within the imposed delay, by putting in the least amount of effort as possible (especially with regards to understand the task), providing a solution that is only acceptable at a very shallow level, and forgetting everything about it as soon as possible. Basically, the developers who are most appreciated by box thicking managers are usually the culprits of overall project slowness or plain failure.

4cao 6y ago

Since this is in huge part about ethics, not skills as such, there was a related submission recently: the ACM Code of Ethics and Professional Conduct. It didn't gain much traction (perhaps it was discussed earlier) but the document is very comprehensive and well worth reading through: https://www.acm.org/code-of-ethics https://www.acm.org/code-of-ethics Link to HN submission: https://news.ycombinator.com/item?id=24533181 https://news.ycombinator.com/item?id=24533181

ionforce 6y ago

I want to see "The Most Important Programming Skills for Non-Programmers"

onion2k 6y ago
If I made a list the first skill would be 'Explaining the bug you're seeing without saying "It just doesn't work."'
- kps 6y ago
  0. What was your goal? 1. What did you do? (Report the steps exactly.) 2. What did you expect? 3. What happened instead? (Report the messages exactly.) 4. What are your wild speculations about the causes and solutions?
kspacewalk2 6y ago
Documentation reading comprehension.
mariodiana 6y ago
The most important "programming" skill for non-programmers is simply knowing when a programmer could automate some tedious, error-prone task that the non-programmer spends a lot of time doing. I remember when I worked second-level support. Most of us had no programming ability. I did. A coworker used to spend hours—when he had many other things he should have been doing—on some ridiculous task that a bit of text processing could have automated. When I found that out, I wrote him a script and told him, "Be on the lookout for things like this. Don't ever waste your time with something like this again. Ask someone who knows how to program if there is something that could be done." I'm guessing there is a lot of that out there.
908B64B197 6y ago
6.0001 [0] Seriously. One simple intro to CS class will allow a non-programmer to more easily differentiate between what can be done easily and what can't [1]. [0] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-0001-introduction-to-computer-science-and-programming-in-python-fall-2016/ https://ocw.mit.edu/courses/electrical-engineering-and-compu... [1] https://xkcd.com/1425/ https://xkcd.com/1425/

bitL 6y ago

"Be likable" is the most important skill. Everywhere.

zigzaggy 6y ago
As my college professor told me many years ago, "people do business with you because they LIKE you more than any other reason. Continue being likeable and you will be successful." I will say that this is true more for entrepreneurs that for Corporate America. I had many successful years as an independent consultant where being likeable was more profitable than being most other things. But I learned when I took the corporate job that it really seems like assholes get ahead more than anyone else. Or as I say, "the biggest bully wins." (Unfortunately, I am not a very good bully.)

darkhorse13 6y ago

Writing documentation for your code/library/framework/project should be another one of these skills. I have written a lot of documentation for a project [1] recently, and it has made me realize the importance of this skill. It is often overlooked by programmers, myself included, as before this project, I never wrote proper documentation. Sure, you can get technical writers to do it for you if you have a big team, but a lot of small, open source projects suffer from the lack of proper documentation. [1] https://www.gethalfmoon.com/docs/introduction/ https://www.gethalfmoon.com/docs/introduction/

robocop556 6y ago
I agree. Out of curiosity, what was this project?
- darkhorse13 6y ago
  I edited the parent comment with a link to the docs.
rawburt 6y ago
Halfmoon look real nice, as does the documentation. Kudos
agumonkey 6y ago
on a similar note I've always been shocked by linux distros wikis. you can have: - near nothing, good luck - debian, ultra structured, .. hard to digest / boring - gentoo / arch, barely structured, just enough content to get the gist, yet precise, and a lot more tips for funsies. this is an art
- cashewchoo 6y ago
  fwiw I find the arch approach the best tradeoff of practical and useful. Usually when I go to a distro wiki, I'm not really going there to learn in-depth what it is. I'm going there because I have a problem or a question. So having low-structure (easy to contribute to), high-signal (too much low-interest clutter info tends to contribute to documentation decay) tidbits seems to work out well. I particularly like that if I have an issue, and I figure it out, I can just pop a quick line in there. h4:"Issues snafucating while running nvidia proprietary driver". Body: "you get this error message. <snip>. This is due to <snip>. Run this command to fix it." And it's already at the quality that people expect.

anm89 6y ago

Strongly agree with empathy at number one. After years in consulting I would say most project failures I see are failures of empathy.

darkhorse13 6y ago
>most project failures I see are failures of empathy That is quite the statement. Would you provide some examples of situations that made you come to this conclusion?
- watwut 6y ago
  Lack of empathy toward user/client made him replace us. Real story. Lack of empathy toward programmers led to imppssible schedule. Real story. Lack of empathy between team members who were supposed to lead cause spectacular dysfunction of team I am in right now.
- anm89 6y ago
  Very few software projects in my experience fail because they were too technically difficult and/or that the people involved were incapable of working through some technical problem. When I say failures of empathy, I'm not even saying that that was the failure of a single person to empathize, but that at the end of the day the collective parties could not understand enough about what all the other parties needed to create an actionable plan and put the people in places to do it. This can be: A software developer failing to empathize with someone in the c suite and understanding the direction the project needed to go in to be considered a successful project The c suite failing to empathize with the development team in terms of understanding what skills and abilities they are offering and what resources and direction needed to be given to them to properly convey their goals Failures of the dev team or executives to empathize with their users in order to create a thing that is actually wanted in a way that will actually be used. Failures of technical teams to empathize with budgetary and business concerns and the reverse. All sorts of other failures between people in the middle to empathize in terms of being able to understand priorities and goals and allocate energy accordingly and understand the hierarchy among those goals. Failures within a dev team to empathize with each other leading to all sorts of various breakdowns. People are generally not very good at mapping out complex webs of incentives and goals and the ability to empathize is what underlies that in my opinion. I've sat in on an absurd number of projects where whatever silly stuff they thought was their roadblock was so far away from what was meaningful to the higher level goals of the project that they were absolutely doomed from the start. You can have projects like that go on for years in enterprises where they never even get on a viable path to creating anything productive. It generally ends up as some sort of battleground for internal politics in that case. At the end of the day, the ability to think in terms of hierarchical goals and incentives and escape the concerns of your personal silo is a majority of the time what could avoid this in my opinion.

baron816 6y ago

I see a lot of these that basically say the same thing. I think someone should write a blog post about the non-programming skills you need to be a staff/principal engineer.

Bodhisattya 6y ago

Maybe I am nitpicking, but which of these skills would not be relevant for a non-programmer? Or for that matter, which of these skills would not matter or be important to a regular, non-coding person in general?

themarkn 6y ago
They are definitely good general human skills. The article highlights the relevance in programming because it’s easy to assume that strong technical skills are enough and that this baseline “dealing with humans and solving problems” toolset is not needed as much. Whereas “the job” you have as a programmer requires these baseline transferable skills in order for you to be effective, even if you’re super good at whatever technical skillset.
- Bodhisattya 6y ago
  Agreed. It is easy to forget the human elements of your job. More so when you are very technically focussed.

asciimov 6y ago

I was hoping one of these would cover personal care and hygiene. It seems that taking care of oneself is a problem for at least one person on every team. Either they don't regularly bathe, wash their clothes, or they smell (either due to smoking, drinking, or body odor). In my experience half of these people are suffering from mental health problems such as depression.

scanny 6y ago
What sort of ratio do you think you have experienced of one group to another? I have never encountered anyone like that here in Australia during my time as a dev. It must be <5% of people surely?

mesaframe 6y ago

And the ability to sell themselves. Anyone got a good read on how can one sell oneself?

IncRnd 6y ago
https://news.ycombinator.com/item?id=24582151 https://news.ycombinator.com/item?id=24582151 Just posted!