
Organizational Skills Beat Algorithmic Wizardry (2013) - rrampage
https://prog21.dadgum.com/177.html
======
BoiledCabbage
The single most important undervalued skill for any programmer, is Domain
Modeling. It's an absolute shame it isn't a requirement to get a CS degree.

Few things have more of a 3x effect on your code, than poorly chosen data
modeling, or incorrect domain relationships. Your domain modeling determines
in a large part, the amount of incidental complexity in your codebase.

When done incorrectly, it's what causes the painful - "Yeah we can't account
for that feature without a lot of work. It's not how the system is designed."
Which means either a re-write of large portions of the core domain, and all
the fall out / impact of every dependency on it; or, the need to wrap code in
hacky patch that works for this feature, but falls apart for the coming
related feature because it wasn't designed the right way.

~~~
101008
I had almost a full course on Domain Modeling to get my degree in CS in the
University of Buenos Aires.

I hate it, of course, cause I had to work a lot. The idea was that for every
model you designed, the teacher introduced a new feature that required to
rethink everything again.

~~~
DenisM
Was the pain worth it in the end?

~~~
true_religion
UVA had a class like this on software engineering. Not only did the professor
randomly add features as the semester went by, they also would randomly
reassign group members so you couldn’t become reliant on a single person and
were forced to keep documentation.

I thought it was hell at the time, but it’s a lot more low key than a real
disfunctional workplace.

