6 ms·

The Most Important Non-Programming Skills for Programmers

45 points by fagnerbrack 8y ago

kartan 8y ago
That are good characteristics for anyone. Be a decent human also while at your job your life and other's life are going to be better. (And probably you also will get better products and be economically successful as a side-effect).
wawhal 8y ago
I don't know if 'Discipline' was missed out, or discipline is a quality inferred to be required for every field out there. Personally, discipline and honesty towards the code have been the most helpful soft-skill challenges in my programming career.
- adamfaliq 8y ago
  Can you explain what you mean by 'discipline', especially in software engineering context? Is it doing test rigorously, code reviews etc? Or simple commited to deadlines and get things done?
  - watwut 8y ago
    Not op but: do skip useful parts of work you don't feel like doing. Do boring or annoying parts of work even when it is tempting. Do not skip test just because you don't feel like. Do clean up code after yourself even if it already works. Write documentation, ask questions even if you would rather code, etc. Finish tasks before moving to shiny new ones. When you know about bug, dont ignore it and at least put it into tracker. Send that mail to administration/management/customer, fill taxes, don't leave mess in common kitchen. If you promised you will do tasks in some order (e.g. prioritized them) follow what you said. Don't come to work sleep deprived too often, eat properly, exercise. It may also mean taking time for socialization/family/help friends even if you would prefer to code right now. Effectively, it means same thing as discipline in any other context.
leowoo91 8y ago
Communication is key I agree but technical managers are more vital for making connection to stakeholders.
Fargren 8y ago
I'm going to go on a bit of a tangent. There's one skill not mentioned here, but I think is the most valuable skill a programmer can learn, and many people take for granted. Know English. "Communication" here is related to that, but it's not the same. A lot programming resources are not accessible at all without passable English, and without very good English, there's a lot of them that will go over your head and you won't even know why. That's without even getting into the advantages that come from talking the Lingua Franca of programmers, and the collaboration opportunities that brings.
wsc981 8y ago
Some people have mentioned communication and I guess a very important subcategory is negotiation skills. I feel most devs are bad negotiators especially when thinking about hourly rates and the like. And (in my view) earning a good income is very important, so you can retire early for example. Or perhaps work less hours (might be difficult in the US, but in The Netherlands a lot of people work 4 days a week, for example).
oldboyFX 8y ago
More people should focus on the following, in my humble opinion: - be consistent and reliable - learn about your company's business goals - focus on delivering value for the business instead of writing "clean/bespoke/artisan" code - don't get emotionally attached to your own code or a piece of technology - learn how to educate other stake-holders - learn how to negotiate with non-technical folks without being annoying and overstepping your boundaries (this can be difficult)
- iliaznk 8y ago
  Just wondering, in terms of value for the business, doesn't clean code always deliver a higher value as opposed to, say, messy code? Being easier to maintain and debug, and also likely to contain less bugs thus being more reliable, do those qualities provide value by themselves? I realise that, from a business' point of view, how fast something is done may be more valuable than how clean, but at the end of the day a "faster" code can eventually take longer to reach a production-grade reliability... Isn't that true?
  - btschaegg 8y ago
    Edit: Obviously, I'm not GP, but here's my take on this. > doesn't clean code always deliver a higher value as opposed to, say, messy code? I'll agree with you there, but I'm under the impression that the phrase "clean code" is somewhat too ambiguous. Coding style per se is very subjective anyway, so obsessing over it propably is not a good thing in most cases, yes. But if the "quick and dirty" approach also influences the architecture of what you're developing (i.e. it also affects other code) I'd very well argue that taking a stand against it is a good thing to do. On a similar note: I find the notion of "technical debt" to be quite useful in a lot of ways: By taking the short path, you'll be forced to make up for it at a later date, be it through slower development, a lack of reliability or the necessity to clean up the "hacks". Where the metaphor breaks down (and seems to be contraproductive) is that it leads many business people to assume the debt (i.e. the negative impact) will be easy to quantify and can be treated like some other expense (and thus it often is ignored for far too long). So, the first thing I ask whenever the "business side" asks for a quick and dirty fix for something (often mainly because of some production issue) is "When and how are we going to fix this properly? How will we deal with the downsides in the mean time?". This usually achieves my goal of making them think about the implications more -- I don't believe that's a very viable strategy in bigger companies, though.
