
Do pro software devs memorize language syntax? - tomaszs
An article discusses cons of memorizing syntax and provides solutions to boost productivity after all
======
codingdave
I don't go out and actively memorize things, not do I know anyone who does.
But the syntax you use often gets memorized nonetheless, simply through common
use.

~~~
2rsf
That with the IDE's autocomplete covers most of my needs.

------
andrei_says_
Do writers memorize grammar?

Presenting memorization as "learning" is a crippling effect of the limited
ways to measure results forced by the accounting needs of the school system.

Memorization is not understanding and is a very small fraction of the
possibilities of learning.

So, no, of course we don't. We use the language, use the reference when
needed, and little by little, use it less for the beaten paths of our
particular use.

------
grymoire1
Years ago, or perhaps decades ago, when there switching languages every few
months wasn't common, yes - syntax was not only memorized, it was second
nature. Not only that, but the language influenced how you thought and solved
computing problems. I have always felt that it would take about a year to
retrain your brain to efficiently program (or rather think) in a new language.
Until then, you would structure your code as if it was written in the last
language you use, because that's how you break down problems in a logical
nature.

~~~
naniwaduni
There was not a time in the past when switching languages was less common. The
tools of the past assumed one would switch between any number of languages;
each tool would have its own, often maximally powerful, language. This has
become _less_ pervasive as communication and code sharing has become easier,
allowing conventions and standards to unify.

------
gexla
I'll shoot off at a different angle from the other posts here. I'm a blue-
collar dev doing web development. I feel the syntax of the major scripting
languages is relatively small and the amount that you have to know even
smaller. Many developers can just shoot from the hip and get by with some doc
look-ups along the way and get things done. Maybe you don't know the prettiest
syntax, but you can work around it something which works good enough. You
could probably significantly strengthen that grasp with a little bit of
scheduled time doing nothing but leveling up on syntax. Or maybe you never
find the time to do that and you still manage to get things done. And keep in
mind that editors help out a bit with this as well.

I find the difficulty in memorizing is in library usage and all the other
stuff which is outside of the syntax. When I'm getting kicked in the head,
it's maybe trying to remember how to do something in Git. Or maybe I have to
remember the sequence of some development process. Or maybe I forgot a
password I never bothered to enter in my manager. There's loads of things you
get a cognitive beating from, but syntax doesn't strike me as the worst.

~~~
skinnymuch
What does blue collar dev mean?

~~~
gexla
Nothing. But it's my way of saying, didn't study computer science, not an
academic and fully self-taught.

------
ilaksh
Programming since age eight here. I would say that before Google and Stack
Overflow were prevalent, really early on, maybe like in the early 90s, I would
remember things more. Because the alternative was actually looking through a
book, and although I did that plenty of times, it was often more convenient
just to remember.

But as the internet got better at instantly providing examples and references
and more and more technologies came out and I started using many different
programming languages, its at the point where I often Google very basic things
if I am tired or just not 100% sure which way the particular language works or
about all of the details.

Its essentially using Google/the internet as an extension of my brain. Like, I
probably could remember this thing, but why bother? I believe it increases my
productivity because it means I can save my "brain juice" or energy for actual
problem solving.

~~~
toadi
Before I had a reference book of the language. Also I would program always in
the same language before stack overflow.

Now I switch between so many languages. But still use references. But now it's
easier in Dash.app I have references to most of the languages, API, libraries
I use. This way if I want to know how to make if then else syntax work in Go
or Javascript or Python I can look it up super fast. Same for Libraries and
API's.

Now language idioms is something you need to keep on top off. These are better
to remember so you can implement it.

------
jussij
In my many decades working as a professional programmer I have never made a
conscious effort to try an memorize any information relating to programming.

I would also say that if you are finding yourself spending lots of time trying
to memorize programming related information then your approach to programming
is probably wrong.

------
davidjnelson
Stuff you use more often tends to get memorized, less common stuff googled
when you need it. When it’s memorized you do save a lot of time. I’d say if
you’re really experienced in a language you rarely google syntax because 95%
of it has become memorized.

------
Hippocrates
I would say no, but actually it’s a bit more nuanced than that. I use many
different languages and if I am not actively working in one I might forget
some syntax just after a couple of weeks. It only takes about an hour or so of
working in that language (and RTFM) to get it all back. I don’t think others
have as much of an issue if they’re in a single language all day but I jump
around a lot and my hands-on-ness fluctuates.

------
chipuni
It really depends on the software professional.

I do, but I have a terrible memory. I use flashcards to remember names of
technologies that are important but that I don't use daily. I create
flashcards when I make a mistake in programming, so I'm less likely to make
that mistake again. I create flashcards every time I look up information, so
that I keep it in mind.

If you have a normal memory, you probably don't need it as much.

------
ksaj
One of the best parts of Lisp is the slobber-proof syntax (except in a few
well-known oft-complained-about cases). Another is that the hyperspec is
published online.