------
dang
Thread from 2018:
[https://news.ycombinator.com/item?id=16703553](https://news.ycombinator.com/item?id=16703553)

Discussed at the time:
[https://news.ycombinator.com/item?id=5910037](https://news.ycombinator.com/item?id=5910037)

------
fest
I really like the perspective provided by the General systems thinking [0]:

There are problems with little randomness and number of moving parts: these
problems are either easy to reason about, or easy to solve by analytical means
(think of systems that can be reduced to few equations).

Then, there are problems with either/both: large number of elements and high
degree of randomness. These problems can be dealt with statistics.

Then there is a ball of mud between - medium number of elements/randomness.
The number of interactions is too high to be able to reason about them
effectively, yet too little to derive solution by statistical means.

Most of the software, especially poorly written one falls in this realm- the
more interactions between elements, the harder to reason about. Mastering
algorithmic wizardry just moves you slightly right on this plot- being able to
decrease the number of interactions makes the system easier to reason about
[1]

0: [https://www.amazon.com/Introduction-General-Systems-
Thinking...](https://www.amazon.com/Introduction-General-Systems-Thinking-
Anniversary/dp/0932633498)

1:
[http://article.sapub.org/image/10.5923.j.ajss.20150401.02_00...](http://article.sapub.org/image/10.5923.j.ajss.20150401.02_001.gif)

------
jkuria
Hmmh, wasn't there another article like this some time back that cited clear
writing (of prose/email/documentation) as the most important programmer skill,
especially if one wants to ascend to the highest ranks of an organization?

In the discussion thread, I believe one of HN's elder statesmen (ChuckMcM?)
quoted a Nobel prize-winning physicist who said "clear writing in English" was
more important to his career than math.

~~~
markus_zhang
Clear writing is indeed difficult, as far as my field (Business/Data Analyst).
More difficult is to express oneself clearly under a lot of pressure.

~~~
cosmie
That's underselling the difficulty of being a business/data analyst. You not
only have to express yourself clearly, but are constrained by the knowledge
and mental models used by your target audience. Which becomes exponentially
more difficult if you have multiple audiences you have to convey a point to,
simultaneously.

------
teucris
“When it comes to writing code, the number one most important skill is how to
keep a tangle of features from collapsing under the weight of its own
complexity.”

This resonates with me for sure. But the article was written back in 2013. Do
employers really still ask questions about “oddball variants of heaps and
trees” and “puzzles with difficult constraints”?

Also can we get the publish date in the title?

~~~
atomicity
My anecdotal experience interviewing this year is that they don't.
LeetCode/Hackerrank-level algorithm questions are common. I haven't seen any
TopCoder-type questions and brain teasers. According to some posts, it seems
like the industry is trending towards easier problems with more focus on "the
process" in which a person finds a solution.

It's still true that employers overemphasize algorithmic ability. I had one
systems pop quiz but nothing about usability, business, SWE processes, etc.
which are as core to software engineering as algorithms.

------
mpweiher
Related: Richard Feynman, "Computers Don't Compute"

 _" One of the miseries of life is that everyone names everything a litte bit
wrong, and so it makes everything a little harder to understand in the world
than it would be if it were named differently. A computer does not primarily
compute in the sense of doing arithmetic. Strange. Although they call them
computers, that's not what they primarily do. They primarily are filing
systems. People in the computer business say they're not really computers,
they are "data handlers". All right. That's nice. Data handlers would have
been a better name because it gives a better idea of the idea of a filing
system. "_

[https://youtu.be/EKWGGDXe5MA?t=278](https://youtu.be/EKWGGDXe5MA?t=278)

~~~
77544cec
In French (and some other romance language speaking countries), a computer is
called an ordinateur(fr)/ordenador(es) as in 'to ordinate' (put in order).

------
opportune
Personally I think large organizations ask algorithmic questions more because
of what it correlates with than what it directly measures (they know most
engineers will not be spending much time solving algorithmic challenges on the
job), so the system is working as intended. But I do think it would be a good
interview question to ask someone to refactor a poorly designed class
structure in order to add a new feature.

------
didibus
If you ask a system design question, an algorithm question, a code structure
and organization question, and some general questions about past work
experience and how they'd handle certain scenarios, you get a pretty good
coverage of a person's abilities I've found.

While I agree a lot of software engineering is about managing large code
bases, it isn't just that, I feel all aspects matter and come into play. And
even code organization exist at different levels: in the small, in the medium
and in the large. It's good to try and get an idea at all levels.

------
bjornsing
The reason few people take up neurosurgery on their own in their spare time is
not that it’s more difficult or requires “intense training”. There is a much
simpler explanation: doing so is deeply immoral, and illegal.

~~~
OnlineGladiator
I've never once thought to myself "I'd really love to perform some
neurosurgery, if only it weren't illegal!" The reason people don't perform
neurosurgery is because people don't have a need to perform neurosurgery - why
think of the consequences of something you never think about in the first
place?

~~~
kragen
Maybe you think that there aren't any humans out there who really enjoy
cutting open their fellow humans' heads with knives, and that neurosurgeons
only do what they do because they're motivated by altruism or money.

If so, you are profoundly mistaken, and probably a lot more optimistic about
human nature than is rationally justifiable.

~~~
OnlineGladiator
I can't remember the last time someone called me an optimist. So where are
some examples of these people that slice up people's brains for fun? If the
law exists for good reason, there must be at least one example of an offender.

~~~
kragen
Most of them, if it's a real passion rather than something they could do
without, have enough self-discipline and concern for others to go through
medical school first, but there's also Jeffrey Dahmer and soldiers. There are
intermediate outlets; Body Worlds, for example, and a friend of mine does
taxidermy as a hobby. On non-human animals he doesn't have to kill because
they're already dead.

~~~
OnlineGladiator
I feel like that was murder and the exploration of bodies was secondary to
that. And other times he was just torturing them because he wanted to torture
them. I meant something more like a person pretending to be a neurosurgeon so
they could attempt to perform surgeries, like removing a tumor. Murderers
desecrating bodies isn't what I would call neurosurgery.

~~~
kragen
Dahmer also performed neurosurgery on some of his victims while they were
still alive, but not in order to torture them, more for power reasons. There
have also been numerous cases of people faking medical abilities (including,
roughly, every doctor before 1800) but I don't think we can unambiguously
attribute any one of them to a strong desire to cut apart human bodies.

~~~
bjornsing
Yea, it’s worth remembering in this context that 1949’s Nobel prize in
medicine was awarded to the doctor who invented the medical intervention we
now call lobotomy.

------
stephc_int13
Algorithms are a valuable part of programming, just like Maths are a useful
part of Engineering.

Most of the tricky/smart algorithms can be learned in a few months by smart
kids.

But real-world, useful software architecture, requires experience and a wide
array of knowledge.

~~~
kragen
> _Most of the tricky /smart algorithms can be learned in a few months by
> smart kids._

This is the opposite extreme from the truth. It's like someone living in a
17th-century small town who imagines that a traveler could meet everyone in
Europe in a few months. You can't even learn most of _the algorithms in TAOCP_
in a few months, much less the entire published literature, still less all the
tricky/smart algorithms that are used in existing software.

~~~
govg
Eh, that's one way to interpret that statements. I think most algorithms that
you would come across usually (sorting / searching / efficient storage), and a
large superset of what could be used in a regular engineering job can be
learnt in a few months. In fact, most CS undergrads take 2-3 courses on
algorithms in their education, which is a few months.

TAOCP and books like that are meant to be a compendium or reference. It would
be like someone claiming "I can learn enough JS to be productive at work in a
year", and then someone refuting that by showing them some obscure feature of
the language no one uses and knows of.

~~~
kragen
The seventeenth-century villager could meet everyone they "would come across
usually" in a few months. Yet every day I meet more people than they would
meet in those few months.

The top-level comment didn't say that most tricky/smart algorithms _a
beginning programmer comes across_ can be learned in a few months, or that
most of the tricky/smart algorithms _they need to be productive at work_ can
be learned in a few months. (For most jobs and for many programming projects,
as Hague points out, you don't need _any_ "tricky/smart algorithms".) They
claimed that _most of the tricky /smart algorithms_ can be learned in a few
months. And that's profoundly false; it's like when I thought I was an expert
at computer programming because I had memorized the constructs of the BASICs
of several different popular home computers.

If you want to organize your programming career so that you never face any
interesting algorithmic problems, you can, easily. That doesn't even mean you
won't face any interesting problems, because many other aspects of programming
are interesting too, like Hague's favorite, videogame user experience design.
But if instead you want to organize your programming career so that you _do_
get to work on interesting algorithmic problems, there are no shortage of such
open problems known, and there is an immense body of knowledge about solutions
to those problems, as well as communities of practice where you can learn to
solve them. Some of them are even quite lucrative.

The top-level comment is saying that this enormous wealth of algorithmic
research simply does not exist; you are saying that it is worthless. Both of
you are deeply mistaken.

------
Geee
I think the assumption is that algorithmic skills are a good predictor of
success in other areas of software engineering.

~~~
rytill
Right? Maybe that assumption is wrong, but you at least have to address it
when criticizing if you want to change minds.

------
Rerarom
We hear this all the time today -- social skills are underrated, technical
prowess isn't everything etc. I agree but on the other hand, if a person likes
algorithmic stuff and can't bring themselves to develop their soft skills no
matter how much they agree on their importance -- towards what kind of
jobs/fields should they turn to?

~~~
MagnumPIG
Even my autistic friends can develop soft skills. If someone can't do it it
means they need help with it, not that they are inherently incapable.

~~~
markus_zhang
TBF it's equally, or maybe even more difficult for those who can but don't
want, to do X, than those who can't but want...

------
erikerikson
An interview needs to determine success in the role initially and as it
changes. As such, it should simulate the daily activities so as to support
effective hypothesis about that success. While the distillation of years of
engineering is the design and implementation of systems and the specific and
most difficult algorithms that will be written during those years we never do
that work in fast forward. In respect to everyone's time we limit interview
lengths. The delta between what would be ideal and what we can afford (or are
willing to invest) is where the high stakes and unhealthy game environment
we've created forms. It is truly a hard problem.

------
anonu
As a co-founder of a fintech company, I absolutely 100% agree with this. When
the company was 1 person, sure, you can revel in how you implemented some cool
data structure or algorithm. But once you scale, none of that really matters
anymore. Organization is more important to get people to work together,
understand each other's code and generally just execute the product....

Also, this recent article from HN is a good pairing with OP's:
[https://www.netmeister.org/blog/cs-
falsehoods.html](https://www.netmeister.org/blog/cs-falsehoods.html)

------
luord
Can't help but agree. I'm aware that knowing about algorithms can be
important, but 99% of the time they're just theoretical knowledge I half
remember from college.

It's getting to the point where I'm not that interested in pursuing a role in
a company if part of the process involves pointless algorithmic tricks.

------
szczepano
Now try to describe it to HR people so they can measure things and write to
excel table like Person A knows 90% Person B knows 50%. Explain that what you
want are lazy people who can abstract the world and peek problems from
different angles. Writing code is only the last step.

~~~
artsyca
Just as any sufficiently complex software system devolves into a half baked
implementation of LISP with an incomplete email implementation, so too does
any sufficiently large organization become a pseudo police state with
secretive protocols and closed room interrogations with files on everyone and
everything

A certain subclass of human thrives in these environs but they don't produce
good quality information systems

------
crb002
Why I advocate CS programs have a MIS style core course on business analysis.
Most programming businesses application development, and even those writing
compilers need the skills.

------
sytringy05
Reminds me of the old adage - when you have good software architecture all the
bugs are right where you expect them to be.

------
rantwasp
this is well known and understood by anyone with a few years of experience.
what I don’t get is why people keep digging their own hole when they know
where this leads.

------
pmoriarty
... and yet algorithm skill is what most employers test for.

~~~
artsyca
It's a bit like the infamous email scam -- it requires a certain kind of
victim in order to be successful

These organizations thrive on a certain kind of candidate who is willing to do
what they're told and not look too far past the perks to question the
direction of management or brand leadership

These questions are not much more than a smokescreen to give the appearance of
propriety while masking all sorts of chicanery below the surface and
optimizing for the sort of engineers who won't think twice to churn out
features on a whim

If it's not algorithms it's some sort of arcane language specification or some
other meaninglessly specific bit of trivia

