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

I always thought programming was my passion as I never get tired or loose motivation when I code until I realised that my passion was DIY and programming was just a tool to create things.

Starting from there, I don't take any programming language seriously anymore. Whatever makes the job easier and faster to accomplish in context.

Oh yeah, big time. The current craze at my work could be summed up by the phrase "How longs your pipeline".

It really irks me because we as 'tech' people don't think about time and money and that spending it in one direction stops you from another. It's very frustrating.

+1 to this, but I came upon this indirectly.

My biggest "OK Moment" (1) was non developers building tools via Spreadsheets Sheets when they do not have a tech team or the team's bandwidth, Which makes them IDEs. They also function - independent micro data stores - a data exchange mechanisms

1: https://ravivyas.com/2020/07/07/stack-the-bricks-with-ok-mom...

1. More of a CompSci aha: Hard problems are hard. Sometimes I get frustrated over getting stuck in a bad local optimum that I can't easily get out of. But then if I take a step back, I notice that the problem is NP-hard, that I'm not gonna solve it by throwing random heuristics at it and I need to either change the constraints to make it P, lower the input size, or lower my expectations. Simplest example: Deciding what goes in which shelf in my home is NP-hard. Solution: Get rid of stuff more liberally -> (n' f(n') is much easier than f(n)

2. Doing NAND to Tetris the first time. It taught me not only how computers work, but how powerful recursive layers of abstraction can be. I had absolutely no idea how my system looked on RTL, but I was still able to build it.

3. Also Lisp. I wish Nand to Tetris had picked something more lisp like in the second half to show how simple and powerful it is.

4. When I'm just coding something- alternating writing and testing - is much quicker than writing a bunch and then debugging it. For bigger projects, setting up CI/CD early can similarly save headaches.

5. The functional big three (map, filter, reduce), but for me even more so closures. I had gotten stuck trying to hardcode coefficients for a polynomial until I noticed I'd end up with a lot of duplicate code, which was what I was trying to avoid with FP in the first place. Then I realized I could just put the polynomial function itself in a closure and call it with the coefficients I wanted, when I wanted.

Most of the time spent developing is spent making decisions.

To me technical debt is therefore defined as how many decisions you have to make in order to create a feature. Clean is when you don't have to make many decisions to get things done.

Example decisions, I'd say I spend at least 90% of my time developing on these decisions:

- What feature would be good to have?

- Is the feature worth the effort to build?

- Is the feature worth the compute costs?

- What language/framework should we use for this feature?

- How should we structure persistent data related to this feature?

- Where should the code for this feature live?

- How should we test this feature?

- How performant should this feature be?

- What name should this helper function/variable have?

The more of those you have to think about when developing the slower you will make progress. Therefore the main productivity hack is to write down guidelines or roadmaps or design documents for all of those so you don't have to think much about it when developing. This means don't be a manager when coding, let someone else do that work or do it before you start programming.

Things you can do to reduce mental cost of above decisions:

- Product roadmap with features that would be good to have.

- Discussions in the roadmap related to how much value said feature will provide and the effort to produce it.

- Discussions in the roadmap related to how expensive the feature will be to run.

- General guidelines on what language/framework you use.

- Have a very good architectural document describing how you structure persistent data.

- Have list of example commits showing where to put code for different features.

- Have a well documented testing strategy with examples pointing to commits with good integration and unit tests.

- Have guidelines on how much typical actions are allowed to take, like "page update should take 100ms at most".

- Try to write code where you don't need a lot of long superfluous names, namespaces and anonymous functions are your friends.

- Lastly, as much as possible try to make reasonable defaults for shared code. If you have to make 20 configuration decisions in order to use a library then you wont save a lot of time using it, and likely people will just copy the configuration from other places anyway since making 20 decisions is too much work. For example, lets say your library have a flag that can speed up processing 2x in some cases but with extra overhead most of the time. You could think that forcing the developer to decide in each case to ensure we aren't missing any performance improvements would be a good thing, but in reality a 2x performance improvement rarely matters. So the cost of having every developer making this decision outweighs the performance benefit. Instead have it as an optional config that they can set when they actually need the performance.