Organizational Skills Beat Algorithmic Wizardry (2013)

https://prog21.dadgum.com/177.html

by rrampage • 7 years ago

165 53 7 years ago

prog21.dadgum.com

teucris• 7 years ago

“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• 7 years ago

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.

BrissyCoder• 7 years ago

Yeah they do, I recently got asked "How would you calculate the volume of a point cloud?" in a software development interview.

rantwasp• 7 years ago

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• 7 years ago

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

artsyca2• 7 years ago

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

BoiledCabbage• 7 years ago

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.

BubRoss• 7 years ago

It's a shame that people get taught the opposite of that approach. Typical academic OO ends up completely obscurring the data you have and how you transform it in to what you want.

Many times when you ask a student to think in those terms they don't even understand the concept of putting all your data in a data structure that is meant to access it instead of being muddied together with little bits of execution that may or may not accomplish something.

erikerikson2• 7 years ago

In an environment where you are also modeling the problem but must do so incompletely as you discover its depths, the iteration of a solution model will always need to be adjusted over time and refined into a better representation of reality. I think if you mean to declare that errors in domain modeling are failures in skill then you aren't accounting for the limitations of humanity in our efforts. I believe we have accepted that refactoring is healthy and to be expected.

astockwell• 7 years ago

Any resources you would recommend?

monkeycantype• 7 years ago

Domain-driven design by Eric Evans gave me a vocabulary set to organise my previously unstructured thoughts about domain modelling into a cohesive domain model of domain modelling.

AzzieElbab• 7 years ago

I can't recommend this enough https://www.manning.com/books/functional-and-reactive-domain...

polishdude20• 7 years ago

As a self teaching developer, are there resources where I can learn more about this?

101008• 7 years ago

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• 7 years ago

Was the pain worth it in the end?

kragen6• 7 years ago

That sounds interesting! In the Departamento de Computación? Is the course still offered?

ThrowMeAwayOkay• 7 years ago

Wow so that course closely followed what happens in real life software development!

bassman9000• 7 years ago

It's an absolute shame it isn't a requirement to get a CS degree.

It was, at least in my Eng school. And the course was called... "Software Engineering" (I & II).

erikerikson2• 7 years ago

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.

Rerarom• 7 years ago

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• 7 years ago

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_zhang2• 7 years ago

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

opportune2• 7 years ago

I suppose you can still do many engineering jobs, but they will just be done poorly.

Unless you are running your own business, you always need to be able to take someone else's high-level understanding of a problem/feature/task and figure out how to implement it. That is true of more than just software development. And if you are running your own business, you need to be able to prioritize problems/features/tasks and figure out how to implement it.

I love solving algorithmic problems, but the vast majority of important (measured by willingness for people to pay you to solve them) problems in the world are not algorithmic. It's actually more important to be able to figure out how to make a service scale efficiently, or add an item to a menu to control overlay opacity, than it is to find the only non-duplicate item in a list in O(n) time and O(1) space.

dang• 7 years ago

Thread from 2018: https://news.ycombinator.com/item?id=16703553

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

stephc_int13• 7 years ago

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.

kragen6• 7 years ago

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• 7 years ago

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.

fest• 7 years ago

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

1: http://article.sapub.org/image/10.5923.j.ajss.20150401.02_00...

jkuria• 7 years ago

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_zhang2• 7 years ago

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• 7 years ago

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.

Geee• 7 years ago

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

rytill• 7 years ago

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

bjornsing2• 7 years ago

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.

OnlineGladiator3• 7 years ago

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?

kragen6• 7 years ago

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.

opportune2• 7 years ago

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.

szczepano• 7 years ago

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.

artsyca2• 7 years ago

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

didibus• 7 years ago

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.

mpweiher• 7 years ago

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

77544cec• 7 years ago

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

crb002• 7 years ago

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.

anonu• 7 years ago

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

sytringy05• 7 years ago

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

luord• 7 years ago

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.

Organizational Skills Beat Algorithmic Wizardry (2013)

Related Stories