august

Optics Oriented Programming

I recently resigned from my job at a healthcare engineering firm. It was the most fun I've had, and I'll look back fondly upon many memories I've had. But I must take this opportunity to talk about a less-often discussed phenomena in corporate firms I like to call "Optics Oriented Programming".

Computer Scientists are often unique amongst other STEM fields - while every other STEM graduate joining the workforce has the privilege of being managed mostly by other engineers, Computer Scientists often have to report to a non-technical manager.

Now, don't get me wrong - a non-technical person, given their ignorance, dare to dream bigger. Steve Jobs was needed to make an iPhone - his assholeness and his lack of ceiling both helped make the iPhone. An engineer would've calculated every way this won't work, completely wrongly estimated how much do people even want this, so on and so forth.

The engineering mind is supposedly logical - I'm never afraid to fly in planes because of statistics, despite having a fear of heights. The logic overrides all other decision making capabilities. To be clear, logic is portrayed as this coveted masculine trait - but of course, that is not true - neither is it masculine (there is a societal push by patriarchy to normalize masculine emotions as logical) and neither is it coveted (a pure logical approach to anything is detrimental to product). It is simply a trait found in higher doses among engineers. Product Managers will often have higher empathy, which itself manifests into an engineer as pride of presented work, but is more inwardly and insulated.

However, to keep engineers engineering at your company, you cannot expect and push for an optic forward culture. I understand that the way healthcare software is structured, you often expect showboating, it is only natural. I'd hop on calls with companies that started this field, and they'd take 3-4 months to create a simple Slack channel. When the bar is so slow, peacocking your slightest achievements means you're pushing yourself to the top of the food chain.

My company used to have this process of QA - without a QA team, it was a bunch of operators QAing our builds that integrate with reverse engineered third party systems, and of course, they'd break time to time. This would get escalated, and in return, a product manager (with the best intentions!) with no context on our systems or deep expertise in writing code would reach out, expect 100% QA pass rates. Happened for 3 quarters, they never got the hint. After this process, a leadership wide email would be sent, to every exec, with the minutest failure highlighted in bold and red "FAIL! FAIL! FAIL!". Who this advantaged, the engineering teams don't know yet. Who this was tiring to, we all knew - us.

I did 30 such integrations, maybe more, close to a million $ ARR, and from experience I can tell you, this badgering didn't improve our actual integrations, and lowered our developer experience. After a point, I might as well be in a sweat shop being waterboarded everytime a "ROS" (a common used field in a doctor's internal note) was printed out as "Review of Systems".

Of course, this culture of showboating permeated elsewhere - we'd use Python to write backend for systems that needed fast and reliable responses. Django would've been an acceptable (though I'd personally not hire a Python engineer to write my generic backends - but this works well at new companies where we actually have processes), but we used FastAPI and all 8-9 teams had one monolithic backend. Of course, this was peacocking - "We got our backend systems done fast! And it's all in one place!". This propagated to frontend teams too - our excellent mobile developers, were left to maintain Flutter for Web because "If we use Flutter everywhere, we wouldn't need to maintain another team to do the React version!".

So where do we go from here? Often the YC advice is "Do things that don't scale" - and of course, they're right from their pespective. And from my POV, I say - "Don't miss the forest for the trees, but damn well make sure you know it's trees" - or something deep like that.