
Organizational Skills Beat Algorithmic Wizardry (2015) - walterbell
https://www.johndcook.com/blog/2015/06/18/most-important-skill-in-software/
======
b1daly
This is a nicely succinct expression of what I intuit to be almost a universal
rule of creating/designing/making.

It’s related to what I think of as “coherency” and I’m often surprised at how
long it can take.

The most recent example is that I was writing up some technical feedback for a
reviewer of a product I develop.

My first draft was several pages worth of dense prose. I realized I needed to
simplify, otherwise it would overwhelm the reader. I worked on it for several
hours, and in the end I had it down to about 4-5 paragraphs.

So it took me five hours to write what looks like a simple, straightforward
email!

I’m a music producer by trade, and the principal is very much at work. To
create a successful recording requires getting into the small details of the
sounds, and working with them, whether your tools are complex or simple.

~~~
magwa101
Timely! I'm on "hiatus" and producing music again after a 10 year break. It's
been months of learning. With the new tools I can go so much deeper, so I am.
If you want repeatable processes you have to focus on tools and organization.
I've integrated github, google docs, Reaper, and bunches of VSTs and I'm just
barely starting to see a good organizational approach. This is 1 year later!

~~~
slfnflctd
I would love to see a more in-depth description of this process you've gone
through, in a blog or reddit post or discussion thread somewhere.

Like many others, I've been playing with digital recording tools off & on
since the 90s as a total amateur (wanted to be in a 'cool band' since middle
school, still do), and while I know there are a thousand great guides out
there, I always seem to find them overwhelming/paralyzing.

Admittedly, I probably don't travel in the right circles for it, but the
github and google docs aspects in particular sound like something I haven't
read as much about musically inclined people doing before.

------
stupidcar
I was thinking along similar lines the other day. I was thinking about whether
I've actually improved as a software developer over my career. It occurred to
me that most of the languages and frameworks I use are either less than a few
years old, or have been changed or reinvented in substantial ways. As such,
not much of the declarative knowledge from my early career is of much use. But
have my _skills_ improved?

I came to conclusion that my ability to code on the _micro_ scale, e.g. at the
level of an individual method or algorithm, probably stopped improving after
2-3 years of professional experience. I think you could take the 24-year-old
me, ask him to work on a narrow problem, and he'd do about as well as I would
now.

But where the 24-year-old me struggled a lot was at the _macro_ scale. He
didn't know how to compose those individual pieces into a cohesive hole, and
instead fell back on a handful of patterns like singletons. I remember
horrible days trying to unravel my own code and figure out how component X was
going to communicate with component Y, and the result was often a mess.

I think this macro-scale ability really does improve continuously over time,
as you are exposed to more and better patterns for integrating components and
managing dependencies.

~~~
AnimalMuppet
This is not true of me. Even on the micro scale, I'm _much_ better than I was
at 24. I write far fewer bugs. And I write code that communicates intent much
better.

------
jmartrican
This reminds me of the PHD in the office, who was hired because of some
mathematical related skill they specialize in, is never getting their hands
dirty. They are off somewhere looking smart and protecting their allure, while
us grunts are keeping the lights on. Broad stereotype here, but it is what I
have experienced.

To be very honest, being on Google searching constantly has been the most
important skill. In this face paced IT environment, if you stay too long
becoming an expert on something, it's replacement is coming right around the
corner.... even within the same framework. As I was finally getting a hang off
Spring 4 and Spring Boot 1.x, then comes Spring 5 and Spring Boot 2 with their
new WebFlux architecture.

~~~
fwdpropaganda
You're like the hospital janitor complaining that the doctor never wipes the
floor. He's just off somewhere "looking smart".

... do you realise how ridiculous this sounds?

Let me say that I get your point of view: I know of the existence of smart and
educated people who are lazy, presumptious, have a superiority complex, talk
down on everyone and/or are fakes.

Do you understand _my_ point of view though? Are you aware that people exist
who are less educated people and who can't grasp that valuable complex things
exist which requiring specialized knowledge, and that those less educated
people being unaware of the existence of such things automatically and wrongly
assume that their specialists are fakes?

~~~
watwut
That is not nearly accurate analogy. Note that doctors in hospital do more
then just looking smart.

And know multiple people who are like he described: generally keep aura of
looking smart are are good in few selected areas and generally don't really do
much work. And they _always_ get absurd amount of benefit of doubt the same
way you do here. Meanwhile anyone who criticize them is assumed to be stupid
hospital janitor who don't get that they are the ones who do real work.

And know, they do not do "valuable complex things" nobody else cant grasps on
the project. They talk about complex things around water cooler to impress
people.

And yes I do know people who do complex things too.

~~~
fwdpropaganda
Right, so we both know both types. But the person I was responding to either
doesn't, or chose to omit one to try and make a point about it.

