Ask HN: As a developer what are your aha moments?

I was studying operating systems and computer architecture in university (this included a tiny amount of assembly programming) and was interning at a company that used scala and learning scala. At the time there was quite a fuss about the fact that the jvm did not support tail call optimization (at least until Java 7 IIRC?).

So on one side i was programming in scala and on the other side i was "hand-compiling" small C functions into m68k assembly...

The aha-moment came when I was hand-compiling a recursive function down to m68k assembly and I saw that I could completely eliminate ALL the recursive calls by re-arranging some register values and some values in the stack frame, inserting a small preamble in the assembly and then at the end of the assembly routine jump back to said preamble instead of making a recursive call.

Not AHA moments, but some pointers:

- most tech is stupid simple, like retard levels of simple, with incredibly complex description

- SOA is stupid and monlith is always the way to go(maybe with handful simple microservices)

- microservices are not SOA

- event sourcing is almost never a good idea

- raw bytes over the wire or in storage are not as complex and mysterious as you might think

- compiled languages are not "smarter" than interpreted languages, don't feel like you are lesser of a programmer if you do php or javascript

- new cool and shiny tech is cool and shiny for 5 minutes, until you implement it, then you realize it brings a ton of new complexity and a ton of wasted time and you should have stayed with what worked before and you realize the people who promoted it were just trying to make a sale

- mysql/mariadb will handle way more than you think

- if you want to waste resources, use java/jvm

- yagni should be tattooed on every programmer's hand so when he types on the keyboard he is constantly reminded that he is wasting time with stupid crap nobody will use

- don't think in "what if" terms or try to predict the future, just code what is needed right now, avoid being a smartass

- you can charge more for your services the more essential you are for the project and the harder it is to onboard new people, ie. your value increases over time

- if you charge less now, you will get paid less tomorrow

- running your project entirely in cloud will bankrupt you, use it to gather usage data, than move to bare metal. cloud is cool and "in" but it will eat your wallet, for no good reason whatsoever

- single binary is always better than docker

.. i could go on and on...but thesre are more guidelines than aha moments so that is it for me.

1. That programmers were a market, we weren't just a bunch of nerds sharing cool stuff with one another. That speaker at the conference? The one talking about Wheezle-snort 7.0? Yeah it sounded awesome, but it was supposed to. It's a sales pitch, even if the software is free (Actually, especially if the software is free)

2. That programming and making stuff people want are two entirely different things, although programmers always assume that whatever you're building, it's the right thing. You can spend your entire career in programming, learning all sorts of goodness about things like Erlang innards, and never really understand what your job is.

3. That all of that mousing around, learning a new IDE every two or three years when I started was a complete waste of time. I automatically assumed that the more cool and shiny the programming environment, the easier it would be to code and the better my code would be. But no. grep and awk work (mostly) the same way now as they did 30 years ago, and any time I spent learning which hotkeys did that work in some long-lost dev stack was a complete waste of time.

4. Conversely, that UX beats internal architecture, every time. If folks are having a blast using your app, you win, even if it crashes every five minutes (How they could have fun if it crashed every five minutes is a good question. You might want to ask them)

5. The more smart people you throw at a programming project, the bigger mess you end up with. I know when I say that people are thinking of "The Mythical Man-Month", but it goes deeper than that. Even if you somehow manage to stay on-schedule, human communication around innovation stops working at a certain scale, and that looks like a hard limit. There are ways around it, using things like Code Budgets, following CCL, layers and DSLs, but nobody does that, so it doesn't matter. We, as an industry, have absolutely no idea how to staff or run projects.

ADD: One thing that was quite profound that I discovered late: if you code well, the simple act of programming can tell you something about the way you're reasoning about the problem that you couldn't learn any other way. Programming is by no means a simple one-way street where ideas come out of the head of the programmer and end up as bits on the tech stack. It's very, very much bidirectional. Our programs influence us as coders probably much more than we influence them.

Programming is using conventions. Lots and lots of it.

Conventions for syntax, names, logic, API, structure, vocabulary and so on.

Conventions are by nature arbitrary, influenced by culture, history, social behavior and a whole lot of human weirdness.

Don't try to learn all the conventions first, it comes faster with practice and exposure to it. Solve the problem, then find the conventions you need to apply the solution in your context.

The beginners paradox is that they need to learn a bit of specific conventions (E.G: part of a language, one paradigm and a few libs) to start working on solving a problem, so it's a frustrating experience.

There is no easy way to build the rest of the conventions based on your knowledge of what you know now, because it's artificial.

It's also what leads people to say "don't learn languages, learn to program". Which makes no sense to you at all, until, well, you finally know how to program. But you got there by learning conventions on the way.

1. Use ADTs instead of OOP, always. a.k.a composition over inheritance

2. No ORMs

3. No Frameworks, use libraries to build up your project

4. Use strong type systems for modelling (make invalid states not representable)