Hacker News Reader

Comment by Felz | Hacker News Reader

Memorizing APIs is... not how I'd approach productivity, but if it works for you, great.

I'm doing a lot of Kotlin right now, where simple, useful extension functions are an autocomplete away. I don't need to memorize how to get a slice of an array; I know it's going to be named something like .slice(), and I can jump right to the documentation from my IDE.

When I run into something not in the standard library, I write a little extension function of my own. And then I remember it the next time I run into that problem, and get to reuse it, just like it were part of the language.

View on HN

There are a bunch of comments in support of your viewpoint, so I'll put in a counter argument. People who have very good memories for lots of programming language and API details are just faster, and faster does translate into higher productivity if you are indeed good at the other parts of your job.

For any programming language, I consider the following pretty essential APIs that you are going to use over and over:

1. Details of primitives and built-in "base" objects and related functions (e.g. strings, numbers, object literals, dates, etc.) 2. Collection libraries (arrays, dictionaries, sets, etc.) 3. Details of async libraries (e.g. in JS everything in Promise, how that applies to async/await). 4. Streaming libraries. 5. For OO languages, details around class creation/construction 6. Language specific details that are important (e.g. for Javascript I would put things like which values are falsy, Function prototype values like apply, bind, etc.) 7. Default common 'util' libraries, like lodash for JS and Apache commons for Java (not necessarily saying you know every single function, but you generally know which functionality groups are there).

Yes, you can look those up, but if you have a good memory for what the slice() function is and what you can do with it you will be faster than someone who has to look up the details every time you want to use it. In addition, knowing the general API surface means you know instantly what tools are available to you vs. what you'll need to create or get from an alternate library.

As a counter-counter argument,

More time should be spent thinking than typing; specifically, reasoning through the problem domain and appropriate solutions. Having surface APIs memorized is going to save less time than having a well of experience to draw upon thinking through correct or best solutions.

Beyond that, you identified a ton of areas of APIs that are useful to know, but if you understand the fundamentals behind the ideas (i.e. how to use arrays to solve problems, when to get a subset from them, how promises and futures differ from streams, etc) you're 90% of the way there. I think it's less about memorizing the API specific words and knowing the language of the paradigm.

I might be splitting hairs a bit on that last point, since they're pretty closely related. But, I think a 10x developer is going to be better distinguished by knowing when to use a future vs. a stream, rather than simply knowing the API method names and signatures for a particular library / language.

In a corruption of a Steve Yegge saying, most programmers are CPU-bound rather than I/O-bound. Very rarely has my code typing speed inhibited my productivity. Understanding which problem I need to solve, and doing the research takes up the bulk of my programming time. Actually writing the code is a formality after that.

I think you have to separate the I from the O. Output, i.e. typing, is not a bottleneck. Input, that is domain and API research, can be a huge one, especially if you're a "full-stack" or generalist engineer where task switches cause information to get swapped out all the time. If you only have to do a task once every few months, you're going to struggle with retention.

'CPU-bound' I would say is where you have all the pieces you need to solve a problem, but the precise solution is tricksy or math-heavy. Such problems are relatively rare in day-to-day programming. So I would say that on the contary, most programmers are I/O bound most of the time.

I don't think memorizing is to type faster. It's to think faster. CPUs speed up with more cache. Adding in a websearch/API lookup in-between thoughts will slow a programmer down.

I am a generalist. After programming in A LOT of languages through my 20+ year career, I have given up in memorising any language specific features (APIs, syntax, etc)

Every time I need to write something in a new language, I grok it and write on it with a handy syntax /API/SDK reference.

For me, The things worth remembering are the patterns used to solve stuff, not how the patterns are implemented in a specific language

Also a generalist.

I do follow the same approach.

As Nicklaus Worth stated, knowing algorithms and data structures is more relevant as specific language features.

I mostly program in C#, python and JavaScript. By mostly I mean slightly more than half the time. The rest is old C++, old Java, old Perl, BASH, etc. I gave up a long time ago trying to remember the APIs/Libraries for all of those. Most programming is doing something slightly different to some other thing you have done before. I make it a point to remember how I do things, so that no matter the language, I can get it done. This also helps tremendously with estimates.

I'm in your category as well. An unfortunate side effect of this is that I think I'm kind of terrible at technical interviews though.

The example flashcards in this post are a bit confusing, and not really aligned with spaced-repetition best practices. First of all, you really want the "answer" side of a flashcard to be as simple as possible so that it's unambiguous what you're expected to recall, and you can make that determination as quickly as possible. Then, the "question" side should be simple as well, to speed up reviewing and make the knowledge that's being committed to memory as generally-applicable as possible. So I'd fix the first example to say something like:

  no-clobber
    
  note: existing files or objects at the
  destination are not overwritten, and are
  reported as being skipped.
  note: makes an extra GET request before
  uploading an item. this may adversely
  impact small transfers, or save data if
  large transfers can be avoided.

For the second example I'd simply adjust the code sample as:

  var fruits = ["Banana", "Orange", "Lemon", "Apple", "Mango"];
  var citrus = /* ??? */;

with only the `fruits.slice(1, 3);` part on the answer side.

You are obviously right. Anyone that ever did some spaced repetition should know it

Reading that line made me cringe. Memorizing APIs come in handy for interviews or perhaps fixing bugs in production but not so much for day-to-day work.

Now, math equations or the minute details of data structures and algorithms.. Those can be hard to internalize and knowing them well is very helpful when reading papers or other diving into open source projects which make critical use of advanced, specialized knowledge.

> Memorizing APIs come in handy for interviews or perhaps fixing bugs in production but not so much for day-to-day work.