maa5444 8y ago
looks 2 me ... advice s from a NaN programmer a programmer likes more machines to ppl, that s it
btschaegg 8y ago
One point in the article I'd put another spin on is the adaptability part. While I totally agree with the author there, another symptom of this is that less "adaptable" people are prone to giving up with the phrase "I don't know" when they are faced with an unknown problem. In most cases, "I don't know, but let me try and find out" would be a way better approach to things (as well as a more useful mindset overall). I've literally solved bugs that were ignored due to "not enough information" for weeks because the original assignee wouldn't even launch a simple grep query and apply some simple predicate logic.
ravenstine 8y ago
> It seems like every day an article comes out with some harmful algorithm a company has implemented, like the YouTube algorithm radicalizing the alt-right, Amazon creating a sexist hiring algorithm (which they didn't end up using), or AI misgendering black women. Think about everybody when you are writing your code! I couldn't keep reading after this. First of all, hyperbole much? More importantly, can such problems be assumed to be what the author seems to be suggesting as microaggressions, or is programming just really hard and fraught with problems?

45 points by fagnerbrack 8y ago

That are good characteristics for anyone. Be a decent human also while at your job your life and other's life are going to be better. (And probably you also will get better products and be economically successful as a side-effect).

wawhal 8y ago

I don't know if 'Discipline' was missed out, or discipline is a quality inferred to be required for every field out there. Personally, discipline and honesty towards the code have been the most helpful soft-skill challenges in my programming career.

adamfaliq 8y ago
Can you explain what you mean by 'discipline', especially in software engineering context? Is it doing test rigorously, code reviews etc? Or simple commited to deadlines and get things done?
- watwut 8y ago
  Not op but: do skip useful parts of work you don't feel like doing. Do boring or annoying parts of work even when it is tempting. Do not skip test just because you don't feel like. Do clean up code after yourself even if it already works. Write documentation, ask questions even if you would rather code, etc. Finish tasks before moving to shiny new ones. When you know about bug, dont ignore it and at least put it into tracker. Send that mail to administration/management/customer, fill taxes, don't leave mess in common kitchen. If you promised you will do tasks in some order (e.g. prioritized them) follow what you said. Don't come to work sleep deprived too often, eat properly, exercise. It may also mean taking time for socialization/family/help friends even if you would prefer to code right now. Effectively, it means same thing as discipline in any other context.

leowoo91 8y ago

Communication is key I agree but technical managers are more vital for making connection to stakeholders.

Fargren 8y ago

I'm going to go on a bit of a tangent. There's one skill not mentioned here, but I think is the most valuable skill a programmer can learn, and many people take for granted. Know English. "Communication" here is related to that, but it's not the same. A lot programming resources are not accessible at all without passable English, and without very good English, there's a lot of them that will go over your head and you won't even know why. That's without even getting into the advantages that come from talking the Lingua Franca of programmers, and the collaboration opportunities that brings.

wsc981 8y ago

Some people have mentioned communication and I guess a very important subcategory is negotiation skills. I feel most devs are bad negotiators especially when thinking about hourly rates and the like. And (in my view) earning a good income is very important, so you can retire early for example. Or perhaps work less hours (might be difficult in the US, but in The Netherlands a lot of people work 4 days a week, for example).

oldboyFX 8y ago

More people should focus on the following, in my humble opinion: - be consistent and reliable - learn about your company's business goals - focus on delivering value for the business instead of writing "clean/bespoke/artisan" code - don't get emotionally attached to your own code or a piece of technology - learn how to educate other stake-holders - learn how to negotiate with non-technical folks without being annoying and overstepping your boundaries (this can be difficult)

iliaznk 8y ago
Just wondering, in terms of value for the business, doesn't clean code always deliver a higher value as opposed to, say, messy code? Being easier to maintain and debug, and also likely to contain less bugs thus being more reliable, do those qualities provide value by themselves? I realise that, from a business' point of view, how fast something is done may be more valuable than how clean, but at the end of the day a "faster" code can eventually take longer to reach a production-grade reliability... Isn't that true?
- btschaegg 8y ago
  Edit: Obviously, I'm not GP, but here's my take on this. > doesn't clean code always deliver a higher value as opposed to, say, messy code? I'll agree with you there, but I'm under the impression that the phrase "clean code" is somewhat too ambiguous. Coding style per se is very subjective anyway, so obsessing over it propably is not a good thing in most cases, yes. But if the "quick and dirty" approach also influences the architecture of what you're developing (i.e. it also affects other code) I'd very well argue that taking a stand against it is a good thing to do. On a similar note: I find the notion of "technical debt" to be quite useful in a lot of ways: By taking the short path, you'll be forced to make up for it at a later date, be it through slower development, a lack of reliability or the necessity to clean up the "hacks". Where the metaphor breaks down (and seems to be contraproductive) is that it leads many business people to assume the debt (i.e. the negative impact) will be easy to quantify and can be treated like some other expense (and thus it often is ignored for far too long). So, the first thing I ask whenever the "business side" asks for a quick and dirty fix for something (often mainly because of some production issue) is "When and how are we going to fix this properly? How will we deal with the downsides in the mean time?". This usually achieves my goal of making them think about the implications more -- I don't believe that's a very viable strategy in bigger companies, though.

maa5444 8y ago

looks 2 me ... advice s from a NaN programmer a programmer likes more machines to ppl, that s it

btschaegg 8y ago

One point in the article I'd put another spin on is the adaptability part. While I totally agree with the author there, another symptom of this is that less "adaptable" people are prone to giving up with the phrase "I don't know" when they are faced with an unknown problem. In most cases, "I don't know, but let me try and find out" would be a way better approach to things (as well as a more useful mindset overall). I've literally solved bugs that were ignored due to "not enough information" for weeks because the original assignee wouldn't even launch a simple grep query and apply some simple predicate logic.

ravenstine 8y ago

> It seems like every day an article comes out with some harmful algorithm a company has implemented, like the YouTube algorithm radicalizing the alt-right, Amazon creating a sexist hiring algorithm (which they didn't end up using), or AI misgendering black women. Think about everybody when you are writing your code! I couldn't keep reading after this. First of all, hyperbole much? More importantly, can such problems be assumed to be what the author seems to be suggesting as microaggressions, or is programming just really hard and fraught with problems?