
The Most Important Non-Programming Skills for Programmers - fagnerbrack
https://dev.to/aspittel/the-most-important-non-programming-skills-for-programmers-iii
======
Fargren
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.

------
oldboyFX
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
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
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.

------
ravenstine
> 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?

------
kartan
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).

------
wsc981
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).

------
btschaegg
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.

------
wawhal
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
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
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
Communication is key I agree but technical managers are more vital for making
connection to stakeholders.

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