Between the two, there isn't a whole lot of memorization needed. You can still
tell a pro's code over a hobbyist, but it doesn't take all that long for the
distinction to blur.

I guess practice is a form of memorization afterall.

------
tomaszs
Missing link for this item: [https://medium.com/@tomaszs2/do-pro-software-
developers-memo...](https://medium.com/@tomaszs2/do-pro-software-developers-
memorize-programming-language-syntax-4e93b38bc2ec)

------
sitkack
This is contrary to most of the advice in this thread, most of the folks here
probably skew towards the highly skilled, and thus they don't really know what
they know since it has been engrained into their muscle memory.

The syntax of a language is difficult to lookup, I don't know what languages
are you are using, but I would say yes, you should know 95% of the syntax of
the languages are you are coding in.

Furthermore, I think you should be able to switch between idioms in the
language fairly fluidly, between functional, oo, data driven, async,
iterators, etc.

~~~
AlfeG
I can easily switch between C#, javascript and postgres SQL. But when it comes
to powershell.. I google every little language construction. It happens to me
every 2-3 weeks for a decade. I still cannot remember from the first time how
to iterate over collection, how to define collection or hash table. I dont
know why I struggle so much to remember it.

~~~
partisan
My coworker and I feel the same way. We’re both .net devs for over 15 years
each. We avoid power shell like the plague. The syntax is ugly and there is a
bit too much magic in it.

As a point of comparison, we are both quite happy to use bash so we don’t have
an issue with command line tools or scripting languages.

That said, after writing a Windows forms app using powershell, I had a
slightly better understanding of it.

------
seisvelas
I do a lot of code puzzles and code golf which gives me a motivation to learn
some obscurer language features. But for professional software development,
it's more important to learn the _concepts_ that the language's syntax is
encapsulating.

That said, there are a few syntactic snafus I regularly find myself in.

1\. I regularly switch between Python and Javascript, so I'm always typing
`push` instead of `append` and vice versa.

2\. I also switch a lot between Redshift and RDS, so I always forget which
functions are exclusive to Redshift and which to Postgres.

------
mailslot
I think that if you don’t, you might end adopting superstitious “best
practices” to compensate.

For example: Countless engineers I’ve worked with don’t know operator
precedence. So tons of ”y = ((i * m) + b);” type stuff. Do not need any
parentheses in this case, but if I remove them, then they have no idea what
happens... So they litter all math with superstitious parens.

There are so many better examples, but you get the idea. I have suffered
“coding standards“ that existed solely because of the devs that won’t RTFM.

~~~
klipt
I'd think most people would remember * before + from school math, but for
other operators the precedence is kind of arbitrary (can vary between
languages) and adding parentheses to make it less ambiguous and more readable
doesn't seem like the worst idea.

~~~
mailslot
Yes, it can vary, but it’s kind of important. If you don’t know the order of
specific operators, or if your language violates math rules, a dev might want
to know that instead of resigning to just not know things.

For readability, yes... sometimes, but for readability sake, not “I don’t know
what this does without them.”

I’m not just talking about math operators, but logical ones too. I’ve seen
people put parens around every “not” because they weren’t sure. There are
three essential logical operators. Surely those can be learned at least. And
yes... in those cases where readability is an issue, of if they’re necessary,
please do add them, but please don’t if you’re unsure what “!a && b || c”
does. Seeing “((!a) && b) || c” raises red flags.

------
ThrustVectoring
Not necessarily the syntax of a specific language, but more the ur-syntax of
what sort of operations are available to work with and what things they do. A
good programmer doesn't necessarily have the exact syntax memorized for
mapping over an array, but "it's straightforward to build an array by applying
a function to every element of an array" should be there when it's relevant to
the problem you're solving.

------
cltsang
Language is just a tool. It's important to know which tool is best for which
task. After identifying which language to use, picking up a language usually
just takes a day or two max. Memorizing is definitely not a necessity, but is
a side-effect when you continuously work using a language for more than a few
days.

------
pcblues
I can type quickly so if i am not sure of the particular precedence rules or
syntactic sugar I dont bother because it is quicker to correctly write
something a little more verbose than it is to remember a cute language trick
that the poor maintainer also has to look up.

------
treeman79
20 years programming Often considered a 10x developer. Also been a .1x
developer when sick. I forgot syntax constantly, basic things I use often.

Difference is I understand the underlying concepts extremely well. I can
reference any needed syntax in seconds.

------
monkeydata
to be productive, you have to minimize the need to rtfm, but you should also
be cognizant of any new implementations -- a refresher may sometimes provide a
better way.

I recently stumbled on the postgres method jsonb_insert(jsonb,path,value)
which is much more elegant than jsonb_set(jsonb,path,jsonb||value) when you
just want to add a thing to some json array inside an object.

I hadn't really looked at the docs much since 9.x, I deal with jsonb everyday,
so I had what I needed memorized. But despite keeping my installs updated, I
had been doing it the hard way for way too long.

