This could be us, but ya'll playin'
It’s incredible, the performance of the 3D rendering, but as this relates to ▒▒▒ I’m more focused on the space optimization. All the code for that—renderer, tracker, physics, assets, everything—fits into 13kb! And even more than that is the mindset behind the approach. The guy had a hard limit of 13kb, and so he changed his point of view to find different and novel approaches in order to meet it. That really captures a lot of what I find wrong about Robmunds' perspective—they refuse to change their minds.
Rob doesn’t rearrange the deck chairs on the Titanic so much as he performs preventative maintenance on them. He’s constantly nickel and dime’ing everything, making noise about, literally, single characters of unminified code instead of looking for the big wins like this, the changes that actually move the needle.
Tags: work
Hoarders
Working with Robmunds' code is like visiting a hoarder's house. You walk in and see massive amounts of trash ALL OVER THE PLACE. You want to clean it up and make it better, knowing that it's a massive job, but you immediately see places that would be very easy to get started improving the living conditions, like that pile of old soda cans. So you walk over and start picking them up off the floor, but then Robmunds runs over, panicked, "Stop! Don't move those! I put them there!"
Rob doesn't know how to design software. I know that sounds harsh and may cause confusion since he's the "chief architect", but his insight into the workings of the code is primarily due to the fact that he's the one that made the piles—he's the hoarder! He genuinely knows where nearly everything is just as in the hoarder's house if you ask them "Where's the Sports Illustrated December issue from 1977?" they could tell you "It's in the pile in the corner about 6 inches from the top". But the fact that he knows where everything is within the piles of code does not mean that the codebase has a proper organizational structure. A valid unit of organization for code is not the pile.
And the fact that Robmunds can't see the problems IS the problem. It means that when you try to pick up the trash from the floor, they don't like it—they think it's a good design the way it is and insist that you put the trash back where they had it or, if pressed, insist that we can't take time to clean up or some other excuse.
Robmunds' ineptitude is pervasive and affects all aspects of their work and approach to work. For me, the most telling is how they respond to new ideas, such as design patterns (setting aside the fact that such basics of software engineering are not part of the toolbox of a "principle engineer" and the "chief architect"). They will occasionally sprinkle some of those "highfalutin" words into their speech, but you can hear in their voice their simultaneously giddy desire to use such emblematic jargon, along with their self-conciousness over feeling judged for using it (and perhaps fear of their lack of actual understanding being revealed). They claim that it's all just philosophical, academic ivory tower nonsense and unnecessary for "getting things done", but they're simply and totally wrong.
In school, my focus was on theoretical computer science which is basically just applied math. Complexity, computability—those were the things I was interested in; I was an ivory tower snob. When I first encountered the concept of Design Patterns I looked down my nose at them. "Patterns are just cookie-cutter recipes for those that can't think for themselves." It wasn't until I got my first engineering job that I learned the importance of having a toolbox of well-defined and understood concepts that could be applied and used to communicate with other engineers (I think the communication of design and intent with other engineers may be even more important than the application of such patterns).
Rather than detached philosophical, academic trivia, these concepts are quintessentially practical, with such immediate applicability so as to be fundamental to engineering, but I bring them up here not as shibboleth, but as litmus test for the real shibboleth—how does one respond to new knowledge? When I got my first engineering job and saw the level of competence, both in-person and in-code, I thought "These guys really know what they're doing. I need to step up my game and learn this."
When confronted with new knowledge does one embrace it (as I did), or reject it (as they do)? When they dismiss, and indeed actively avoid learning, such concepts they don't come off as "old fashioned" like they tell themselves they do. They're simply outing themselves as amateur hacks, just fucking around instead of engineering.
Tags: work
Rob's bullshit
bc -l <<< "$(cloc --vcs=git --include-lang=JavaScript --include-ext=js . | awk '$1 == "JavaScript"{print $5}') / $(git grep -wc 'if' './*.js' | awk -F: '{sum += $2} END {print sum}')"
Every 8 lines of code in ▒▒▒ is an if statement. Every 8 lines. I've never paid much mind to my use of if’s. It’s not like I ration them, but the sheer volume of them in ▒▒▒ caught my attention.
Imagine a cook, wandering around a kitchen and every 8 seconds he has to ask wtf he's supposed to be doing. "Should I cook this? Should I stir this? Should I flip this?" It wouldn’t be long before his boss pulls him aside. "It's not that questions are bad, but why do you need to ask so many? Don’t you know your job? Why don't you know what you're supposed to be doing?”
And they legitimately do need to ask—because there is no structure to our code. It’s like finding some old tupperware in the back of the lab fridge with a piece of masking tape that says fresh delicious cheese. Do you just pop it in your mouth, or do you ask some questions first? You ask questions because you don’t know what’s in there! It says "cheese", but how do you know? There is nothing to stop someone from putting literally anything else inside that container.
That’s our code. We don’t have well-defined objects; we have some old tupperware with masking tape that says “Chart” and they know that they can’t just assume what’s inside and so they have to ask. Every 8 lines.
Because they reject anything more complex than popsicle sticks and hot glue, they have no control over what anything is and so they’re left with no choice but to ask. Every 8 lines. In a properly engineered system, the structure would tell you so much. When you call Promise.resolve() do you need to ask if(Promise.resolve) first to see if it exists? No, because there is structure that defines what it is. But they have no structure, just if statements. 17 thousand of them, or 1 out of every 7.8 LOC.
I guess I'll just throw this on the pile of shit that I can't do anything about.
Tags: work
What a difference two years can make
…or, you know, 6 months.
There was a lot of promise in this place. And I wanted it to be awesome; I wanted it to be paradise. I wanted it, badly. I'm now on my way out. If I can find someplace better, or if I can get my business bootstrapped, I will be out the door so fast I won't be able to hear them bad mouthing me to reassure themselves that "he just wasn't good enough to be able to handle how awesome we are".
I have written so much in my vimwiki diary and local BB. I will re-post some here, but these guys are sophomoric, at best. It's so bad that trying to articulate the what and the why of their incompetence has actually been useful in helping me understand them as anti-patterns.
As an example, I unintentionally began fixating on their absurd volumes of if statements which led me to question myself (because, unlike them, I actually have intellectual integrity). "Why are their if statements not okay, but mine are? Is it a double standard?" In dwelling on that I believe I've come to a valuable observation: conditional statements should be used to check state, not structure. I use conditionals and don't feel bad about them because I'm checking state. They have to have conditionals—literally—every 7 lines to check structure because they have no defined structure. Any piece of data has to be deeply inspected because they know it could be anything. It's no wonder they have so many conditionals.
I wanted this to be "the place", but it's not. And, in having now explored a number of companies beyond Yieldex, I have to conclude that I simply got lucky right out of the gate with my first startup. Yieldex seems to have been an anomaly of competence; most everyone else seems to have very little idea what they're doing.
I am forced to admit the truth of my situation: I need to be either employee #3 or employee #1.
Tags: work