Over the years I’ve heard some good advice on this sport of thing attributed to Bertrand Meyer. I keep meaning to track down citations.
There are conversational styles you can apply to code that make it simple to test (or in his case, make coherent assertions about) that still keep the methods small but cleave it in a way that you can still track in your working memory.
It’s a style I aspire to, and put a great deal of time and energy into. But reading my old code I can say it’s harder than it sounds and it doesn't sound that easy to begin with.
I’m a fan of KISS and I spend an inordinate amount of time getting people to reframe problems in a manner that meets the needs more directly (straightforward is on the road to real simplicity, and is a good place to stop if you can’t reach the destination).
But I can’t agree with this observation. There are a lot of smart people who are bored and solve a problem we never had to keep from going nuts, but the solution is so complicated it drags everybody else down.
But there are also a lot of people out there who think that if you pretend hard enough that our problems are simple, then a simple solution can be used.
If you oversimplify the problem enough, everything looks easy.
"Implement a method that shuffles a list"
vs.
"Shuffle a list"
I would want the candidate to ask me whether they can use their language's standard library. I would say no/yes depending on how the question is framed.
The absolute worst is when question is framed like 1) - the candidate just makes an unwanted assumption, and then acts outraged or smug when I tell them I expect them to demonstrate that they aren't oblivious to the underlying implementation.
Then we venture off whether they can make improvements/trade-offs if the list becomes 10K, 1MM, 1B, etc. records of N bytes etc.
I have to agree with this comment. More often than not one-liner rewrites of even trivial functions are unreadable and can't easily be modified, all for the sake of having the appearance of elegance. It's more important to have code that is easily understandable and extendable, which isn't always the case with fewer lines of code.
For example I could write a massive list comprehension in Python in one line that could solve my problem, but it would be much more difficult to read and would be a pain to modify. I'd much rather work with the 10 lines of code it would take to actually spell it out.
Coming from a (primarily Windows) desktop development background, I can definitely tell you that JS/HTML/CSS and the DOM is some of the most complex, over-engineered stuff to ever see the light of day. It seems simple, but that's because it was simple initially, and now it's grown into this monster that has very little design at all and is just piles and piles of APIs and code added on top of other APIs and code.
Desktop development is blessedly simple, in contrast. The problem is that desktop development APIs and UI toolkits have been neglected for many years in favor of web and mobile, so now desktop development is also a fractured mess because much of it is outdated or hasn't kept up with current graphic design and UI standards. But, at its core, desktop development doesn't struggle with oddball concepts like promises and other bizarre features that were introduced to overcome issues with the overall design of the language/environment.
I said, "Given two candidates with all things equal except ..."
I mean if there are two candidates who are equally motivated and are more or less equal in all things except that one is strong at CS fundamentals and another isn't, is there a good reason to reject the candidate who is good at CS fundamentals.
In many hiring decisions, I am faced with a similar choice, and I go for the person who is good at CS fundamentals. If two candidates are good in all other ways, then the understanding of CS fundamentals becomes a tie breaker. I see no rationale for selecting the guy who does not demonstrate his strength in CS fundamentals.
For example, I know a heavily right-brained person, and when he reads a book, instead of the intuitive sequential pattern (even page-odd page-even-odd-even-odd) he may read it in a zig-zag (even-even-odd-odd-even-even).
The analogy is synchronous processing (left brain) vs multithreaded (right brain).
On the other hand, right-brained people seem to have problems doing 'obvious' things like finishing chores in order, telling left from right or positioning something on a blank page.
Yeah, it's just an opener. Setting the stage, making sure everyone is on the same page, and then you can build onto that à la "and now suppose xyz...".
With most people, it is impossible to gauge how good they are just by observing what they do in half a day on the job. Thus, any interview process must necessarily be somewhat artificial in trying to gain insight into a candidate's abilities in the span of a half a day.
A real life task might be implementing a much more complex library over several days or weeks. Asking the person to implement a simple function like shuffle is the closest you can get in the span of an hour.
Yup. If I get even the slightest inkling of this attitude from the interviewers, I will refuse to join the company. I'll give a pass for one smug interviewer, but if I encounter multiple such interviewers, I assume it's not a company I'd like to work at.
YMMV, but, outside of technical contexts, the phrase "increased exponentially" is often used by people who don't even know the difference between linear, geometric and exponential growth. In many cases they don't even understand that the word "exponential" refers to a rate of growth, if they've heard of the concept.
Take the context of a high-profile art magazine, Frieze. (I googled "frieze increased exponentially"). This is shooting fish in a barrel—but the most egregious example in the first page of hits is this one:
"Seppie in nero’ – squid in its own ink – is my favourite Venetian delicacy. Although customarily served with polenta, I prefer it on thick spaghetti since pasta exponentially increases the naturally squirmy quality of the creatures’ tentacles, creating a Medusa-like mound of inchoate, salty matter."
So you've got an art critic writing slightly pretentiously about food, and he throws in an "exponentially" which has nothing to do with a rate.
This and similar usages of "exponentially" are extremely widespread now. People talk about exponential increases without any mental model of the rate of growth as a function of time at all—just the woolly idea that something is growing fast.
"The term "exponentially" is often used to convey that a value has taken a big jump in short period of time, but to say that a value has changed exponentially does not necessarily mean that it has grown very much in that particular moment, but rather that the rate at which it grows is described by an exponential function."
I've spent a fair amount of time interviewing in London a few years ago. I would literally go to any company that send me an e-mail or contacted me via recruiters.
I didn't have enough money to buy new clothes at the time, so instead I've picked the shoes with the largest amount of holes and would never do any grooming before hands. I would come stoned to the interview. So the gist: instead of trying to appear on the lower mid end, I went all the way through to the lowest low end.
Thinking retrospectively I think that's pretty much the reason why I barely received any negative responses unless I had miserably failed at the technical side of things (e.g. I didn't know how to use generators in Python at the time and the whole list of questions would be about them and their syntax).
I have to admit that in this scenario I was quite good at the technical side of things. But the general philosophy was that if I don't try to appear too good - people will assume that I was better. Put humility and definite sprinkle of character on top of that.
I've come to the same one. I think it explains a great deal of what we see. Even in the hiring process and such. It's actually very primitive at its core. Who's part of who's tribe and who is jockeying for status in that tribe.
Same with Rust, to some extent -- in some cases it's extremely hard to get a program to compile, fighting with borrow checker along the way, but when it's done and done you can be fairly sure it won't segfault due to a dangling pointer or something stupid of the sort. It also makes it easier for you to trust the code written by others, e.g. when working on a large codebase collaboratively.
Rust is another favorite of mine, and with Rust you also get efficiency besides correctness and reusability.
I wish Rust would have gone with an ML syntax though, in particular the Hindley-Milner type signatures allow me to reason better about code reusability, the "fn" and braces just adds noise to me, too much Haskell I guess.
20 comments
[ 3.4 ms ] story [ 44.8 ms ] threadThere are conversational styles you can apply to code that make it simple to test (or in his case, make coherent assertions about) that still keep the methods small but cleave it in a way that you can still track in your working memory.
It’s a style I aspire to, and put a great deal of time and energy into. But reading my old code I can say it’s harder than it sounds and it doesn't sound that easy to begin with.
But I can’t agree with this observation. There are a lot of smart people who are bored and solve a problem we never had to keep from going nuts, but the solution is so complicated it drags everybody else down.
But there are also a lot of people out there who think that if you pretend hard enough that our problems are simple, then a simple solution can be used.
If you oversimplify the problem enough, everything looks easy.
I would want the candidate to ask me whether they can use their language's standard library. I would say no/yes depending on how the question is framed.
The absolute worst is when question is framed like 1) - the candidate just makes an unwanted assumption, and then acts outraged or smug when I tell them I expect them to demonstrate that they aren't oblivious to the underlying implementation.
Then we venture off whether they can make improvements/trade-offs if the list becomes 10K, 1MM, 1B, etc. records of N bytes etc.
For example I could write a massive list comprehension in Python in one line that could solve my problem, but it would be much more difficult to read and would be a pain to modify. I'd much rather work with the 10 lines of code it would take to actually spell it out.
Desktop development is blessedly simple, in contrast. The problem is that desktop development APIs and UI toolkits have been neglected for many years in favor of web and mobile, so now desktop development is also a fractured mess because much of it is outdated or hasn't kept up with current graphic design and UI standards. But, at its core, desktop development doesn't struggle with oddball concepts like promises and other bizarre features that were introduced to overcome issues with the overall design of the language/environment.
I mean if there are two candidates who are equally motivated and are more or less equal in all things except that one is strong at CS fundamentals and another isn't, is there a good reason to reject the candidate who is good at CS fundamentals.
In many hiring decisions, I am faced with a similar choice, and I go for the person who is good at CS fundamentals. If two candidates are good in all other ways, then the understanding of CS fundamentals becomes a tie breaker. I see no rationale for selecting the guy who does not demonstrate his strength in CS fundamentals.
For example, I know a heavily right-brained person, and when he reads a book, instead of the intuitive sequential pattern (even page-odd page-even-odd-even-odd) he may read it in a zig-zag (even-even-odd-odd-even-even).
The analogy is synchronous processing (left brain) vs multithreaded (right brain).
On the other hand, right-brained people seem to have problems doing 'obvious' things like finishing chores in order, telling left from right or positioning something on a blank page.
A real life task might be implementing a much more complex library over several days or weeks. Asking the person to implement a simple function like shuffle is the closest you can get in the span of an hour.
Take the context of a high-profile art magazine, Frieze. (I googled "frieze increased exponentially"). This is shooting fish in a barrel—but the most egregious example in the first page of hits is this one:
"Seppie in nero’ – squid in its own ink – is my favourite Venetian delicacy. Although customarily served with polenta, I prefer it on thick spaghetti since pasta exponentially increases the naturally squirmy quality of the creatures’ tentacles, creating a Medusa-like mound of inchoate, salty matter."
So you've got an art critic writing slightly pretentiously about food, and he throws in an "exponentially" which has nothing to do with a rate.
This and similar usages of "exponentially" are extremely widespread now. People talk about exponential increases without any mental model of the rate of growth as a function of time at all—just the woolly idea that something is growing fast.
"The term "exponentially" is often used to convey that a value has taken a big jump in short period of time, but to say that a value has changed exponentially does not necessarily mean that it has grown very much in that particular moment, but rather that the rate at which it grows is described by an exponential function."
https://books.google.ie/books?id=aVovDwAAQBAJ&pg=PA36&lpg=PA...
The battle is lost on this word, as it is with "literally". To the man on the street "exponentially" really just means "a huge amount" now.
I didn't have enough money to buy new clothes at the time, so instead I've picked the shoes with the largest amount of holes and would never do any grooming before hands. I would come stoned to the interview. So the gist: instead of trying to appear on the lower mid end, I went all the way through to the lowest low end.
Thinking retrospectively I think that's pretty much the reason why I barely received any negative responses unless I had miserably failed at the technical side of things (e.g. I didn't know how to use generators in Python at the time and the whole list of questions would be about them and their syntax).
I have to admit that in this scenario I was quite good at the technical side of things. But the general philosophy was that if I don't try to appear too good - people will assume that I was better. Put humility and definite sprinkle of character on top of that.
I've come to the same one. I think it explains a great deal of what we see. Even in the hiring process and such. It's actually very primitive at its core. Who's part of who's tribe and who is jockeying for status in that tribe.
There are some other aspects to this idea of code economy: correctness and reusability. This definitely depends on the programming language.
In Java(or oop for that matter) you can get correctness but to get reusability you need a whole hierarchy of classes, lots of added code/cost.
In Python you get more reusability out of the box but to get correctness you need to add swaths of unit tests, lots of cost.
In contrast with a functional language such as Haskell you get both with less effort, fp plus a rich type system reduce code enourmosly.
I wish Rust would have gone with an ML syntax though, in particular the Hindley-Milner type signatures allow me to reason better about code reusability, the "fn" and braces just adds noise to me, too much Haskell I guess.