[yuy910616]

Glad to share but I'm not sure if I'm representational - I'm a data analyst who is learning more about backend engineering.

I think if you're a SWE or has a CS education or worked with a compiled language before, you know exactly what kind of problem typing is solving. For me, I have to first discover the problem, slowly learn that there is a solution out there, and finally realizing that my problem can be solved by this solution.

The formalization of problem space + the discovery of solutions + the final realization of matching solutions to problems are non-trivial. I'm a bit embarrassed that it took so long and a bit sad. But it is what it is.

[wonton53]

That makes perfect sense actually, thank you for taking the time to answer. And I’m indeed a SW eng with a degree, so spot on. I do something similar to data analysis «for fun»/non professinally but my day job is payment/banking systems. Live payment systems and settlement systems are both very different from analysis tasks. They have all the focus on «correctness» and integration interfaces with other organizations (which are ALWAYS wrong because «they» don’t understand types/strict interfaces). While analysis in my experience is dealing with tons of dirty data sources not in real time or the code will even just run once (not millions of times). I always go to cleaning the input and validating the data, but I suspect that is because of my day job and i feel it is less valuable to put in this effort than it is for my day job. So I have myself also skipped using types many times to learn whatever library I need or to iterate quicly (minutes compared to days). For example, it is very comfortable to just let pandas give you 0 for NaN when you just want a plot. So I understand it takes more time because the value of types is probably much lower to you in absolute terms.