------
finnthehuman
Yes. Not completely, but they will be proficient in the ones they use
regularly to the level of going weeks/months without checking the
documentation.

------
groomed
Language and its syntax is the last thing I care about. You just have to find
the right tool for each task.

------
cosmosa
It's memorized in the same way that natural language syntax is memorized. It's
just learned.

------
jitendrac
I dont think this is required. Every language has some rules but more
importantly control structures which are identical but have difference in
syntax. ie, take Foreach loop, I almost every time confirm the foreach's
language specific syntax. Try jumping b/w php, java, python, js in same day
multiple time.

so i will say remembering it is not necessary, but definitely handy thing.

------
mrfusion
Most interviewers believe this.

------
ThJ
Knowing the features of your language can expand your horizons. I had already
been a programmer for years when JavaScript entered a new era, and I thought I
knew a thing or two about computing.

With time, I understood that what I had was a lot of memorised knowledge about
specific systems. The layout of a Master Boot Record. The numbers to BIOS
interrupt calls. Memory addresses.

The transition from Pascal to C that I made at age 12 had only opened my eyes
a little. I learned that there is no true distinction between a function and a
procedure (subroutine), that statements and expressions are really two sides
of the same coin, that a for() loop doesn’t have to enumerate anything, and
that pointers, direct memory access and direct access to system calls are a
very powerful tool.

For the past 10 years, I found myself repeatedly involved in web development
projects. I had minimal interest in JavaScript at first, viewing it as a toy
language for simple automations, and I did most of the heavy lifting in PHP
and Java Servlets. Gradually, as people began doing more and more “weird”
stuff in it, I became more curious.

That’s when I fell into the rabbit hole.

Functional programming, map-reduce, lambda notation, closures, asynchronous
code, generators, observables, applying argument lists to functions at
runtime, destructuring assignments, spread notation, treating functions as
behaviours you can pass around...

Basically, stuff that modern JavaScript has borrowed from languages such as
Lisp.

It made me aware that there’s a distinction between computing as a Platonic
ideal and computing as a practical discipline. Computing is a set of ideas
about information and the logic of manipulating it.

Computer science is a branch of mathematics and information theory. Computer
programs are living equations, written in a notation rigid enough that a
machine can read them and perform computations with them.

I didn’t have that kind of perspective 10 years ago. My skill as a programmer
has taken a very solid step up. Unfortunately, this has also made me
overqualified, and I’m often in a situation where I’m doing work that just
about any developer with a couple of years’ experience could pull off, and
would learn much more from than me because they’ve never done it before.

I’ve come to the conclusion that the jobs that require you to actually
appreciate the nuances of computing and programming on this level are
virtually non-existent. Most customers don’t care if the application software
is a rotting carcass under the hood. They want it cheaply and quickly, and if
it breaks, “That’s what computer programs do, isn’t it?” and then they pay
someone to fix it.

In most cases, the practical craft of programming is very far removed from
that Platonic ideal I mentioned.

I would argue that the craft of programming is in fact almost entirely
unrelated to the field of computer science. Here is an analogy: Building
elaborate cuckoo clocks involves a great deal of classical mechanics, but it
doesn't teach you anything fundamental about physics. A watchmaker is not a
theoretical physicist, even if his practical knowledge of the mechanical
movement of small parts suspended in a mixture of oxygen and nitrogen in a
narrow temperature range under the influence of the gravitational field of a
particular planet may be quite excellent.

~~~
ThJ
The field of information technology is still in its infancy. Had it been more
mature, we would already have formalised the distinction between the
researcher, the engineer and the craftsman, so commonly seen in other fields.

Our current use of titles is loose and very imprecise, and serve as marketing
more than anything else. I would like to see a formal distinction between the
different roles.

Douglas Engelbart, Dennis Ritchie, Richard Stallman and Linus Torvalds are not
"developers" or "programmers".

Engelbart was a "computer scientist" in the true sense of the word. His
systems saw little practical application, but they enhanced our understanding
of what computing machines could do.

Ritchie, Stallman and Torvalds are engineers. If they were in the car
industry, they would be renowned engine and drive train engineers.

Your typical programming job, on the other hand, is equivalent to the title of
"mechanic", "construction worker" or "craftsman".

Many people who enter the field don't actually want to be craftsmen, but since
we are so poor at making the distinction, we get misunderstandings. There are
retired programmers who worked in the business for 30 years who never quite
understood why the job turned out to be so different from what they had
imagined.

One consequence of making this distinction is that a hierarchy of exclusivity
inevitably emerges from this. There are far more car mechanics than drivetrain
engineers. Only so many people have the privilege of doing that.

I don't know if the supply of computer engineers and computer scientists is
smaller or greater than the demand, but what I do know is that these jobs
aren't the kind you find on a job site. They are found through networking,
which requires you to have the right kind of network, which isn't possible for
everyone who would be a good fit for the position.

------
johnthescott
your hands learn to code.