Some interviews, maybe. As you say, it doesn't matter much for day-to-day work -- and so I put no weight on it when rating interviews either. If the candidate remembers the right method names, great. If they don't, who cares.

I always make a point of explaining that I'm not testing them on API memorization.

If there are 2 candidate, one can remember stuff and other don't, everything else being equal, who are u going to pick?

Both. Tech companies are ravenous for anyone and everyone who clears the bar; “choose the best from N applicants” is not a model for the hiring process.

If you only can hire one?

Was it Seneca who mocked this line of thinking? If I remember right he mocked it by saying either

1) a good man is a good man and thus equal to other good men

2) you proceed through so many qualifications and “but what if this guy was prettier or had nicer tone of voice than the other good man all else equal” etc until you admit that you include minute details like the exact placement of every hair follicle on some dudes head in your proposed total ordering of humanity

I'll admit there's probably an argument against that method of evaluation, but I'm not exactly blown away by Seneca's arguments.

In particular, I'm not convinced the evaluation must extend from arguably relevant features to obviously irrelevant features. Even if I'm ultimately wrong, I can mount a defensible argument that memory is relevant to programming ability. I do not see a way to mount a defensible argument that (for example) facial features are relevant to programming ability.

His pretty face might leave your superiors with a better impression of your group. A friend manages a software group and actually told me that one of the best things to increase chances of getting a job with her group would be to pay more attention to my appearance and smile more. Also mentioned that just being interpersonally nice was much more important than actual abilities in her organization as long as you were good enough that the owners believed you knew what you were doing and she could justify keeping you there. Etc

Here's one - attractiveness is roughly correlated with intelligence, and in the general case positive traits tend to correlate. An interview is an attempt to extract the maximum amount of information about a candidate in a short space of time. Virtually any positive trait is evidence that somebody will be a better candidate. Weak evidence, yes - but if you have two otherwise completely identical candidates (a silly hypothetical) it's not illogical to choose the one with better hair follicles (a silly outcome of a silly hypothetical).

So choose the one you think it's better, for me its the prettier one. What's wrong with that? It's better than just flipping a coin.

Hopefully the candidates realize that the interview is only the first of many shitty zero-sum games, and they opt for growing positive-sum companies instead.

Or the candidate realize that this is something they too can learn to improve themselves instead of dismissing it.

Improving oneself is a good frame for this. There are so many important and subtle and deep aspects of the craft to improve at. I want to work with people who recognize this and allocate their self-improvement efforts wisely.

Studying API trivia to show off in interviews is about as far off as it gets. So probably I’d choose the candidate who hadn’t done that. I’d rather risk a lazy coworker than one who fixates (even if competently) on the wrong problems. I’ve seen coworkers with that trait seriously drag down a team with low-signal nitpicking on others’ pull requests and designs, for example.

API knowledge is ideally a consequence of familiarity with the craft. Sort of like how vocabulary is a consequence of reading, writing, and interacting with well-read people. I’d rather have a conversation with someone who reads a moderate amount than with someone who decided to memorize the dictionary. The former knows fewer words, but I expect they’ll have more interesting things to say, even if none come across in the first 30 seconds.

Yes studying api trivia doesn't have much use. These stuff doesn't need to be memorized. Ideally you memorize stuff that important to you and likely useful for you.

Let's use your example of memorizing dictionary in some foreign language x. This person will be able to read faster and more efficiently without having to stuck on some unknown word and looking up dictionary every 2 minutes. At this state this person is just simply reading and focusing the brain on the content itself.

Likewise with memorizing programming stuff, the person can now just simply code and freeing the brain to just focus on the problem. Consequently more time to code moderate amount and ensure familiarity with the craft. I think this so called the 10x engineer that the author mentioned.

Remembering stuff is important, but in an interview, all I expect is that the candidate can remember what they discussed 10-20 minutes ago (in the same interview), and that they use a credible looking syntax that's self-consistent; and that they can explain anything they wrote.

I also give a problem that doesn't use a lot of library functions.

The one that will be a better team member.

This relates to my most hated interview question - "If someone else can do what you do but they also have X quality why should we pick you?" Which always makes me want to contemptuously exclaim "Well obviously you shouldn't, fool!"

I have never actually gotten a job where the interview had a variation of that question.

on edit: changed explain to exclaim, don't think it significantly changed the meaning in context however.

I would never sit there and try to memorize the API of a language or tool but after you use it long enough, it really really speeds things up drastically if you can recall things mentally instead of having to look it up.

At this point I can sit down and bang out entire Ansible roles (hundreds of lines of YAML) without having to reference the docs or even use auto-complete for 95% of it. It's really a joy when you can just focus on getting what you want down in code and have it work in the end -- without interruption.

I'm with the author here in that I am very jealous of anyone who can memorize things like that without putting in years of practice. It's not just a speed boost, but you feel good about yourself being able to just hack on something for 20 minutes without having to look a single thing up. It takes a LOT of repetition for me to get to that point.

I gave up on memorizing APIs long ago (like I regularly have to look up how to lower case a string in languages I've used daily for years). This was triggered by regularly moving between multiple languages with confusing levels of similarity (e.g. ",".join([1,2,3]) vs. [1,2,3].join(",")) where it was impossible to keep straight. However this does not meaningfully impact my productivity because I 1) have gotten really fast at looking stuff up if needed and 2) the tools I use make it really easy to find and adapt similar code that I've written before. I really think programmers will in general gain much more by taking the time to understand the code they are working on (importantly including the code all the other people on the project are writing) than on low level APIs. The latter can be explored with Google and Stack Overflow, and generally safely assumed to do what it says on the tin, but the former will be the source of endless surprise and confusion.

Reply on news.ycombinator.com