Development/Engineering Epiphanies from your experience?

Choice of language does matter.

For instance if you commit in 2022 to java/scala - you subscribe to heavy 20yo over-engineering legacy, whether you want it or not. No matter how fancy and eloquent your frameworks are, or how smart is your founding team — sooner or later this will catch your project.

The benefits may still outweigh the drawbacks for your particular case (though i never seen such cases except some external infra constraints like dependency on critical jvm service etc.) - but it is an important factor to consider that so many overlook.

I did a lot of job hopping and can tell you all projects are a mess. So for me it's all about the money. And having a hobby project where I can have fun.

Business value trumps tech issues/nice solutions/priorities/etc every time. Or put an other way: the guy paying for the party decides what goes and doesnt go, regardless of how technically correct you are (or how correct your technical argument is). To put it bluntly, most of the time the message will be: “F your tech debt and long term considerations, just deliver business value in the short run.”.. just delivered in nicer wording.

HOWEVER here is the epiphany. All of the above talk comes from the “business side” and they only speak business language. You speak the tech language which the business people do not understand (and thus you can get the last word on tech things). If you learn to speak the business language then you will be in the unique situation of speaking both tech and business, and you can use that to frame and control talks with the business people. That will enable you to steer the “all mighty - value now” people into decisions that incorporate tech concerns without them explicitly knowing this, enabling you to deliver value in a way that also allows you to provide your team with an environment where they can do great tech things. That will keep your team happy and delivering which will keep the business happy with your team.

The bonus epiphany is: This is not even a bad thing for the business or misleading, since baking due and proper tech cosiderstions into business prioritization and decisions will benefit the business in the long run. They’ll just never realize it.

Deep learning is clever matrix multiplications with some clever loss functions.

When I first started learning theoretical deep learning I was afraid of it since it seemed so difficult. Then I realized that it's just doing matrix multiplication with some clever tricks to introduce inductive bias, and clever loss functions that teach you how to optimize the parameters of your matrices. And a lot of data.

Naming things is probably the most important part of programming. If you’re struggling to give a function a good name it probably means that it’s the wrong level of abstraction. For example if you find yourself naming a function something like “submitAndParseResult” that’s probably an indication that it should be broken up into two functions.

I used to give a code refactoring exercise as a part of my interview process and I remember one candidate spent most of the exercise just naming the variables and breaking sections of the code into separate functions that didn’t actually improve the performance but made it much more readable. I hired him on the spot.

All of programming is moving data, the better you understand WHAT you're moving, the easier and cleaner the code.

If you implement a fixed size binary tree as an array, breadth first search is simply iterating over its elements.

Never underestimate the ability of end-users to do the wrong thing.

Abstraction doesn't mean you don't have to learn the underlying technology.

Most performance problems come from not understanding the underlying technology due to abstraction.

Being a software developer doesn't mean you understand how the thing works.

Setting expectations is the #1 job of the account team.