Organizational Skills Beat Algorithmic Wizardry (2013) | Hacker News Reader

Organizational Skills Beat Algorithmic Wizardry (2013)

prog21.dadgum.com

165 pointsrrampage53 comments

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.

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.

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.

Any resources you would recommend?

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.

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

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

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.

Was the pain worth it in the end?

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.

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

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

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

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

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

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

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.

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.

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.

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

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.

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

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

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

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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?

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.

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

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.

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.

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

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.

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.

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

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.

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

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.

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

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

Reply on news.ycombinator.com