11 ms·

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 fu

by Felz 8y ago

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.

robinhoode 8y ago
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.
- Filligree 8y ago
  > 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.
  - matz1 8y ago
    If there are 2 candidate, one can remember stuff and other don't, everything else being equal, who are u going to pick?
    - closeparen 8y ago
      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.
      - matz1 8y ago
        If you only can hire one?
        hnuser355 8y ago
        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 Or 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
        throwawaymath 8y ago
        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.
        hnuser355 8y ago
        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
0815test 8y ago
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.
- qnsi 8y ago
  You are obviously right. Anyone that ever did some spaced repetition should know it
xtracto 8y ago
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
- pjmlp 8y ago
  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.
- JustSomeNobody 8y ago
  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.
- matt2000 8y ago
  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.
hn_throwaway_99 8y ago
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.
- zdragnar 8y ago
  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.
- 8y ago
nickjj 8y ago
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.
- femto113 8y ago
  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.

by Felz 8y ago

robinhoode 8y ago

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.

Filligree 8y ago
> 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.
- matz1 8y ago
  If there are 2 candidate, one can remember stuff and other don't, everything else being equal, who are u going to pick?
  - closeparen 8y ago
    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.
    - matz1 8y ago
      If you only can hire one?
      - hnuser355 8y ago
        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 Or 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
        throwawaymath 8y ago
        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.
        hnuser355 8y ago
        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

0815test 8y ago

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.

qnsi 8y ago
You are obviously right. Anyone that ever did some spaced repetition should know it

xtracto 8y ago

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

pjmlp 8y ago
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.
JustSomeNobody 8y ago
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.
matt2000 8y ago
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.

hn_throwaway_99 8y ago

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.

zdragnar 8y ago
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.
8y ago

nickjj 8y ago

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.

femto113 8y ago
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.