I was under the impression that modern compilers just inline something like that, and even in older languages (like C) use trickeries are used to inline it (typically MAX is a macro rather than a real function, so its always inlined)

Ultimatelly it depends not just on what you’re doing but also the language and compiler you’re using.

Yeah, I’m about the same age and started noticing my ability to keep everything in memory falling at around the mid 20s. I mean, I’m still probably way better at keeping all manner of obscure details in memory compared to the average person (we exercise that so much in this profession it’s only normal), but it’s below the peak point, not enormously so but it’s kind like having once been a top “athlete”, years later you know you can’t reach that peak performance anymore.

Also once you go through the full life-cycle of enough of your projects (that got shipped and a year or two later you have to pick it up and change it), you kinda figure out that even at peak “performance” you wouldn’t be remembering much from a project from years ago and start adding comments to help you pick it back up and alert you to possible pitfalls you noticed and avoided but forgot all about in the meanwhile.

Fortunally I figured it out long ago that I’ve created a couple of principles around commenting that have repeatedly saved my ass years later: things like documention parameter assumptions in functions, actually writting down the “why we do this” or commenting before the code of especially complex algorithms (I actually design the algorithm to the comment first and only after than code it).

I just love it when people who have no understanding of the purposes, objectives and applicability of various parts of a famous software development process and just follow it in a blind fashion-following way.

And by “love it” I mean “get frustrated to no end even though by now I should know better”.

“I’m dumber but wiser” - me, hopefully

It’s a bit more complex than that.

On one side you should put comments on the choices of how to do certain things at a code level that are the product of external limitations or requirements (over the years I’ve seen quite a lot of code which was kept doing things in a certain way and turned out the actual reason for it had long stopped being applicable) whilst most of the code should indeed be done to be self explanatory (though complex algorithms, especially if optimized or relying on obscure functionality, should probably be preceeded by a summary).

However, go up one level to software design and suddenly comments become more important (at the function and class level). They document functionality for significant chunks of code (so make it way faster for people trying to figure out the design of a code base they never saw before, as otherwise they would need to wade through a lot of code) as well as implied expectations in things like parameters or return values (i.e. that a variable is never expected to be null, that a zero size string is treated as NO DATA and so on) of functionality meant to be called from the outside (a kind of comment which is really just a lightweight form of an Interface Requirements Specification document). Mind you, over the years I’ve seen tons of comments documenting functions “just because” and without understanding what’s the point of doing it (probably because the programmers were told the HAD to do it) in the libraries and frameworks from some of the biggest companies around.

You could say the WHY of commenting is also important.

Communing with his lesser minions.

Pretty much all online service APIs (Google APIs, Facebook and so on) out there are text-based.

Granted, JSON formatted text, but still absolutelly human readable text.

The reason for that is because it’s agnostic of the machine architectures (stuff like endianess) on both sides.

The really crazy stuff in banking are the old binary protocols (like EDF) from the time when bandwidth was way less than now (so, the early 90s and earlier).

I read it as them both being loose-typed interpreted and widelly used languages.

Not even close.

Most software out there is not consumer facing (there is a huge amount of custom stuff inside companies of all sizes) and even in the consumer space most software nowadays resides in … smartphones.

Unless, of course, you count HTML (literally a Markup Language, so data formatting for display not code) as programming, in which case I’ll leave you to enjoy your fantasy world.

A proper backend developer would have the query be a URL using the GET method with a parameter that the user can fill-in directly in the address bar and the result be a text/plain page with just a bunch of numbers separated by pipe characters (or an application/json page with that info encoded as JSON if you wanna be fancy).

This has the added advantage of working both for humans and as an API for use in machine to machine communications via HTTP.

I’ve worked with Java for decades (kid you not: learned it from reading the Java Language Specification 1.0 back when it came out) and there’s definitivelly a stage (often a long one) in one’s career when one thinks him/herself so great at OO and just overengineers every single software design way (way, WAY) beyond the actual objective of behind the whole OO design concept (maintenability and bug reduction), actually achieving the opposite objectives (an unmaintainable POS, riddled with hard to track bugs because of way too many unnessary details having overwhelmed the developer’s ability to keep track of it all).

