I've been an iOS developer for about 5 years. There are still things that NSString and NSArray do that I didn't know they could. All optional attributes and behaviors that I haven't seen, because I've never actually sat down and memorized all of the optionals and capabilities of the NSString class. I know the most of the basic stuff off the top of my head, but I typically google for the fastest way to do it if I can't on the fly. My question is: Do you guys have most of the classes of your most commonly used frameworks memorized? (For me it would be Cocoa Touch). Does this have any effect on the classification of "level" of programmer you are? Technically I'm a senior and do well at my job but the above makes me wonder... Who's on the same page, if anyone?
-
1@gnat where do you see the duplicate in this case? It's, of course, related. – Wolf Jan 08 '15 at 11:13
-
Knowing the answer vs knowing where to find the answer. You are more productive when you can rattle off classes, methods, and parameters without a reference doc, but it's unreasonable to think you can or should memorize everything. Be aware of optional parameters, and less commonly used classes and methods, but if you don't use them frequently enough to memorize from repetition, then it's probably not worth memorizing. Knowing something exists and looking up the details is faster than finding something for the first time. So study the API, be familiar with it, but don't memorize it. – LLL79 Jan 08 '15 at 20:20
6 Answers
I've been programming professionally for 20 years, and I am still amazed at how much I don't know. My strongest languages are C++ and Perl, and I know the basics of the language extremely well, but then there's STL and Boost which I have to look up all the time, and all of CPAN which I peruse occasionally and am always happy to find someone else has already made a module for the code I'd been writing for a week.
Languages, APIs, and Other People's Code (OPC) are always coming and going, evolving and dying. My 20 years experience would amount to nothing if all I could do was spout with 100% accuracy the properties and methods of this year's popular twist on development. Learn how to program beautifully with the tools you have, and don't worry if you don't know everything about every class. Odds are some new API will be introduced eventually that makes obsolete the API you've spent thousands of hours learning and mastering.
Windows used to be a C-based API, so I learned Windows API, then Win32. Then it went to C++ in Borland so I learned OWL. That didn't turn out well, so I learned MFC. Had to learn OLE then OLE2 then COM then .NET. What's next? Apple is turning to Swift. I don't know anything about it, so this might be inaccurate: Time to abandon your Cocoa Touch?
I'm sure any old timer has similar stories. Whatever. Learn to program, use all you know of the available APIs, embrace new knowledge as you find it, but don't kill yourself learning every last piece of it, 'cause it might not be relevant in a few years anyway.
- 121
- 2
-
1Well explained! I know these stories, but I think there is something valid that remains, and [I tried to make a positive statement](http://programmers.stackexchange.com/a/269412/106929) – Wolf Jan 08 '15 at 11:10
-
I have about the same number of years experience as Wonderful Wawb, and a different set of stacks I've worked in. I would assert that there's a tipping point on any language/API where each additional thing you memorize makes you more of a love slave to that language/API, and that's (generally) a bad thing. You need to be productive, but you have to balance that with the fact that every API or language has a shelf life of about 5 - 10 years. You don't want to be the guy that knows everything about a dead or dying language, trying to promote it when nobody wants to use it any more. – Calphool Jan 08 '15 at 19:19
I'm a C#/.Net developper.
.Net is HUGE so I don't beat myself up for not knowing all of it inside and out. That said, because I've been focusing on mostly desktop/server business apps for the past few years I'm very familiar with the subset of .Net that solves my typical problems. That's not to say that I don't occasionally discover new gems here and there.
I do periodically find new things (or even old things) that are useful but that I never knew about. For me, these new gems are usually found by reading other people's code -- not by pouring through API documentation.
Other people's code has been my main resource for learning for a long time. Eventually, when I had built up an acceptably solid foundation, I threw myself at crazy blogs like Eric Lippert's.
In my experience, this approach isn't uncommon. About 80% of the devs I meet on the job don't care about progressing as a developper. The other 20% seem to have approaches more or less identical to mine. And yes, that involves googling anything I don't know off the top of my head.
I wouldn't worry too much if I were you. The mere fact that you think about these things enough to ask a question on here is a very good sign.
- 11,549
- 3
- 44
- 75
-
1It's not *that* crazy. :-) And I am with you; I certainly do not know anywhere close to the whole .NET framework. – Eric Lippert Mar 02 '15 at 22:35
Concentrate on the problem-to-class path.
Prefer grasping concepts and patterns over memorizing class details, because these first are much more portable than the latter. Sure you'll know the details of classes you use on a daily basis, but you'll not be able to keep track of all classes of your (future) framework(s).
A house may be defined as consisting of bricks (or even atoms), but this doesn't help much when building one. Classes are of course much more abstract than single lines of code, but memorizing all its facets is overhead, just memorize key classes.
Most probably, your memory for plain facts will decrease with increasing age, whereas your ability to integrate knowledge (if well-developed) will stay some longer.
- 630
- 1
- 6
- 24
Yes, I can tell you off the top of my head probably 80% of the operations are on the things I use day to day. After all, how can you plan to build something if you don't know what your tools are?
Though to be fair, I have an exceptional memory.
- 108,850
- 29
- 239
- 365
Most of my knowledge is in the world, as opposed to in my mind.
I mostly do .net. Unlike Telastyn, I probably only have about 20% of what I use regularly memorized. The rest, I know just barely enough that intellisense can pull up the rest that I need, which is just as fast as had I memorized it. That knowledge is what's in the world.
Other times, working on python for example, a greater percentage is memorized, however, that comprises much less than what's immediately accessible in C#. That knowledge is in my mind.
In neither case do I expend any effort commuting things to rote memory. All of it is memorized through osmosis, simply by using it repeatedly enough.
- 27,463
- 14
- 73
- 93
Fluency should be something to strive for in the language you're using. I'm not sure if you differentiate knowing things exist and memorizing them. When someone says memorize I usually think of exact naming, syntax, etc. To me there is a greater difference between a developer who doesn't even consider to Google a capability of a language/framework to one who needs a "cheat sheet" or reference to actually write code than there is between the ones who need some reminders and those that have it all memorized.
Some people have better memories than others. Some put more effort into memorizing things, but I think a developer who has developed fluency with a language is demonstrating a lot more experience. If you claim to be a senior developer who is current working with a particular language, but you're not really sure how to write and IF statement, you'd be suspect.
- 36,816
- 2
- 57
- 124