> That is not nearly accurate analogy. Note that doctors in hospital do more
> then just looking smart.

That's precesily my point. Doctors in hospital do more than just looking
smart, even though janitors may or may not realise it. It's really an
excellent analogy.

~~~
watwut
Pretty much all janitors realize that doctors do work.

~~~
fwdpropaganda
Are you guessing, or have you actually asked?

~~~
loxs
I have been a janitor (or pretty much that) during my MD studies, then I have
been a nurse, then a doctor, then a programmer. I didn't know a janitor who
thought that nurses or doctors didn't do valuable work (greatly more valuable
than their own).

In the IT field it's different though. Every junior is absolutely sure they
are better than their team lead (been there, done that, also been the team
lead). Every QA thinks that programmers are lazy brats. Every PM too. Every
programmer thinks QAs and PMs are stupid and can't grok their (programmers')
work (which, so far I think that it's indeed true (maybe not the stupid part,
but the 'can't' part), and that's why the industry suffers).

~~~
fwdpropaganda
Thanks for sharing.

> I didn't know a janitor who thought that nurses or doctors didn't do
> valuable work (greatly more valuable than their own).

More than once I've heard staff (not janitors though) talking depreciatively
about doctors (e.g. "he thinks he knows everything", "he said X but my uncle
says Y").

I think if you read what I wrote a bit more charitably you'll see that my
point wasn't really about janitors. I used them figuratively to comment on
OP's attitude that seemed like the terrible combination that is confidence and
ignorance.

~~~
loxs
I absolutely agree with your comments. I just joined in to give my 2 cents
with some real experience and to give more nuance to the discussion. I do
agree that medical and IT fields are different (and that's what I tried to
explain in my original comment)

------
lopmotr
I work on math-heavy engineering software where it can take a month to learn
how some clever algorithm works and I'd say organizing the code is still
equally as important as that. I've thrown away big clever algorithms when I
found libraries that did it for me and did it better than I could.

~~~
nafey
But most people are not doing that in their careers. It's mostly CRUD
applications that they are building

~~~
collyw
I am working on CRUD just now. Its amazing how complex some people manage to
make simple things. Keeps me in a somewhat unsatisfying job though.

~~~
Raidion
I mean, CRUD doesn't have to be simple. It can get complexity from the
underlying data, or dealing with 100 million users at once, or it having to
return results FAST.

Just because you don't have to write some novel algorithm doesn't mean you're
not solving hard problems.

~~~
Tade0
I think the parent wanted to say that their problems are rather _tedious_ than
_hard_.

I'm currently in a very similar situation - a project in which we have a table
of records, two of which are special in a certain, business-related way, but
need to be presented along with the others, so to get around this we place
"ifs" here and there - a lot of them.

It's a generally simple project that has been turned into something overly
complicated because somebody lacked the foresight to design the architecture
better.

~~~
collyw
What I meant is that with a decent database design, you shouldn't need to much
code to get things done (using Django as I am used to).

Instead I am jumping from file to file, trying to work out what is going on,
what all the seemingly unnecessary code is doing. It can be both tedious and
difficult just to get data between the database and a webpage.

I want to rewrite a lot of it, but I understand that working, tested code is
actually worth quite a lot, and there may be functionality that i haven't
understood yet.

------
CodeArtisan
_we want to establish the idea that a computer language is not just a way of
getting a computer to perform operations but rather that it is a novel formal
medium for expressing ideas about methodology. Thus, programs must be written
for people to read, and only incidentally for machines to execute._

This is from the preface of SICP[1] which taught me that abstraction is the
most important concept of programming (and computer science?). Do you need to
know how sqrt() has been implemented to being able to use it? no. A programmer
shall first have a good knowledge of the abstraction techniques. He shall know
how, when, and the cost to use them. Then, if you are illiterate when it come
to algorithm design and analysis, it shall not be a problem because replacing
a _bad_ algorithm/implementation by another would be easy due to the correct
application of abstraction. _" The cleaner and nicer the program, the faster
it's going to run. And if it doesn't, it'll be easy to make it fast."_ —
Joshua Bloch

[1] [https://sarabander.github.io/sicp/](https://sarabander.github.io/sicp/)

------
wolco
The most important skill I've learned is how to collect money. Everything
falls apart at the end if you can't collect.

~~~
da02
Do you mean setting up a payment system for customers? Or getting the adequate
funding for a project?

~~~
icebraining
I think wolco is talking about payments that are charged after the service is
(at least partially) performed, which is common in the B2B world.

~~~
jwdunne
Yes. We've had clients that have literally taken courses on how to dodge
invoices for as long as possible. Well past our 30 day terms.

~~~
dboreham
A horse head in their bed works quite well.

------
henrik_w
This is exactly my experience too. When I started working as a SW developer, I
expected to use a lot of the clever algorithms I had studied at university.
That didn't happen. Instead, the tricky problem was having lots and lots of
simple features aggregated together - complexity from aggregation.

These were my top 2 surprises when I started working as a programmer:

[https://henrikwarne.com/2012/08/22/top-5-surprises-when-
star...](https://henrikwarne.com/2012/08/22/top-5-surprises-when-starting-out-
as-a-software-developer/)

------
hellofunk
> But it’s hard to have the patience to wrap your head around a disorganized
> mess that you don’t care about. Only if the disorganized mess is your
> responsibility, something that means more to you than a case study, can you
> wrap your head around it and appreciate improvements.

This really hit home for me. I personally find it very difficult to get
emotionally invested and therefore effective when working on a codebase that I
don't personally like. But that's not very professional, so I tend to phone it
in when in that situation, at the expense of really using my talents or
dedication. But I know that other professional coders do better than me and
somehow find a way to be very interested or invested in things they don't care
about, perhaps because for many coders, the code itself is enough to warrant
the personal interest, and less so what the actual code is used for? If I
don't have a big-picture appreciation of a project, I don't enjoy the small
stuff either. Perhaps that means I'm in the wrong profession.

~~~
wonton2
I have found out that the only thing that motivates me is thinking about the
people that will use what i code. Either the users find it useful and
enjoyable or the company find it profitable. I dont see any reason to work on
something where i cannot see my role in contributing to these things.

------
lstamour
Previously:
[https://news.ycombinator.com/item?id=9757892](https://news.ycombinator.com/item?id=9757892)

------
YeGoblynQueenne
The tough truth is that you need to be able to do both, or your skillset will
never be complete. If you specialise in algorithms, you might never be able to
put a bunch of them together to build a system that works and does something
interesting. If you focus on architecture but never understand how to read and
implement algorithms and how to evaluate them, you will always be limited in
what your systems can achieve and how well they work.

Additionally, most of us are limited in what we can learn in a lifetime.
Talent is far from the primary limitation (most people will be average in
terms of innate ability; my guess). Far more important is the time available
to study and learn new skills and the motivation to do it. Then there are
issues of personal preference: if you just love algorithms, you will tend to
focus on them, if you love building systems, etc.

~~~
blowski
> The tough truth is that you need to be able to do both

There are many, many more opportunities for organised people who aren't great
with algorithms, than disorganised algorithm geniuses.

------
thinkloop
There is something that doesn't ring completely true about this. While I agree
coding is not about coming up with some ninja recursive one line function that
solves all the problems, reducing it to a simple matter of organization is not
quite right either. Yes it is about organization, but there is a component of
wizardry too. It takes a lot of intelligence, skill, experience and talent to
be able to identify and model the fundamental relationships between all the
parts in the simplest possible way. It's what separates seniors from juniors.
The top guys do the tricky work of architecting and modeling the system, while
the juniors fill it in until enough new information is revealed for the
seniors to improve/change/update it as needed.

~~~
watwut
> The top guys do the tricky work of architecting and modeling the system,
> while the juniors fill it in until enough new information is revealed for
> the seniors to improve/change/update it as needed.

If that is how it works, I did not really experienced it. In one place where
they attempted this, senior ended completely out of touch with his
architecture problems - because it was only juniors experiencing them and
never him. In big corporations, architect does super uber high level and
negotiations.

Big refactoring and architectural changes were done by seniors and require
experience, of course. But that is only part of what senior does, a lot of if
is using existing architecture. Also, juniors can grow into such senior only
by taking on larger and larger tasks - you don't get there by filling small
boxes without doing own decisions, mistakes and living with them.

The biggest problems, especially in larger projects, are organizational one.
As in, algorithms part is what is often done by juniors, who often actually
can do them well being just out of school and being trained in them lately.
And also who have bigger uninterrupted chunks of time then seniors.

------
foreigner
I totally agree, so how can we interview for this?

~~~
codingdave
You need to ask questions that let them show off their full understanding of a
system. People without organization skills will focus on one area and not
explain the whole.

My favorite is to have someone explain to me what happens when a browser makes
a HTTP request to a web URL, which has <insert framework and DB here>. Network
guys will tell you all about the request and response, web developers will
focus on the front end, devOps will tell you how all the pieces communicate,
etc. My expectation is for someone to at least be able to give a high level of
all those things, while also having detailed knowledge of some specific
areas... and seeing how they choose to answer such an open-ended question
tells you quite a bit about where their focus and attention lies.

~~~
innocentoldguy
Personally, I would answer that question by telling you how the HTTP protocol
works because, in my mind, that's what you're asking for. If you're going to
ask that question, I think you need to be more clear about what you're looking
for. I don't think there is any value in interviewers being intentionally
vague in order to test if a candidate can guess what they're thinking.

~~~
leesec
Or you could just ask them to specify like, "did you mean explain x or y?".

~~~
innocentoldguy
I do. That wasn’t my point, however.

------
blueprint
In other words, a person of training can obtain good skill, but a person of
sincerity will end up with much greater skill.

------
fouc
Isn't organizational skills a fancy way of saying refactoring & (depending on
your language) Object-Oriented-Design?

Just look at Sandi Metz's or Avdi Grimm's or Martin Fowler's writings and
there's lots of good ideas on how to organize your code.

~~~
xamuel
In practice, Object-Oriented is incredibly disorganized, and you'll need an
organizational wizard to clean up the mess.

------
bordercases
I've never found out how to build organizational skills.

~~~
AlexCoventry
Modularization, encapsulation and DRY are good places to start learning to
organize code.

------
sriku
One sentence summary of the skill and attitude needed for this - "take a sad
song, and make it better" .

------
acroback
Why the f __k do these stupid companies then ask really hard Algorithm puzzles
in interviews?

This is insane, what is imp? Giving too much info or not, asking more
questions or not?

Oh man, sometimes I hate this process of interviewing.

~~~
fwdpropaganda
What do you suggest they should ask instead?

~~~
serpix
\- what do you like doing?

\- how are you as a person, a coworker

\- are you able to ask for help?

\- can you hold a conversation?

\- how do you learn?

\- describe a failure in your career and how it went from there

all this is for the interviewer and the interviewee to get to know each other
each other and see if the candidate is a good fit for the company culture and
values. If the recruitment lets in a narcissist or toxic person it will poison
the well.

~~~
groby_b
These would be perfect questions, if candidates didn't lie.

They do. All the time. More often than you'd think about something as trivial
as "can you actually write code".

And so, you'll need to demonstrate your skills. Find a better way with an
extremely low false positive rate, and you can make a _fortune_ consulting and
implementing that. It's not like anybody _likes_ doing these interviews.

~~~
watwut
You don't need to ask "really hard Algorithm puzzles" to figure out whether
they can actually write code. You can ask normally hard or even simple
algorithm and have them implement it. If your company does object oriented,
you can also ask them basic patterns. If you do functional, have them do
little bit of that.

It is the "really hard" part that is criticized here, not the "algorithm" or
"code something" part.

That being said, asking logical puzzles is fine when you are hiring juniors
you expect to train. The question with them is "is this kid smart enough to
understand what I will teach" not "does this kid already knows everything".
However even there, really hard algorithm is not something I would go for.

~~~
fwdpropaganda
> It is the "really hard" part that is criticized here, not the "algorithm" or
> "code something" part.

Really? That's not how I read it. And when I asked OP, that's not how he
responded. The examples of questions that he said he would ask had been
stripped of any algorithm-related questions, or any questions that involve
coding.

~~~
watwut
Neither serpix nor acroback answered again here, so it was someone else who
responded.

~~~
fwdpropaganda
I'm talking about serpix. When I asked him "if you don't thik that algorithm
questions should be asked, then what should?" he replied with a list of
pointless questions.

Then you said "it's really hard bit that's being criticized here, not the
algorithm bit."

No, it's the algorithm bit that serpix was originally criticizing, as
evidenced by the fact that when he replied to me he didn't include algorithm
questions from the list of things that he would ask.

------
ndh2
Does this promo piece add anything to the original blog post that it feeds on?
I didn't notice anything. Why not link the blog instead?
[http://prog21.dadgum.com/177.html](http://prog21.dadgum.com/177.html)

~~~
jakelazaroff
Side note for anyone who hasn't heard of the original blog before: it's
_fantastic_. Well worth a few hours browsing through its archives.

------
oggyhead
I don't understand this! Math is a super set of algorithmic wizardry and if
you include heuristics in algorithmic wizardry (why would you not?),isn't
organizational skills a part of the Algorithmic Wizardry? So he's saying that
knowing all skills in the subset is better than knowing all the skills in the
set? And that's just the headline

~~~
oggyhead
Organization is a mathematical and algorithmic problem regardless of the
context. And if you think people go to school so that they mug up algorithms,
you're missing the point of school. You go to school to learn how to problem-
solve, how to model problems mathematically and incidentally become aware of a
repo of solved problems which may help you in your own problem solving
adventures.

~~~
oggyhead
This is what I read in this article. The author has a problem with people
thinking that rote-learnt algorithms is the best thing ever, and proceeds to
say nope a stash of the most subjective heuristics to produce 'good code' is
wayyyy better. All in all the way I see it, the author is proposing to
supplant a shittty misconception with a bs idea that is nice short term
solution but a complete disaster in the long term which has inculcated into
this idea that programming is an Art and not a discipline.

~~~
rmdashrfroot
I agree with this argument, please continue explaining.

