aboutme.txt

- I'm a software engineer
- I refuses to believe in magic, but I somehow want to make magic happen to those who believe it, even if it's not magic; without proper scrutiny, it feels like magic, but it isn't. Even though I don't like being around people who believe in magic, nevertheless, there is wisdom in having people believe in magic, and it's that they are busy with their lives, and their lives are chaos, and they need that chaos managed. Anyone who can help them is—in their eyes—practicing witchcraft. But deep down inside, I know that it isn't witchcraft; I just know how the world works, so deeply, that I can find where their problems lie, and where and how to solve it. The analogy of magic is fitting. Although a large part of what a magician practices is the art of deception and illusion, but at its essence, it's the information asymmetry. Although, I deeply believe in empowering people to be highly knowledgeable, that said, in the end of the day, the parallel to be drawn between me and that magician, is that him and I know a lot of how things work. But the difference is, I like people being knowledgable; magicians thrive in information asymmetry
- as much as I despise this recent movement towards vibe coding, I can respect some aspects of it; the tools that emanates from atomization of things, via the process of tokenization, and assigning a direction to tokens (in the form of a vector). Most people who think of code as a means to an end would often end up writing long drawn out functions and procedures, that have been duct taped together. I like to ask the deeper, more finer questions. The questions that will unlock cross-domain pollination of solutions. And this requires breaking problems down so finely, that parts of the solution can be pulled out and applied elsewhere. LLMs do this, but as tokens. But tokens without context are meaningless. So my idea of an "atom" has an element of elaboration to it, but still a unit much smaller than a whole procedure. Then if atoms don't make sense on their own, we got molecules. From experience, LLMs get it right about 99% of the time, but 1% of the time, it's clear it's a stochastic parrot. I don't want stochastic parrots. I want solutions that, regardless of problem domain, actually yields something that doesn't trigger a compiler error
- As much as I talk about "pulling out" things in code, most would immediately think of packages that get published to npm or PyPi, or perhaps into classes that adhere to SRP. But I actually don't believe in that. I believe the unit isn't a package or a module, but instead an idiom. And I firmly believe in finding these idioms, writing them up somewhere, and sharing them, and using them to solve problems, even if it means duplicating code everywhere. I mean operators in syntax is repeated everywhere; why can't idiomatic code? Why does it need to be "abstracted" (as used by most programmers; a definition that I don't agree with) into a function or class, and not repeated?
- I hate building buggy software. I've said this numerous times before: if a feature (or software) is buggy, it is no better than it not existing. I have a bias for building simple software; not only because it adds more value than a complex full-featured software solution, but also it ensures that bugs don't seep through. I have nothing against features. Hell, in my hypothetical mental framework, there is no upper bound to the number of features that a software may have. I have repeatedly mentioned that I don't believe in magic, but I like to make magic happen. You know some examples of that? LLMs. Such a simple idea that emanated from several papers worth of refinement, then a breakthrough simplified it more, in the 2017 landmark paper "Attention is all you Need". That's the kind of magic that I love. But even before LLMs, what was also magical is the idea of Turing completeness. The moment something is proven "Turing complete", this is where things feel magical; anything is possible (given enough time and resource).
- My personal philosophy is, if a product doesn't doesn't implement some form of emergent generality—such as Turing completeness, graphs, etc.—to implement (I prefer the term "surfaces" more than "implement") new features, but still has a tonne of features, surely there was an idiot somewhere that worked more than they should have to get the product out
- I don't like me-too products. Some people trying to copy features don't realize the story behind why they even exist, and they just copy. Does it exist because customers actually wanted it? Is it a short-term fix for specific customer needs? Does it exist out of some emergent generality (e.g. procedural generation)? Why not think outside the box? It's OK to "copy", as long as it is intentional (e.g. researched the intent as to why it exists). Or "copy" because they see opportunity beyond just trying to gain marketshare, in hopes of more breathing room (to which I'd say an aphorism in the same class as "if you're not happy single, then you won't be happy in a relationship"; if you need quick fixes to get a few customers to make money, then you won't have customers nor any money. In other words, you're operating in a red sea)
- I believe that beliefs must be earned, and must be defended against
- An anecdote: I've worked with a company that was working on a p2p video broadcasting platform, à la Twitch. But of course, by the nature of p2p, the broadcaster may be an end user with just a laptop, with a home broadband connection. Surely it can't provide an acceptable level of quality. The founder of the company thought about having the broadcast only to two nodes, and those two nodes would each broadcast to two other nodes, and so on. It was built with no edge cases in mind; the philosophy was to just ship something, and fix it later. Unfortunately, the fixing strategy involved just patching that up as an edge case. My intuition just sees that as a duct tape fix, which ultimately brought up another bug, which that gets patched up. Then another, which that gets patched up. Ad nauseum. Here's what I think: they should have stepped back for a second, and actually thought philosophically, or epistemologically as to what is it that they were building. Personally, if they thought things through, their first bet at a fix would have been to write some specification, and realized that there are atoms that they can draw from. The atom being a node in a graph, and the graph is managed by something that ensures full reachability of all nodes in the graph. And this solution would have been applicable more broadly beyond just broadcasting. The possibilities would have been endless.
- Most people have this clichéd idea of giving people with low qualifications a chance at a job (costing salary); they frame it as charity that they'd self aggrandize themselves in a LinkedIn post. I give people chances not because I feel charitable, but because I don't know what is right. For example, if our codebase uses TypeScript, I will definitely give someone with just JavaScript experience the opportunity, if they can successfully capture the spirit of why many advocate for TypeScript in codebases; hell, I may give it to someone with TypeScript experience, if they show signs of complacency
- I don't tolerate complacency
- I don't tolerate indolence
- I want to work on something bigger than myself
- I don't play status games, nor do I tolerate people playing status games
- I don't like cynics (the types who are quick to default that others are there to act exclusively in their own self interest, thinking purely zero-sum)
- I may tolerate pessimism, but it has to come with solution-orientation, or highlighting the benefits of what we already have
- A company that I look up to a lot is Apple, who is utterly unashamed for keeping things barebones, even in the face of cynicism from from Android fanboys (and I'm saying this as someone who is an Android user)
- Another company that I have been reading up on a lot is 37signals
- What may have started this movement in me may have emanated from the frustration stemming from me currently working at a job that it's clear that they have a bunch of product managers writing tickets, and devs just turning tickets into running code… For a product that the CEO absolutely requires that can be white-labeled, and customized entirely under a self-serve basis. Remember how I keep talking about the concept of emergent generality? Well, I just wished the company would explore this extensibility, so that they don't end up with unexpected surprises; they most likely will, but at least these ideas are kept at bay. Not to mention, the CEO most certainly would be insanely giddy about the idea that their whitelabel product would extend beyond the current problem domain that they are in right now (video streaming)
- In my own journal, I wrote this: "Truth is not fact. Truth is what is on your mind. You know something. But you only know about it through your senses. And what you know eventually begins to alter over time. The truth is your mind: feelings, recollection of memories, thoughts. Truth is not facts. And the facts that you read are often tainted by the authors, and so the truth that you claim to speak (had you claimed facts were truths) are equally likely to not be true."
- Whenever I take the big five test, I tend to score high in trait openness to experience, conscientiousness, extraversion, agreeableness, and low on neuroticism. But I am quite intrigued by how rather high I score on trait openness to experience. It's usually in the 95th-percentile or more, and I have noticed that I enjoy hanging out with other people who seem to score high on trait openness to experience
- I tend to sit and listen, and spend time digesting what people tell me, before speaking. And if I do say a word, it's usually a question
- I have very low energy for drama
- I love a lot of what Nassim Taleb talks about (although, I have yet to have completed the Incerto). I loved Antifragile and Skin in the Game. One of the ideas that I adhere to from Antifragile is the idea of "Via Negativa". Although, he talks about eliminating risk, but he does use Via Negativa in the context of describing God, And I'm using that as reasons to use Via Negativa to talk about building something awesome, by first building something that doesn't suck (yes, Nassim Taleb, would be PISSED for using his idea like that). The other aspect of his work that I love is "Skin in the Game". I have lots of wild ideas that how thinking in atomicity will empower the building great solutions. I bet my life on it. If you disagree, then you'd better not just have words; put it into action, and own the consequences (good or bad)
- actions speak louder than words. Data speaks stronger than feelings. The latter is important since I don't tolerate manipulative insincerity. Although arbitrage is a great way to get ahead, but it had better not be zero sum.
- among frustrations, what also gave me confidence in pursuing such a mission (even if it means I'll be alone at it for a very long time) started back in 2013, when I first found out about React. AngularJS was pointlessly too opinionated, where as React was—at that time—just another DOM manipulation library that leveraged a pattern (what many would consider an "anti-pattern") of just throwing out the whole UI element (or the whole screen!) for even the most smallest of UI updates. AngularJS' approach is a bit more heavy handed; it demanded stronger ties with the ViewModel, so that it can tie-in with fine-grained component-level UI updates. React, on the other hand, empowered more idiomatic programming. That, and also, at that time, I was drinking the functonal programming Kool-Aid
- What I love about functional programming is that patterns aren't only about object-oriented design to fit a problem domain, but also thinking about data and how the patterns match. Case being? List comprehension. Yes, that's mostly syntactic sugar in Python and Haskell, but nevertheless, ideas were borrowed from them to form idioms that are compatible with functional programming. But you know what? This is fitting, since Haskell is a functional programming language. So many things that aren't traditionally considered "objects" in Java, C#, and—if you really try hard to bring those ideas to this language—C++, but functional programming empowers one to think beyond just objects. You are empowered to think in terms of algebraic primitives, while possible in languages like Java and C#, just feels a little clunky (but I do admit that I have not played with those languages much)
- I previously posted online: "I wish early on, when software developers began adopting the idea of "abstraction", it was used mostly to describe a "class" of patterns more than some layer that merely exists to hide implementation details. Kind of like how math does it. The idea of abstraction is more conceptual than something concrete. In math, abstractions are there because the details are irrelevant, not an attempt to dumb things down."
- I keep talking about grievances, but I did have one success in the past, and I do feel it is attributed to me taking action to prevent those grievances that I have had—and continue to have in projects outside this singular success. This success was when I worked on this dance choreography software. Many dub the project as the "Figma for dance choreography", which allowed for a Figma-like canvas, that people can pan and zoom on, but what's important is that the canvas displayed a formation (circles representing performers), and people can drag the circles around the formation. But get this: the canvas had this magical property where it didn't exclusively show one formation at a time; instead it was a place where people can preview the transition from formation to formation, and even preview the whole performance, all time-synced as the choreographer would have intended. This project started out as something that a bunch of contractors hacked together. When I joined, the project exchanged several contractors' hands. Each one of them would complain about how the code is hard to work with, or that introducing one feature would break something else, but fixing that something else would break that new feature. The problem persisted, then I came along. I noticed that some pre/post-conditions and restrictions, and expectectations weren't being respected, possibly due to product management just creating tickets and assigning them to contractors, and contractors just implementing the feature to the letter, rather than caring about the implications. I actually cared about the end-to-end story, and noticed, that to get things working, each component needs to entirely relinquish the concept of (what I pretty much inferred) as a "ViewModel"; something that listens for events, and updates the underlying data. In other words, there was state synchronization bugs, all because of short-sighted efforts to tackle the surface-level, literal interpretation of tickets, rather than to care about the second-order effects. I changed that by having everything be thrown into a single source of truth, and updates to it triggered a smart, efficient redraw, thanks to React's DOM diffing, and thankfully, they were using React already, just that it was a means to an end, rather than to care about the craft of programming with React. This newly hired highly junior engineer was as a result able to move fast; really fast. It's at this opportunity that I learned about the virtues of atomicity, and most importantly, eliminating domain specificity
- Throughout my career, I've noticed people who build highly elaborate systems, ones where code just can't be moved from environment to environment. It's unclear what is the motivation for it, but I think one of them is that they are attempting to build code that outlives them. If it's true, then I think they are foolish. I've said this before: those who plan to have their code outlive them should strive to write deletable code
- There are two types of system architects that I can think of: those who design glass houses: intricate code where everything is interelated; code that at first felt like things would just slide neatly, but over time becomes brittle; looks beautiful, though. And then those who build brick homes: code where nothing is related, but maybe a solid foundation. Code can be dismantled quickly, and replaced without much problem. I prefer the latter approach: the brick houses.
- Tailwind CSS is a classic example of what I am talking about
- Recently, I've been going all-in on the Fediverse. What attracts me to it is the IETF-styled RFCs, and the clear W3C specifcations. Not to mention, the use of RDF (via JSON-LD) as a delivery medium. For the naive person, JSON-LD looks like a JSON document, but for someone more in-the-know realizes the power of JSON-LD: it's a delivery medium for RDF (and a little more). It's highly extensible. And with JSON-LD, we get to alias the docs in other languages, and still have the document parsable. Not to mention: IRIs. A powerful primitive that not allows for the dereferencing of resources, but also allows to be used as a natural key to be stored in databases, and looked up from a KV-store
- I'm currently working on an AI-based story writing solution. At first I was meh about it, but when the founder talked about small artifacts that can be swapped from stories to stories, I was intrigued. These are perfect examples of things that can be dereferened over the Internet, and addressed using a URI (URL, to be precise)
- I avoid storing too many PIIs. I keep revolving back to the idea of emergent generalities. If I can infer information from just the smallest bit of data that I can have, then great! For example, if I have their emails, then that's good enough to uniquely identify someone, because their emails can double as an authentication mechanism. Or perhaps a social login. Or perhaps a blockchain wallet address. Those are all that I need to get moving
- Regarding functional programming: this is why I love JavaScript. Sure, it may not be a truly functional programming language, but it does treat functions as first-class objects, rather than just an after thought, and this makes for highly expressive code that simply would not have been possible in any other environments, or at least felt too awkward
- I like the idea of 3NF. It has me avoid storing too much information, and it avoids synchronization issues
- I like the idea of event sourcing. Blockchain systems are pretty much that (but I do admit, blockchains are slow)
- I acknowledge that efforts to get emergent generality may be highly inefficient. Take Turing completeness as an example. Once an application is built using whatever that is Turing complete, we can solidify that in the form of hardware; AES is a classic example of that
- I have an appreciation for first-principles thinking
- I have a fascination with procedural generation
- I have a fascination for a lot of cryptographic ideas, namely the concept of a PRP
- I love abstract algebra
- I love the open source world. The fact that forks are a thing, and that there is practically a graph going on. Not just trees, but also lattices (merges)
- I think Git is such a cool piece of technology. Sure, there are stuff that it oversimplified, but you know what? It's what makes Git so elegant. What did they over-simplify? It's the fact that Git stores whole files, instead of just the diffs. That said, of course there are elegant solutions out there to make things more efficient out there, but you know what? Linus Torvalds needed to move fast! Maybe I can come up with the elegant solution to Git's shortcoming with my idea of atomic programming that I keep talking about
- If I can describe my software design style, I'd say that I'm pretty much drawn to the idea of axioms
- I think object-oriented programming is overrated
- I despise the mindset of looking for "what to think" and not "how to think". Hell, I despise "looking things up" at all, and instead exploring the best path
- I worked on this JavaScript data validation library called "hyperguard"—and it is especially powerful if used with TypeScript, because the library surfaces type annotations. But ironically, the library only exists for those who like the concept of "libraries", but at its core, what's truly valuable about it is the interfaces that is documented in its main README file. The library only exists for those who would find it alien to just think in idioms, rather than invoke a set of functions to call. But for the power users, if they want to extend the library, then they're in good hands. In spite of never adding any "extend" method/function, the library is still "extensible". Actually, the library is idiomatic. Not to mention, the library was designed more as a *demo* or set of *examples* for the idioms. It doesn't lock you into the library's ecosystem. What's so special about these idioms? It's the idea of atoms that I keep talking about. At its core, the library's core primitive is the "Validator" interface. And each validator will only validate—true or false–for specific data types. The library exposes several validators for JavaScript primitives. And for more complex validations? Those are composed, by deriving a new validator by invoking—for example—the `object` function that accepts an object of property keys, and values themselves are validators, which forms the *shape* of a perfectly valid objects. Other functions include things like unions, intersections, tuples, arrays of, etc. But don't like the functions? Write your own! As long as it comforms to returning a perfectly valid "Validator" object. Highly composable, and so simple, yet so powerful. This is what I'm talking about when I talk about emergent generalities.