Eventually you learn KISS design and Refactoring as a sort of housekeeping practice for code and design.

But yeah, as a freelancer I’ve very commonly landed in the middle of maintenance-stage projects with existing code bases that were clearly done by somebody at that oh-so-special stage in their career, and often it’s better to just reverse engineer the business requirements from the application and redo the whole thing (in the process cutting the codebase size to a small fraction of what it was).

The Design Patterns book itself (for many an OO-Bible) spends the first 70 something pages going all about general good OO programming advice, including (repeatedly emphasised) that OO design should favour delegation over inheritance.

Personally for me (who started programming professionally in the 90s), that first part of the book is at least as important the rest of it.

However a lot of people seemed to have learned Patterns as fad (popularized by oh-so-many people who never read a proper book about it and seem to be at the end of a long chinese-whispers chain on what those things are all about), rather than as a set of tools to use if and when it’s appropriate.

(Ditto for Agile, where so many seem to have learned loose practices from it as recipes, without understanding their actual purpose and applicability)

I’ll stop ranting now ;)

You can add tons of explanatory comments with zero performance cost.

Also in programming in general (so, outside stuff like being a Quant) the fraction of the code made which has high performance as the top priority is miniscule (and I say this having actually designed high-performance software systems for a living) - as explained earlier by @ForegoneConclusion, you don’t optimize upfront, you optimized when you figure out it’s actually needed.

Thinking about it, if you’re designing your own small matrix multiplication library (i.e. reinventing the wheel) you’re probably failing at a software design level: as long as the licensing is compatible, it’s usually better to get something that already exists, is performance oriented and has been in use for decades than making your own (almost certainly inferior and with fresh new bugs) thing.

PS: Not a personal critical - I too still have to remind myself at times to not just reinvent that which is already there. It’s only natural for programmers to trust their own skills above whatever random people did some library and to want to program rather than spend time evaluating what’s out there.

In my experience we all go through a stage at the Designed-Developer level of, having discovered things like Design Patterns, overengineering the design of the software to the point of making it near unmaintainable (for others or for ourselves 6 months down the line).

The next stage is to discover the joys of KISS and, like you described, refraining from premature optimization.

I actually have a ton of professional Java experience and have done a lot of microcontroller stuff of late (for fun mainly) and if you go at doing software for ARM Cortex-M microcontrollers the Java way you’re going to end with overengineered bloatware.

It’s however not a Java-only thing: most of those things have too little memory and processing resources for designing the whole software in a pure OO way, plus you’re pretty much coding directly on the low-level (with at most a thin Hardware Abstraction Layer between your code and direct register manipulation) so only ever having used high-level OO languages isn’t really good preparation for it, something which applies not only for people with only Java experience but also for those whose entire experience is with things like C#.Net as well as all smartphone frameworks and languages (Objective-C, Kotlin, Swift).

Actually there’s also the breaking of the psychological state of Flow, which is the mental state of total focus and maximum productivity, which takes about 15 minutes to get to.

Years ago when I had to work as a programmer from the Trading Floor of a major Investment Bank (think Fishmongers’ Market but with Financial Assets) I bought some noise reduction earphones and have used those kind of things ever since as they really cut down on distractions and it mainly works.

It even cuts down on the “can you help me for a second” thing because other people actually have to get up and move to were you are to get your attention (as you can’t hear them unless they shout), so the zero-effort choice of just calling you from their seat to help them isn’t there anymore and one thingI learned pretty early in my career is that in the absence of a zero-effort help path through you for their problems, your colleagues will actually try to first solve their problems themselves and only come to you if they’re really stuck, whilst if you’re the least effort path to having their problems solve most will just default to breaking your focus and using your time to have their problem solved.