
The most important software dev skills aren’t technical - philk10
https://spin.atomicobject.com/2019/03/07/software-dev-skills/#.XIEhLFBznVU.hackernews
======
sammnaser
I guess it's like saying the most important traits of a golfer are patience
and focus. Sure, if you're missing those, you'll toxically spiral when you
don't perform, but are those the "most important skills" in golf? Nope, I'd
say those would be the technical skills that let you make the shot.

~~~
mgoblu3
I think the perspective of this is assuming that the technical skill is there.
You're totally right that the difference between a prime Tiger Woods and the
field is definitely talent related.

But when there's a lot bigger population who all have a similar level of
technical skill and that's not the limiter, I can agree these things are some
of the important differentiators.

~~~
enitihas
Also we should keep in mind that very few software developers are playing the
PGA tour( working on rare problems). Most people are playing in local
tournaments ( easy enough projects where the skill required is fairly low).
And they need to do that every day of the year. In those environments the
technical skills seem less important.

~~~
tmemfnskdj
This is so true. There is so much focus on social skills nowadays, I see it
taking over someone with technical skills. It’s a double edge sword in my
opinion. You have a bunch of agreeable software developers that cannot code
outside their frameworks.

------
meuk
I would argue that social skills are very valuable. At least, in the projects
where I ended up, there are a lot of people writing code of debatable quality
in a big, messy codebase. Asking around and communicating stuff helps you
understand what's going on, and what to touch and where to stay away.

~~~
apercu
Social skills allow you deal with the things around coding that lead to bad
code. Social skills are underrated and we could all develop better ones.

------
asaph
> So many things have to go right just to get a software program to compile.
> That’s why attention to detail is so important...

Even the sloppiest coders who work with no attention to detail still _compile_
their code with ease. I get the author's larger point about attention to
detail but I don't think compilation is an effective example to illustrate
that point.

~~~
bmj
Agreed. I generally see a lack of attention to detail with regard to things
like linting, unit tests, and documentation. Our CI builds fail way too often
due to the first two items, which can be easily done via a single build target
on a developer's machine.

~~~
asaph
A pre-commit hook in your revision control system can block checking in code
that doesn't pass a lint check. That would reduce your CI build failures.

~~~
ninkendo
I'm not entirely sure I want to sit through a 10 minute linting process every
time I do a quick `git add -A && git commit -m WIP` locally. Why does it need
to be a pre-commit hook instead of a simple PR check? PR checks obviously need
to be done anyway.

~~~
dean177
10 minutes?

A strategy I have used is: \- only lint the files that have changed \- only
apply lint rules that can be auto-fixed

This usually takes less than a second (short enough that you can't really tell
the difference) and the developer doesn't have to do anything .

~~~
ninkendo
> 10 minutes?

Yes. I work in a codebase that's 30GB checked out. It takes a long time to run
our automated checks. That's why they happen on the server, when I make a pull
request.

The upshot is the same: it doesn't go to master until checks pass. But who
gives a shit about what I'm committing locally? I reserve the right to save my
work even if things aren't compiling. You (my teammate) won't see it anyway,
it's all locally on my machine. Why do you care?

------
jaabe
I agree with the author on patience, but I wonder if you can become a software
developer without it. Sure some people will have more than others, but
learning how to make code work is a terrible, terrible process and I’m not
sure you can go through it without massive amounts of patience.

I have a side job as an examiner for Danish CS students, and a noticible
difference between first years and final project students is how they tolerate
the frustration of having code not work. If you can’t sit through hours of not
knowing why something just doesn’t work, you probably find a different field.

~~~
swsieber
I think you can have different types of patience. Patience with getting
something to work could be very different from the patience to build something
correctly, which could be different from the patience to deal with people...

But I agree - you probably won't become a dev without having or learning some
degree of patience.

~~~
mr_toad
Some people are far _too_ patient to be great programmers.

They are content with the daily drudge of slow, manual tasks, whereas a truly
good programmer would become frustrated and desire to improve things.

