valand

7 ms·

31.
by valand 3y ago
Basically, pushing (e.g. revving) an engine beyond its structural limit.
32.
by valand 3y ago
I found Donella Meadows' book insightful, but I only read it after I understand system thinking so I might be biased. I wonder how insightful vs confusing it is to people from different paradigms
33.
by valand 3y ago
The author uses the general meaning of the word and not the now-popular subset meaning: scientific theory.
34.
by valand 3y ago
Even this is an over simplification of inversion of control. Dependency injection is one form, but even a library that exposes parameters is also a form of inversion of control. The degree of control is what varies, whether it is a mere fla
35.
by valand 3y ago
Often the people who overfocus on the beauty of the flower are those detached too far from the customers, too many indirections that hide failures and pressure
36.
by valand 3y ago
I always deplore this shallow influencing of design patterns without proper examination of whether said design pattern fits or is even correctly described by the popularizer. People fail to realize that inversion of control is necessary ONL
37.
by valand 3y ago
It's neutral. However, a brief negative implication: it's less "idiomatic", as in the pattern that's commonly advertised as best practices
38.
by valand 3y ago
> but articles like this one are probably the things that can lead to the kind of unproductive bikeshedding that is sometimes experienced in PRs and other discussions I'd counterargue that if these trivial principles are established
39.
by valand 3y ago
Not even strictly DOD, this trivial principle produces better semantics and drives better code separation down the line. Several years ago I was exposed to DOD (and then this principle) when working on complex JS/TS-based for long-runn
40.
by valand 3y ago
What's more curious is why is it becoming popular nowadays. The internet, of course, factors into it. But ideas don't stick only through dissemination. The adopters of the idea need to be able to relate to the idea to some degree.
41.
Show HN: Vaettir-React – Control Inverting Agent Library for React Apps(github.com)
1 points by valand 3y ago|0 comments
42.
Systemic TypeScript(valand.dev)
1 points by valand 3y ago|0 comments
43.
by valand 4y ago
One factor of why Java is so crowded is because the capital city, Jakarta, is in Java. Back when I was a kid (I lived in Java), urbanization is quite popular thing. People from all country go to Jakarta and other major cities in hope that t
44.
by valand 4y ago
I do creative work. Doing house chores in between work often put my mind into an idyllic state and it gives me flowing ideas, akin to when we procrastinate.
45.
by valand 4y ago
For me, the reasons are: - PHP's capability is limited in a sense that its main use case is akin to a template engine rather than a full fletched executable. This puts a lot of limit in PHP - TS steps up JS' game. Like what other
46.
A skeptic’s guide to software architecture decisions(infoq.com)
110 points by valand 4y ago|4 comments
47.
by valand 4y ago
No :v I might have picked the wrong word "measurable". It's better to stay away from ultra-narrow measurement. "When a measure becomes a target, it ceases to be a good measure" Instead, put the phenomenon in their
48.
by valand 4y ago
> But the overall system becomes a little more brittle, and a little harder to reason about > minimize the amount of brainpower I needed to understand my code > weighing it against the larger system. If you haven't try convert
49.
by valand 4y ago
Sometimes people disregard history in a very obvious way. One time there is a person who wants a system rewritten, because of some perceived complexity. The original builders who built the system from the ground up is still actively maintai
50.
by valand 4y ago
I was enrolled to a piano course before I developed interest in music. And then classical guitar. While I knew the theories and excels in mandatory music classes at school, music didn't click at least until a decade later in which I re
51.
by valand 4y ago
When I shared this to my colleague, I call it "dynamicizing statically-known info". It is in the same family as putting hardcoded values in a list and calling a .map to it. It almost always end as a premature abstraction.
52.
by valand 4y ago
It comes down to how deep the type system of a language support this kind of operation. It'll work well with TS, Rust, but it doesn't add much to golang, C++. But well, usually dynamicizing statically-known types yields premature
53.
by valand 4y ago
Be even more DRY by having function that does quite a bit of everything, accepts different arguments, and returns different type. You only need to supply different strings to the first parameter
54.
by valand 4y ago
It can be combinations of both. Many deeply nested small ones is convenient for objects/actors/agents/entities with different lifetimes.
55.
by valand 4y ago
Similar to some strong sentiments in this thread, we don't use common state managements. Mainly because they doesn't suit our need and requires us to learn more unnecessary patterns. My company is building app with quite a set of
56.
by valand 4y ago
Location: Indonesia (with high possibility to move to Stockholm, Sweden next January) Remote: Yes Willing to relocate: No Technologies: Rust, TypeScript, React, NodeJS, Electron, SQL, NoSQL, Docker, Git Website: https:/&#x
57.
by valand 4y ago
Reminds me of this quote "A wizard is never late, nor is he early, he arrives precisely when he means to"
58.
by valand 4y ago
I used to enjoy it. We make a platform and toolings for game devs and publishers. Back then when it was small everyone is thoughtful toward everyone else. Then there's the hypergrowth phase. It's good for the money. But the cultur
59.
by valand 4y ago
It might sound cliche and not based on a professional psychological, but the advice I'm about to give is working at the least. I had been at your position too and it helps. You are losing and with that state of mind you might be attemp
60.
by valand 4y ago
I feel you in this regard. I presume low code/no code comes from the simplest notion of programming language, which is a medium between human and machine. And the easier it is to read and write means the "better" it is. There

More ›