Creator of Go on Software Complexity | Rob Pike | Prime Reacts 

The descriptiveness of a variable name should be proportional to its lifetime. That's why it's fine to use "i" in tight loops - because the variable has a very short life span.

resolve, reject is actually much clearer than res, rej. I can tell you this personally because I've read other people's code and realized they think res means "result" or "response" and don't realize it's a callback function. I use abbreviation all the time, e.g. "amt" for "amount", "len" for "length", "args" for "arguments" etc, especially anything that's a reference to a common abbreviation in use in unix utilities or POSIX standards. I also don't shy away from 1 or 2 letter variables for inner variables and things controlling control flow (e.g. if I'm orchestrating some concurrent logic in Go and I only have one main communication channel, it is often named "ch"). But for something like "res" that could refer to so many different concepts (result, resolve, response, resume ...), I avoid it.

"clear use of function pointers is the heart of object-oriented programming" absolutely true. Ffmpeg, a C program, is object-oriented because of how it uses function pointers. It also does object-oriented better than most actual OO languages.

30:32 - so true !! In college, I had a professor that made us do EVERYTHING in Python, and he would give us template code, meaning, we had to complete it but we couldn't change what was given as a base. And he would use Classes in Python for every single thing, and I would just get so MAD because the code was so simple but because of this, the code would be so slowwwwww. Because of that, in one of the projects I delivered the project with two codes, that did the same thing, but in one I replace all objects with dictionaries, and in the delivery file I also appended a graph with a profiler analysis of both codes. That felt good!

I'd say that for the sake of search it's better to name things uniformly and without abbreviations. It's much easier to find anything in project related to 'address' if it's fully spelled than to try all kind of silly abbreviations which can come to mind to different people. It also has an advantage of spell-checkers validating that you don't have a typo. Especially useful if the people working on the project change often, and some of them are just juniors from unknown countries whose knowledge of the project domain and English skills are lacking.

Can't believe you're a hair's breadth away from Plan 9. I'd love to see that arc.

res and rej versus resolve and reject The shorter one differ only in one letter. Also searching the text with longer names is easier. It is fine to abbrev, but I personally prefer slightly longer names, depending on the situation off course. There are no hard rules.

I comment a lot - actually sometimes even add ascii-art drawings when needed. I think coding enough long in assembly teach you to comment and comment well. These are the things I do: - Typographic comments that mark blocks: like "// preparation" and "// windup" instead of creating methods for that only called from this single location. It makes readable code! - Documentational comments for methods and structures are very useful - Writing out why you choose and algorithm is very useful - Sometimes explanation of invariants or even the algorithm can be useful (this is where drawings can happen mostly - mostly for new data structures) - There are cases when I use "markers" - like "this works because of (***)" so that you can totally search for (***) held up as invariant somewhere. You can say "oh likely is bad design" but this also works in performance optimized codes and edge cases and sometimes you cannot make a more readable version but this still works and is very useful. - What about other hard-to-convey-in-ode information like "(// O(n) because despite this being a loop in a loop total element size at this point is linear to original input data) ??? - Also perf characteristics I sometimes mention in documentation comments - but also contracts for the caller genereally. +1: Actually I do prefer even the wrong comments compared to none if I can access git blame. Its a fallacy to think "code should be self-explanatory" because it might be self explanatory to someone and give endless headache to others (or even yourself) later. Especially with feature or code creep around that area where every small change in all the small PRs end up creating a monstrosity that lose its meaning. I saw that happening and comments HUGELY help. If they are not what the code says - that is indication of a bug: its either the comments bug, or worse: the code is buggy. In both cases worth investigating. Also keep in mind that the argument "the compiler does not check the comments" does not really hold up: neither the compiler checks how you name things and the same article puts a heavy effort on naming. I say this because I literally saw endless many times where naming and content go out of sync.... like "railConnectionMap.get(c)" for example ADDING c to the map if does not exists before.... who made that change was a total idiot, butt added the code there which is crazy and I got heavily surprised that this call not only always succeeded but makes it possible to out of memory the whole process :D It was once a simple getter, but it got "other shit" into it and the name stayed. I knew things where a checkRegex(r, obj) got to have a side effect of connecting to a database and do stuff related on user role - sorry I was like whyyyy why not rename if you do these kind of shit? Mostly good content, but sorryicantfukinreadwithoutcamelorsnakeorsomepropercase exceptshort.... and sorry but I find comments very usable. It is sad people are not excercising good commenting.

The most meaningful point about abbreviations is actually not about abbreviations per se, but about consistency: The thing about abbreviation is that there are no standard conventions for how to abbreviate things, and this can cause naming inconsistencies when different programmers abbreviate similar concepts in different ways in different parts of the program. I often choose to use the full name of things simply because it sidesteps the question of exactly how to abbreviate it. This only matters of course when the concepts have a wide scope, e.g. method names or fields in public interfaces etc.

Can't wait 'The C Programming Language' on PrimeTime sometime next month

Loved this article! Especially the focus on data. That approach can really make a night and day difference in a program. Data is king.

PL/SQL has a very important differentiation between functions and procedures. If you have to write stuff in it, it's really helpful to know the difference immediately, it saves you confusion.

the thing about pointers is so true, whenever i have a loop over an array's contents i have a value like cur_ or just that is the array indexed by the index because its easier to type and theres less that could go wrong

Apparently its a hot take around these parts but I like complete naming and don't like abbreviations. I've spent more time in C++ than I would've ever liked to have and it drives me up a wall how some of its naming where it begins to fail to even read like english anymore. It's painful, the few times I have to do something with C++ the number one thing I'm actively despising going in is the abbreviations. If it was just the full name I probably would be able to figure out what the purpose of the thing is. But I can't and now I have to pause and go read code or docs because someone couldn't take the two seconds to type 8 more characters. I'll die on the full name hill.

I am going to be bold and try to clarify 32:55 - 33:30 for anyone who is wondering. What Rob Pike means is that you should encode your data into a format that is easy to address in your code, rather than adapting all your code to the data. By doing so, you reduce the amount of times you have to deal with the complexity of the data. In the parsing table example, encoding the grammar of the programming language into a parsing table once saves you from dealing with complex grammar rules every single time you manipulate the data. Think of it as centralizing the complexity of the data into a continuous block of logic, instead of having bits and pieces all over your program.

Flip: How many videos do you want released in 24 H Prime: YES

“e” certainly isn’t confusing when sitting right next to the definition. But if you find it at the bottom of a 200 loc method, you’ll find yourself going back and forth to check what things are.. it hurts readability because you cba to write the thing in its entirety to begin with. Just my two cents

old out of date comments are very occasionally an issue. but i've found that lack of comments entirely is a problem 100x more.

The only instance I'd advise from using short abbreviations is to be able to find variables quickly in the source code and navigate faster within the source code, can't really do that if all your variables are named i, j, k, o, and when you search it matches every letter in every other word. Also trying to keep them unique is crucial if you want to search and replace variables later throughout the entire codebase, so it doesn't matter what you call them for as long as you can replace them later with one click.

On the use of abbreviations in variable names, I worked with a guy who took that to a whole new level. Some of the notable abbreviations we had to change all over an API were dtBth for dateOfBirth, veh for vehicle, and clnt for client. It happed so early on in my career that now I, to a fault, name things way too long.

I think a good argument against abbreviating is that there's usually more ways to abbreviate ("res", "rej" or "rs", "rj" ?) so it's harder to keep it consistent. IMO for short words like "result", "reject" it's probably not worth. OTOH, if it's a really ubiquitous well-known call that's also short-lived, I would not really care.

18:30 also a good thing to consider it that extracting expressions to a var will make it easier to wrap or replace it later when necessary. It's much easier to change e.messageType to e?.messageType ?? "NO_MESSAGE" in just one line than to copy that same code to multiple places with different contexts.

the creator of go, I wonder what is take will be? 🤔

13:15 my brain interpreted the parenthetical as being unrelated to the rest of the sentence like “The Sun is a star located in the center of our solar system. It radiates energy derived from a process known as “nuclear fusion” (my family died in a drunk driving accident 5 years ago)”

Reminds me of that other PrimeTime video about how much programmers hate to read code, but love to write code. And I think this happens because there's a disconnect for many people between being a reader and being a writer. As a writer, you're immersed into the context (of what you're writing about) all the time. As a reader, you have to expend effort to get into this context, and expend yet more effort to follow along when context is being modified. Additionally, it's not just the semantic context a reader needs to follow, but also the idiosyncrasies of the writer. Add to this the general complexity of programming, and you get a soup that's easy to cook, but mostly hard and unpleasant to swallow. Sometimes, and I'd say, more often accidentally than intentionally, writers get it right enough and have success. This reader/writer disconnect also seems to present a hurdle to improve one-self as writer for many. Peer reviews could help, especially when peers with alternative idiosyncrasies take part, and the writer in review can distance from code as self-expression and from the immediacy of their own context experience as writer. Unfortunately, this appears to be very hard to learn, and even after years of code reviews I've experienced as writer, they still often leave me feeling defensive. I'd say the biggest change to my perspective on code expression came from applying the Zen of Python repeatedly to my own code and that of others. Reflecting on suggestions I received and gave, and also applying suggestions I made to others to myself. Now I think it's so obvious, if you're a reader take note of positives and negatives of the materials you're reading and apply them to your own writings. If you're a writer, take breaks, switch context, read your own stuff over and over again. But perhaps most effectively, try and explain it to anyone, then observe where you had to spend more time giving context... then add this additional context to your code. I also think this reader/writer disparity also takes part everyday as listener/speaker or observer/actor. It's generally a disconnect between communicating parties, and people only experiencing themselves as one but not the other at any given time.

17:40 this is one feature I really miss from haskel in other languages. There 'where' syntax would allow you to write write a short function showing the algorithm or calculation you're performing, and then afterwards you write "where type = e.type" etc at the end to show where you get the data from.

At my last job we had like 15 people who ALL knew that "sis" meant "Student In School" (education tech stack). It was so ubiquitous that no one questioned it. It was wonderful. 3 chars said so much about what a variable was and meant.

From Chat Jippity: The word "as" can function as both a preposition and an adverb, depending on its usage in a sentence. Preposition: "As" can be used as a preposition to introduce a comparison or in the role of a function word relating a noun or pronoun to another element in the sentence. For example: "He works as a teacher." (introduces a comparison, indicating his occupation) "She used it as a tool." (relates the pronoun "it" to the noun "tool") Adverb: "As" can also function as an adverb, modifying a verb, adjective, or adverb, and providing information about the manner, degree, or extent of an action or condition. For example: "She ran as fast as she could." (modifies the verb "ran," indicating the manner of running) "The car is not as expensive as I thought." (modifies the adjective "expensive," indicating the degree of expense) "He writes as well as his brother." (modifies the adverb "well," indicating the extent of writing ability) In some cases, "as" can also function as a conjunction or a relative pronoun. The specific function of "as" in a sentence depends on the context and the role it plays in connecting or modifying other words or phrases.

There was an interesting article I found where some Russian fellow was talking about not using design patterns and all the other things, just trying to keep things like performance and simplicity in mind. Apparently this was the easiest system to update and maintain he had while the other ones just went down hill.

The older I get as a programmer, the more I consider code primarily a document written to other coders. It is read and written by people many thousands of times more than it is to generate production code. The only thing that matters always is that it is as clear as possible for other humans to read. Even to the point where for those very rare cases where highly optimized code is obfuscated in the name of performance, I also include the unoptimised, readable code with it.

The length/descriptiveness of a variable name can be calculated by a simple formula. It's the distance of the declaration and use, divided by its usage frequency. In other words, short variable names are for things that are used shortly after declaration (iteration variables, temp variables, ...), or things that are used frequently (sum, fn, Vec, ...). It makes sense. In the first case you have context, and in the second you have familiarity.

I don't have a problem when people abbreviate but I do have a problem when they abbreviate the wrong thing. for(const event of events) is perfect, for(const e of events) is fine, but for(const el of events) is not. I don't think anyone would write "element of events" but some of those people find it ok if they reduce it down to el. I personally hate that.

The larger the scope, the longer the name. If it hangs around and gets used a lot, I tend to be descriptive. If it's an index or local to a small func, it gets shortened usually.

about the abbreviation thing: You don't see any clarity, because english is your first langage. Start naming variables in... say, Polish, and you will see the difference. [edit] I see a lot of people missed the point. Of course everything in code should be in english, veriables, functions, etc etc. My point is that there is a difference to looking at two abbreviations in your mother language, and in learned language. For me, there is not much difference anymore, since i learned to "think" in english (my internall narrator is bi-lingual now) but some years ago, certain abbreviations in code would throw me off the correct path because i un-abbreviated them differently than intended. [edit2] I think my initial statement should have read: "If standard for language used in programming was Polish, you would see the difference". about idexes in for loops, i agree wholehartedly, but with a "*". When you have nested loops with large bodies it's sometimes advantageous to give more specific name to the indexes.

If combining data structures is fair game, arrays are enough for everything: 1-element arrays for scalars and indexes as pointers complete the list of building blocks needed for any data structure. Also, the distinction between data structures and algorithms is ephemeral: a data structure is a set of algorithms that work together to accommodate specific data usage patterns.

8:05 In plan9 C they do use this mostly no space in binary operators convention but there is no such thing in Go, but yes gofmt will remove spaces in operators expressions in a style that is used in plan9 C, that's removing spaces to group by precedence order, that's way harder in C because there 15 levels of precedence, in Go there's only 5, so in this expression: 5 + 1

the procedure/function distniction is still important for reasoning about programs! even if your language doesn't distinguish the two, knowing in your mind that a function doesn't change things or involve global state simplifies their analysis vs procedures

In 1989 i was starting my first job programming an IBM System/38 then AS/400. i feel old. All command were created with 3 characters of each word with a few exceptions. e.g. CRTF (create file), SBMJOB (submit job), WRKACTJOB (work with act job), WRKBNDDIRE ( work with binding directory entries). Absolutely awesome system. It would just keep running.

e becomes confusing the further away it is used from original declaration. The length of the variable is dictated by the number of lines you need to scroll to find how it is declared. The size of the context spanned by the variable matters. The second parameter affecting the length of the variable is the number of declared variables in the same scope. If you have e1, e2, i, a, o then something is not right. If you only have single variable you can use the shortest name possible. If the variable is competing with common notation from math or accepted software engineering standard then the name better be elongated. For example, I refuse to accept that "i" is ever a good variable name except for iterating through a loop.

"This paragraph predicts NPM dependency hell" It actually doesn't, that paragraph is anachronistic even when dealing with C code. Pike is essentially saying that include guards like #ifdef FOO_H_DEFINED #define FOO_H_DEFINED /* contents of header */ #endif are hard to get right. There's some room for getting it wrong, sure (like what if you pick the same guard for two different files) but they're a well-known idiom and there are ways to avoid that (you could even configure your editor to generate and append a GUID to the guard name). These days we have widely supported #pragma once which works always unless you're doing crazy stuff with symlinks and distributed filesystem (in which case you might want to consider not doing the crazy stuff). Either way, dealing with include guards and their problems, or nonstandard pragma once, is vastly, vastly preferable to having to manually include the dependencies to every single header you put in your program. These days, that would just fill your editor with squiggles and it's not worth the bother.

Its good to get into the habit of using idx as your index: someday you might work in a language/library/codebase where i is reserved for or imported as the imaginary unit.

28:50 How many years ago was it that you saved multiple seconds using for instead of forEach? I also worked on a radar product and also switch to for due to processing millions of items of data, but I've tested similar loops since and I don't think the same performance issues exist now.

Pike is very much sort of describing how Common Lisp does object orientation and it's a rather pleasant experience. People should try it out, it's a neat way of doing business.

people who dont like go - "its to easy to do stuff i need to do while being safe enough to also be flexible"

26:27 "don't laugh now, wait until you see it in real life". I suddenly remember reading this article about 15 years ago! And I have seen these comments in real life since then! I call them zero-info comments.

The issue at ca. 42:20 (Include files) is a problem of "back then" as C programmer (Sometimes still today but we have tooling). Which is include hell, where the header uses stuff but you have absolutely no idea where that comes from. Visual Studio is still bad at finding some of these things. E.g. you include a header called which includes some library global header which in turn includes all of the library. Suddenly the header uses a "thingC" which got included over multiple corners. Back then it was a nightmare to follow all the header to the definition of "thingC". The #ifdef's help to hide this include problem very well.

The "as" in "as sensible" is an adverb, modifying the adjective "sensible." However, "as" can be a preposition, as in "acting as a mediator."

6:26 I agree that abbreviation in this case is no fuzz. It's just a pain in the ass when it is not something standard, and you have to guess what it actually is. Its made even worse by some people insisting that we should always use implicit typing. In the worste cases you end up with this variable that has a abbreviated name that is implicitly typed, where its value is returned from a function named something that is wage. Of course you figure it out fast, but when you have this everywhere, I hate reading code where everything is abbreviated.

32:50 By "programming with data" he's just saying "declarative", but before it twisted to mean "force everything into an AST and pretend that it's declarative for a cool conference talk"

I avoid nested includes too. Instead I'll group the prerequisites into sections, e.g.: #include #include #include #include #include Each group contains the prerequisites for something in the next group. I also tend to sort alphabetically within each group.

The parsing stuff favoring data over code is essentially the Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.

I would not have known where for res and rej stands. I find that especially for new sounds better or easier to understand, especially if they do not have English as their mother tongue. But opinions may also differ

33:30 My understanding is that he's expressing that often algorithms have more general parts that are best expressed through code while details fit better into data. Like the parsing table. The parser *code* encodes the process of categorizing arbitrary (implying general) symbols into tokens while the *data* defines what characters in what sequence will form tokens (details). Hoping I'm wrong.

all of us blessed enough to have learned programming through C, have no problem abbreviating, I agree with Rob Pike on naming.

6:00 the problem is that `res` is already "server response" and (in some code bases "client response" - which should, of course, be `resp`), so you should use the full `resolve` for consistency - just like `i` is always a counter and `e` or `err` can be an exception, but events should be `ev`. The shorter the name, the more context matters, and you'll *definitely* have resolve and response in the same context from time to time in JavaScript.

"Rule 6. There is no rule 6." is the most subtle Monty Python reference I've seen in a long time.

I also hate comments in code, but there's a rust library which auto-hides docstrings - which enables me to provide documentation for client, but also to have my preferred method of viewing and working on code

Standard advice for C and C++ now, I am 85% certain is do it, inside #ifndef block. There was probably a point where the standard libraries didn't do it, so it probably had other issues if you tried doing it, but to the best of my knowledge all the standard libraries do it now.

The thing about OOP I would consider bad are stuff like inheritance, the UML stuff, and the obsession with abstraction. Classes and methods are pretty good, actually. I feel like people are throwing the baby with the bathwater.

26:22 I do add a block comment on a whole module if module is complex enough

People will go on an hour long debates just not to type 3 extra letters in their variables to make them more readable

(res, rej) clearly stands for (response, rejuest). :P However, I do use "index" and not just "i". Because people that use "i" often use "j" for an inner loop and I had the case where "i" and "j" got mixed up and I just didn't see it because the letters look so similar. Took me a while to debug that. And when you write "index" nobody writes "jndex" in the inner loop. You write "thingIndex", like "userIndex" and then "postIndex" in the inner loop (if you have to do that via indices for some reason and not a for-each loop). And about using "e" instead of "event": Lot's of people use "e" for errors. I mean I guess clear in that small loop, but if its more complex code where you *also* have to handle errors I think writing "event" and "error" is good practice. Nothing I would argue in a code review, though, if it is really like the shown code example.

You're talking about how abbreviating things is just fine, but BOY, I wish I could show you some Minecraft source code I was trying to understand becuase I was making a mod. The damage function is absolute spaghetti. It was so stupid. There were like 5 variables getting thrown around that were just single letters, and I don't even think they stood for anything. But hey, maybe that's just copium/skill issue.

data-driven algorithm -> reminds me of structure and interpretation of computer programs

15:27 wrong, "no problemo" is from Terminator 2 (I had to search for the date) which came out in 1991, the article is 1989, then there was no problemo so "np" was a bit more specific and usable.

i used to think that all these battles were silly. then i had to start using Braille. in that context, space vs tabs made a big deal. lines being too long was a real problem. i think Go is right to use very short and standardized names in local scopes. global variables should be as verbose as the global function names. the more distant the consequences can be, the more verbosity is reasonable.

Code in a stupid way, and your program will survive longer ^^ In implementing form validation, I coded the whole thing, assuming I would have two magic functions. One is to retrieve a field from whatever structure was passed to it, and the other is to retrieve a value from whatever design was passed to it. So, relatively easy to do the validation using those functions. Then I created those two first-order functions to grab fields/values from the right place. When the same functionality was required in an Angular application, only those two functions were to be remade. I tried explaining that to the other developer, who insisted on changing the "core." I don't do Angular (I did AngularJS), but in the end, I did those two functions myself. The guy still didn't wrap his head around it. Later, we had to update the core, copying one JS file. He had the same issue; he didn't understand it was just a copy-paste...Took a few times before he became confident. I even asked my boss if I could take over that part entirely because going into a call to copy a file is...painful. In another application, I created an intermediate representation. My boss thought it was a waste of resources, but that intermediate format is more suited for processing. A small upfront cost for a lot of downward efficiency! I had to implement a new feature, and thanks to the intermediate format, it took a day instead of a week ^^ And I am the first to say comments are usually band smell (as a QAM, I used comments as a mean to quickly find code that belongs to a function), but most of them read like "do not attempt to simplify" or "bug in library, force reloading data". Now there is a considerable drawback, people not used to that way of programming are stumped because it's not a big block of code where you can read from top to bottom. In the middle of the code, you have a call to a function coming from the parameters, so you've to see how it's called to see the body of that function in context...except that you don't have to because you're supposed to work at a different level of abstraction. So, it makes stuff way simpler as you just have to assume the function does what it says it does. And that's the beauty; in the end, you concentrate on a very generic algorithm, which is relatively easy. Then you fill in the gap, which is relatively easy too. Then you end up with something complex but totally digestible if you don't freak out. On top of that, the JVM loves smaller methods. (No JIT if bigger than 8k, and I saw strategies much bigger than that ^^) I have 15 years of professional development, 25 years with hobby. (You can look up "Navigateur à onglets gérant ses favoris et qui peut se dupliquer (==>capture)" for an example)

THE VIM PLUGIN IDEA IS AMAZING PLEASE DO IT LMAO (im a java developer and i see that bs all the time)

Aged like fine wine.

I don't write this in JavaScript: const type = event.messageType: if (type === I write: const { messageType } = event; if (messageType === If messageType is used more than once. Otherwise if only used once: if (event.messageType ===

How does one chisel their thumb? You need one hand for the chisel and one for the hammer, so how does a thumb get in front of the chisel?

I had no idea that foreach loops are considerably slower.

27:40 probably masking bits, preserving bit 7 because of bit 2 somewhere else? I'm probably way off, but I've been coding a gameboy emulator for a little while and I see bitmasks in my nightmares.

e in events is honestly better than event in events because event and events are once character apart, and like you only need to know e means event for the loop body.

C# has always had “function pointer” as delegates from 1.0.

"Functional languages have a similar problem with I/O." Unless the functional language just says screw it, we're doing side effects. In Fexl the hello world program is just: say "Hello world." You might not call that "functional," but other aspects of Fexl *are* purely functional. You can make any section of code as "pure" as you like.

Prime rants about comments being bad, simultaneously proving he needs comments.

crabs in every pirate movie are cursed

You should told at the end "The name is Gophergen"

21:20 If you follow the command-query separation (CQS) principle you have would end up writing commands that are analogous to what was understood to be procedures (perform an action) and queries that are analogous to was understood to be functions (return data). In that context, the recommandation still holds up.

31:37 I see why Go stuck with hashmaps and arrays. The dogmatism has been there since 1989.

4:15 Ackchually, my sub sandwich is as long as the log, but unfortunately it is also as tasty as the log.

II tend to not shorten them passthrough words. more because my brain doesn't immediately jump to response & reject, and more commonly for what I've been doing, I remain verbose on the names with passing in types of things like that.. because I tend to bounce around versions and unless it's crystal clear what it is via the type (like an Entity Type named XYZ, where the only thing that could be is that Entity Type, by the name), and with shit like int, double, float, etc.. I tend to be a bit verbose and label the intent of the variable rather just juts use it's name.

my variables: this.x = x; this.y = y; NO!!! This. !algebra class

28:00 at this point, I am usually, "Well lets see what happens if I take that out..."

You don't need a language server to know what something was or where it was defined or used. We've had lookup etags / ctags. But software dev tools in general back then were far more primitive.

Writing clean code really boils down to expressing yourself in a way that it makes sense to another reader. Ideally, somebody should be able to read the code almost as easily as reading a newspaper article. Your choice of words is *entirely* dependent on context. It could be the case that “int amt = 42;” is obvious in a short method, but then as needs change and the purpose of the method changes, it’s more valuable to name it “initialAmount” as you add a new variable “finalAmount”, or whatever. Names should change as the context in which the code appears changes. Whether an abbreviation is appropriate or harmful will certainly depend on the complexity of the code and the number of abbreviations somebody has to juggle. I don’t think this is altogether difficult to do, but it requires putting yourself into the shoes of another person, and a lot of programmers… well, they’re just not good at that or frankly even interested in it.

Not quite abbreviating fever, but anyone working in defense contracting knows how communicating about anything feels like regurgitating acronym soup

You probably know this but (assuming this is Java) forEach uses streams which (in a lot of cases) tend to be slower than loops.

Man, that Tom guy is a genius!

You were alive in 1989. Wow such old!

13:12 classic old programmer wood worker.

4:01 "as" can function as a preposition. "I work as a programmer."

86er aswell damn the world has freaking changed

Audiobooks with prime reading up old programming books, and yelling at them when?

this essay unironically blackpilled me into using a grayscale editor theme and i've never looked back

Abbreviating is bad with a large codebase. You want names that are specific or even a bit odd so you can easily find them. I started with abbrvs but now I use lngnms.

+in an expression no space, + in a statement does. But doesn't really matter gofmt makes everything written with one way. This is the way.

When you declare or use a pointer the syntax tells you that it’s a pointer. “Node_ptr” is as ridiculous as “length_unsigned_int” as a variable name. 🤣

The "comments for each line" section gave me some bad flashbacks