[http://threevirtues.com](http://threevirtues.com)

------
kharak
"Attention to Detail" is my major weak point. I don't have it in coding. Give
my a philosophical essay, a political discussion or an academic paper and I'll
drown you in details, implications and references. Those come intuitively to
me.

Writing codes is completely different. I have to practice everything what
others seem to do intuitively. I need checklists. I need to take notes. I need
to review my task and codes several times. And still, I overlook the obvious
and never spot the easiest implementation (even for trivial tasks like
checking for empty Strings). All while it takes me a great deal of discipline
to take care of the level of detail that is required.

If someone here has/had the same problem, I'd like to hear their solutions.

~~~
dwrodri
Just out of curiosity, is you background in web development and/or the C
family of languages (i.e. C, C++, C#)?

I mention these because they rely heavily on object-oriented and/or imperative
programming paradigms. With C and C++, I still struggle often with striking a
good balance between "writing a short solution that works well" and "writing
code which is a joy for others to read". The former often relies on my
technical knowledge and produces code that can be obscure to other readers,
the latter often requires MUCH more concentration and attention to detail when
writing.

However, I have recently started experimenting with declarative and functional
Programming. Coming from an imperative background has made "relearning" how to
program quite difficult for me, but I've just started to see the "elegance" in
higher level functional languages, such as OcaML and Haskell. Of course,
functional languages are often MUCH better suited to different problems than
OOP languages, but combining filters, reductions, maps and folds seems to
activate the parts of my brain that are much more closely associated with the
"classical logic" side of programming. I think you should check it out if you
haven't already.

~~~
kharak
You're on to something.

I started with database programming, so mostly declarative. That was a joy and
I did't need much time to catch up with the senior developers. Afterwards, I
switched my employer and started anew with Java. I was completely overwhelmed
and struggle to this day. Last week, I learned a little bit about streams and
how functional programming works in Java. To my surprise, that seemed quite
easy to understand.

I don't really know why OOP seems so much harder for me to do.

~~~
mrfredward
Honestly, I thinks it's because a lot of OOP is awkward and forced. When it
was the craze, object orientation became an ends instead of a means, and so it
taken past the point of being clean and useful. Why do c# and java require
every function, including main, be in a class? Why do we need static classes,
which are really just a namespace for functions? There's no benefit to the
programmer, it only serves the "everything is an object" paradigm. Certain OOP
patterns, like the visitor pattern, are really just hacks to make OOP work
like functional.

I use c# everyday at work and for the most part love it, but there are certain
problem domains (anything with significant multithreading) where forced OOP
thinking just makes everything harder than it needs to be.

~~~
james_s_tayler
Curious, can you explain how the visitor pattern is like functional
programming? What is it analogous to in FP?

It's not a pattern I have ever really wrapped my head around fully, but
perhaps there is some structure in functional programming that if I view it
through that lens it will make much more sense?

------
edw519
I have always strongly believed that "Tech skills make you good. Other skills
make you better."

OP brings up a lot of good points (who could argue with these), but overlooks
my #1 fundamental: If you can't write good code, not much else matters.

I know lots of programmers who have mastered the technical skills but are weak
at the other things, so no one would ever mistake them for "senior", no matter
how good their code is.

But I know many more "I.T. people" who are good at the "soft stuff" (analysis,
design, product ownership, people management, agile, etc.) but can't code. I
don't want to sound snarky, but these people are a dime a dozen. They often
have great attention to detail and patience, but would you really entrust them
to build your software?

Learn how to build software first. Be able to do that well _before_ adding the
soft skills.

 _That 's_ the most important software dev skill needed. And it is most
definitely "technical".

~~~
mpweiher
> If you can't write good code, not much else matters.

Can't stress this enough and I frankly don't understand all these articles
claiming otherwise, when even the most minimal reflection would clear things
up in a jiffy:

Take a skilled trapeze artist who has great attention to detail (I hope) and
is patient (I hope) but cannot code.

Alternatively take a brilliant software developer who is slightly sloppy and
not very patient.

Which one do you want writing your software?

Of course, that's accepting that these are important skills/attributes. I
don't actually agree they are. See

[https://medium.com/@petecam/why-laziness-impatience-and-
hubr...](https://medium.com/@petecam/why-laziness-impatience-and-hubris-
drives-great-developers-to-script-301f46f431)

~~~
avgDev
I agree that good code matters but I am not sure if it matters THAT much in
some cases.

I write average code but always seek to make improvements. I'm always trying
to improve my knowledge on OOP and learn about different approaches to
architecture but at my company I could write garbage code and nobody would
care. Recently, I tried to make an update to a legacy software and the code
was quite bad, methods that were 15K lines long. Terrible variable names, UI
elements named button1, button2 etc. However, nobody cared because it worked,
it served it's purpose for the last 12 years, and yes it needs a complete
rewrite, but it would probably need that anyway after 12 years as there are
some major business changes.

I think every programmer should try to make things and try to improve.
However, over-engineering and writing too many unit tests can also be a waste
of time.

~~~
mpweiher
> over-engineering

Not sure why you think "great code" = "overengineering".

Great code is _not_ overengineered, by definition.

------
rcar
"Most important"? My mother is a patient and detail-oriented person, but I
wouldn't hire her as a software dev.

To take a less extreme example, depending on the role I'd still rather hire
someone who was occasionally impatient and didn't always write tests but knew
how to code really well vs. a fresh grad who's always cheery and polishes the
hell out of their work but takes a lot longer and produces meandering code.

~~~
scoutt
If your mother is not a programmer, then (following the logic of the article)
being a patient and detail-oriented person doesn't make someone automagically
a programmer.

------
bitL
I disagree, those are virtues one needs just to become a programmer. The only
skill that matters in the end is velocity; these days you are required to
deliver a 99.999% solution that solves some "unsolvable" computer science
problem in a practical way within 3 months. Whatever helps you to get there is
what you need to acquire, the rest is useless. This article seemed to me like
a story from a developer that is just factually leaving being junior in
practice (not in title) and observing there is a bit more complex world out
there... I hope that person doesn't end up in management, enforcing their
tunnel vision on everybody underneath, capping their capabilities.

~~~
HashHishBang
People like you are the reason people like me are QA/SETs. Your velocity, in
my view, is some slapdash worked-15-hour-days-because-they-thought-they-could
nonsense that is more likely to crumble under load and/or the first edge case
that pops to mind. The only one capping their capabilities here is you mate.

~~~
bitL
You are naive. Did you work at world class companies that dominate their own
market? They are exactly like that in the areas they are making money - they
get the fastest programmers that could deliver world-class code. Not your
typical half-baked developer quickly churning low-quality code in JS that
breaks down after 5 seconds of load you get headaches from as a QA.

~~~
HashHishBang
>You are naive. Did you work at world class companies that dominate their own
market?

Seeing as I'm currently sitting in my office at Adobe I would say yes. There
are plenty of code jockeys like you churning out low-quality
Java/Python/PHP/C/C#/JS/whatever. You, despite what you may think, are not
special.

> Not your typical half-baked developer quickly churning low-quality code in
> JS that breaks down after 5 seconds of load you get headaches from as a QA.

Cute. I get headaches from the guys who think they're great. From the ones who
think that not documenting what they do is time wasted because clearly what
this does is obvious. I get headaches from the people who have NO IDEA how
their code actually performs and if there's any kind of slowdown well just
throw more money at the hardware.

I can practically hear you and the others like you cry out, "But it works on
my machine!" Oh the headaches that has caused.

~~~
bitL
> There are plenty of code jockeys like you churning out low-quality
> Java/Python/PHP/C/C#/JS/whatever.

OK, I landed #1 spot on HackerNews with a product I mostly developed (under a
different nick) some time ago. You know everything about me as well. It was
also competitor of one of your products.

All I am saying is that these are assumptions/metrics with which VCs/owners
run/structure their companies and what actually matters to them. I have
experienced it dozen times. I have also experienced when I had to fix
somebody's horrible code in production developed in high velocity/high
stress/low quality mode that was bringing one famous tech company down
(lawsuits etc.), and had to correct spots I'd never seen before in some of the
most complicated areas of the product dealing with provably infeasible
problems (distributed systems). I'd also experienced an environment in a
relaxed top company (rated higher than either of FAANGs) where we discussed ad
infinitum just individual names of functions, their parameters and if they
perfectly capture their meaning and refactored them daily; I don't have to say
that project wasn't having much of a velocity and its market share reflected
that.

------
CM30
Also, knowing what to build helps a lot too. Many of the most successful
companies and projects didn't come about just because there was a good
developer/programmer involved, but because they identified a market with
interest in it and built what said market wanted/needed.

A lot of people will just build stuff they find interesting/fun to build, but
no one will care. What they will care about is whether it solves their
problems, and they'll often go for a hacky, poorly done solution that does if
need be.

------
asaph
Continuous learning is also critical for success.

------
JoeAltmaier
Agreed; the single most important characteristic of an effective performer is
Conscientiousness. Working at a task, measuring the result against a standard,
working some more, until its actually really done.

The absence of this causes havok: a task thought done will turn out not-done
at the deadline and become an emergency. A feature not measured against all
the requirements will fail in test or worse! in the field and cause customer
angst and extra cost to everybody.

~~~
duxup
Does this make sense if I ever want to change this code?

Can anyone else even read it?

What is the end goal here and does this accomplish the spirit as well as the
technical goal?

What about related features that are likely going to end up related to this
somehow?

That and so many more things to think of that can change your direction, but
long term really pay off rather than "code does thing, good enough".

I say that having just read a bunch of code that only does one thing, could
only do one thing, and now has to be reworked entirely because it can't do
much else / be adapted.

~~~
JoeAltmaier
If that is the task (make code that can be changed) then work at that. How do
you verify it though? My buddy Tom says, code isn't portable/changeable until
you port it at least once.

~~~
duxup
Yeah I agree there is a verification problem. I certainly wouldn't try to tie
any solid metrics or such to it.

My thing is... did they even try? There's a lot you can tell that is not the
least bit portable or changeable. If it doesn't meet some requirement in the
future, oh well that happens no way to be 100% sure. But at least some effort
might leave a path open, even if not optimal.

------
Yuval_Halevi
I pretty much agree with the author. I'm not a developer but I worked with
many developers in the last 6 years.

Some of them were great and some were not so friendly. -Respect for others \-
Being friendly \- Give good energy to the people around you in the office \-
Learn how to work in a team

Those are the things that when a good developer has, he becomes a game-
changing part in a startup

~~~
C1sc0cat
The attention to detail and not missing obvious gotchas is something that
comes with age / experience.

------
stuxnet79
While the traits mentioned in the article are useful (patience and attention
to detail), these are traits that are selected against in most work
environments. Writing software "The Right Way" TM takes time and time is
usually something most engineers don't have in abundance.

------
WheelsAtLarge
No, I completely disagree. The most important skills, after being a competent
developer, are being able to communicate and get along with our team.

It took me years to understand this but without being able to work with your
team you will not e able to create great software.

It's possible to create a product that's not technically beautiful but it
meets a real need in society. Ultimately we create software to meet a need.
Once we understand the need we can go back and refactor it. But if we can't
communicate and get along with our team then the chances of creating a good
product are low.

------
johnrob
The challenge of details is best solved via rigorous definition of “done”
(i.e. acceptance criteria). If you don’t have consensus for that, there are a
million ways someone else can re-define the problem and thus expose “incorrect
details”. Many orgs delay this consensus, making for plenty of post code
review work, but I don’t think that’s necessary bad so long as you don’t let
PR comments hurt your ego.

------
rarspace01
To be honest, after I started in software development 10 years ago, the most
important skill is (good) communication. If you can't understand your
stakeholders or express concerns the prettiest code won't help you. Obviously
it will help, but only after figuring out the former.

------
bpyne
The following are at least as important. \- communication \- compromise \-
curiosity

~~~
saiya-jin
Communication is by far THE biggest issue in many projects. Especially with
geeky introverty software dev types. Heck, my fiancee is a doctor and the
amount of crap that happens in hospital just because people (other
doctors/nurses/patients) don't communicate clearly, make tons of incorrect
assumptions etc. is astonishing (and has direct consequence in quality and
quantity of health care provided).

------
stunt
Both hard and soft skills are important. When the subject group are above a
certain level of hard skills, you can identify real seniority and leadership
capabilities by looking into soft skills.

------
linkmotif
I'm not sure these aren't "technical" skills. Patience and attention to
detail? In my experience that's part of the technical skill of programming.

~~~
brootstrap
same thoughts here. I mean i appreciate the article and write up. My big skill
is openness, communication, honesty. I have worked with many brilliant nerds
who cant stay focused and literally contribute jack shit to major projects.
They probably make the most $$ too.

I dont care how good your program or app is. If you cant talk like a normal
person, accept criticism, negotiate etc. You are going to suck. The best co-
workers i have are able to combine both the CS tech knowledge with other
skills like good estimation, honest and open communication, clear planning and
execution etc.

You can just tell in my opinion. Start workign with someone on a project for
an hour and you can tell if they are a nerd without focus who spends weeks
doing useless shit, or someone who will seriously contribute to your team and
help get shit done.

------
bassman9000
_I’ve come to appreciate two important characteristics of good developers that
aren’t unique to software at all._

The title doesn't match the article's intent.

------
mr_toad
If all a programmer required was patience and attention to detail then we
could have machines do it.

------
nukeop
This goes against Larry Wall's virtues of GREAT programmers: laziness,
impatience, and hubris. Impatience stems from laziness and made me look at
entire classes of problems in a different way than many of my peers. It is
crucial to the character of a proper developer and its lack cannot be
substituted for.

