13 ms·

Organizational Skills Beat Algorithmic Wizardry (2013)

165 points by rrampage 7y ago

teucris 7y 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 7y 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.
- deleted 7y ago
  [deleted]
- BrissyCoder 7y ago
  Yeah they do, I recently got asked "How would you calculate the volume of a point cloud?" in a software development interview.
rantwasp 7y 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 7y ago
... and yet algorithm skill is what most employers test for.
- artsyca 7y 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 7y 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 7y 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.
- erikerikson 7y 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 7y ago
  Any resources you would recommend?
  - monkeycantype 7y 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.
erikerikson 7y 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 7y 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 7y 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_zhang 7y 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...
- opportune 7y 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 7y ago
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
ErotemeObelus 7y ago
Blogwarts's School of Algorithmics and Wizardry.
stephc_int13 7y 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.
- kragen 7y 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 7y 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.
    - kragen 7y ago
      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.
fest 7y 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-Anniversary/dp/0932633498 https://www.amazon.com/Introduction-General-Systems-Thinking... 1: http://article.sapub.org/image/10.5923.j.ajss.20150401.02_001.gif http://article.sapub.org/image/10.5923.j.ajss.20150401.02_00...
jkuria 7y 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_zhang 7y 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 7y 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 7y ago
I think the assumption is that algorithmic skills are a good predictor of success in other areas of software engineering.
- rytill 7y ago
  Right? Maybe that assumption is wrong, but you at least have to address it when criticizing if you want to change minds.
bjornsing 7y 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.
- OnlineGladiator 7y 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?
  - kragen 7y 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.
    - OnlineGladiator 7y ago
      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 7y ago
        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.
opportune 7y 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 7y 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.
- artsyca 7y 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 7y 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 7y 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 https://youtu.be/EKWGGDXe5MA?t=278
- 77544cec 7y 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 7y 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 7y 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 https://www.netmeister.org/blog/cs-falsehoods.html
sytringy05 7y 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 7y 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.

165 points by rrampage 7y 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 7y 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.
deleted 7y ago
[deleted]
BrissyCoder 7y ago
Yeah they do, I recently got asked "How would you calculate the volume of a point cloud?" in a software development interview.

rantwasp 7y 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 7y ago

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

artsyca 7y 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 7y 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 7y 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.
erikerikson 7y 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 7y ago
Any resources you would recommend?
- monkeycantype 7y 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.

erikerikson 7y 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 7y 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 7y 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_zhang 7y 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...
opportune 7y 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 7y ago

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

ErotemeObelus 7y ago

Blogwarts's School of Algorithmics and Wizardry.

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

kragen 7y 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 7y 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.
  - kragen 7y ago
    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.

fest 7y 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-Anniversary/dp/0932633498 https://www.amazon.com/Introduction-General-Systems-Thinking... 1: http://article.sapub.org/image/10.5923.j.ajss.20150401.02_001.gif http://article.sapub.org/image/10.5923.j.ajss.20150401.02_00...

jkuria 7y 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_zhang 7y 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 7y 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 7y ago

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

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

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

OnlineGladiator 7y 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?
- kragen 7y 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.
  - OnlineGladiator 7y ago
    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 7y ago
      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.

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

artsyca 7y 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 7y 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 7y 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 https://youtu.be/EKWGGDXe5MA?t=278

77544cec 7y 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 7y 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 7y 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 https://www.netmeister.org/blog/cs-falsehoods.html

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