Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
halfflat227029dThe abstractions are leaky.
Memory is presented as a uniform, unlimited resource, but it isn't. Arithmetical operations are presented as if they occur serially, in the order you write them, but they don't.
These abstractions and simplification are useful, but limited. A better model of what is really going on will allow you to write more reliable and better performing code.
Being a driver is a great example. If you don't understand the basics of how cars and engines work, you probably just turn your car on and go, you use the cheapest non-synthetic oil, fill it up with 89 octane, never clean your air filter, ride it constantly at too high rpm, or strangulate it by not understanding where the torque bands are.
It gets better though: you have a grinding sound that won't go away, but can't identify it. Mechanic looks at it, says you need a new rotating assembly. They replace half of your car and your timing belt, pulleys, etc etc and bill you for it because they can, you don't know any better. The mechanic also know that the problem was just a tie rod end that was improperly tightened, so he took a torque wrench to it, fixed the actual problem in about 2 minutes and you're none the wiser. But hey, the problem is gone. All good, right?
If you can't reason about the memory usage of your algorithms, you're guaranteed to paint yourself into a corner. You'll be that kind of person that needs tons of vendor support tickets, you'll buy more hardware when you could have just optimized a method or introduced a throttle or some strategic caching. You'll have no choice but to accept bullshit answers from framework and hardware vendors because you don't know any better.
There's also the bit that you're supposed to be the expert, they're paying you for that. I can tell you within a few mb what the operational profile of my applications, and therefore my jvm memory settings should be with some simple back of the napkin math. That's delivering value.
The you in this context is euphemistic and general, not the actual *you* 😉
C0D45946529dIf you don't want to know what's under the hood, stick to SPA and NodeJS and drive the car till it catches fire, and trade it in for a new model, that's fine, just another useless dev in the market as far as I'm concerned.
Learning what your application can do, how to find optimisations that are abstracted away from you due to frameworks and vendors and how to make that process that takes 4 hours because some useless dev wrote it, and turn that into < 5 minutes.... that's a game of its own you're being paid for.
Your profile says fullstack, yet you claim you don't need to know the fullstack 🤷♂️
Indeed. Honestly the better analogy isn't even one of driving your car, but driving professionally. As engineers, we're closer to the level of racecar driver than bus driver, chauffeur or truck driver. It's our job to diagnose the "vehicle," which is in this case our application. You may not need to know how to make a harness wiring harness, or machine components, but you need to be able to identify where low level problems are to effectively communicate with the pit crew (vendors, framework, language and system teams, as well as other teams within your company). It's the difference between a quick resolution and being out of the race.
If your company leans open source, you'll have the advantage of being able to test and fix the issues yourself and submit PRs and tests to the project itself, saving you even more time since you don't have to wait for a vendor patch.
NEMESISprj7527dSpeed, optimization of resources, (re-)writing an algorithm or function tailored to your own needs and specs, the list goes on... And the bigger the data you work with and the more time-sensitive your application, the more critical memory management and execution time will become for example.