SoylentNews is people
SoylentNews
I've historically always tried to stick to one or two big languages, because as soon as I start deviating even for a week, I go back to my primaries and find that I, humiliatingly, have forgotten things that anyone else would be completely incapable of forgetting. Now, I'm going to be learning assembly, since that kind of thing falls in line with my interests, and I'm concerned about forgetting big chunks of C while I learn. I already often have the standard open in a tab constantly despite using C since 2012, so my question is, how do you guys who are fluent in multiple languages manage to remember them? Have you been using both for almost forever? Are you all just mediocre in multiple languages rather than pro in one or two?
This discussion has been archived.
No new comments can be posted.
Remembering Multiple Programming Languages?
|
Log In/Create an Account
| Top
| 52 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
"The subspace _W inherits the other 8 properties of _V. And there aren't
even any property taxes."
-- J. MacKay, Mathematics 134b
(Score: 5, Informative) by VLM on Monday April 07 2014, @03:14PM
Its exactly like literature or math where the first time takes forever and it seems impossible, and the twentieth time you glance at a google search result just to make sure and you're right back up to speed.
Ditto big old codebases... Took days to write this three years ago and I haven't looked at it since... it'll only take an hour to totally understand it again next time around, if that, not days.
There's also a level of detail, like memorizing geography. Its kind of important to remember printf has an octal output format character, well, kind of. But in the era of google its far more important to remember that it exists, than to memorize its a lowercase "o".
Fixing compile time bugs because you forgot if SQL INTERVAL are plural or singular takes seconds, at most a minute. Fixing architectural bugs can take weeks/months. So invest your time and memory bandwidth appropriately. Especially domain specific / business analyst type requirements need to be memorized.
Getting the syntax perfect in a n ** 3 algorithm is pointless if you should have been storing up the brain cells to implement a log n, maybe with a few dumb typos to fix at compile time that'll only take seconds or minutes to fix.
Memorize features and abilities and geographies, sorta. Maybe limitations. Don't sweat the small stuff.
It is very much like moving to a new city and trying to find your way around.
(Score: 1, Interesting) by Anonymous Coward on Monday April 07 2014, @04:13PM
Some job interviews require you to sweat the small stuff though. e.g. write a simple working C or C++ program on a whiteboard without looking stuff up...
I can't do that and I'm not a good coder so I'd rather not work for such places anyway. BUT I often have a good idea of what should be done though. For example in a previous workplace I had just joined the company and they were discussing what a new system should do before it figured out which port a client was attached to. They were initially on the side of showing something to the client ASAP in the interest of responsiveness. But I said we shouldn't - it's much better to wait first. We avoid showing clients the wrong thing[1] and we avoid race conditions. Fortunately I managed to convince them to do it that way.
[1] Yes initially we may only need to show all clients the same thing no matter what port they are on, but once we build the system that way it's harder to change it later on if we need to do things differently. Plus we still can't let clients do anything further till we figure out what port they are on anyway, so we gain little, and the users might get confused and complain (see first page immediately but not be able to do stuff). Better to not show them anything first.
(Score: 3, Insightful) by VLM on Monday April 07 2014, @04:28PM
"Some job interviews require you to sweat the small stuff"
Invariably the kind of place that puts you thru a wringer writing a syntactically correct python implementation of a B-tree is the kind of place that wants you to write RoR CRUD apps. Not that there's anything wrong with Btrees or CRUD apps or python or ruby, its just the presence of that kind of stuff implies the actual job requirements will have nothing to do with the interview, which makes your intel gathering way harder. Its a bozosity bogosity warning indicator. Might still be a nice place to work, if only their interviewing is screwed up. But, certainly a warning sign to keep a look out.
So ... I read my Sedgewick and my Knuth now wheres the completely unrelated job that entitles me to?