!!office drama

I haven't been around much in recent weeks. Due to family illness, christmas shopping, dealing with estranged parents, and brooding over the foregoing, I haven't had a lot of time or energy left to myself.

tl;dr: The CTO ("API Guy") is ostensibly getting fired, and I might be taking over his job. I don't know if I should accept, try to stave this off, or simply flee.

------

Anyone who has been following my recent rants knows that API Guy is my boss, and he often writes terrible code. It's solid and unbreakable, but reading it is a *nightmare.* One of our applications is half the length of Leo Tolstoy's War and Peace, and it's difficult to tell what code is live and what amounts to ancient, still-active landmines. This is one application; we have several, most of which I've never even looked at.

Ostensibly the code is so terrible because the company grew extremely quickly, and API Guy needed to cram in lots of unexpected / planned-against features. From what I can see, that seems about right, but I haven't checked timeframes [because that's a lot of work!].

Here's a brief rundown of the situation.
- API Guy co-founded the company with the CEO.
- CEO and API Guy have been friends for a long time.
- CEO belives the company will fail with API Guy as head of tech.
- They could just be testing me; I have zero way of knowing. API Guy seems totally oblivious, and CEO seems sincere, so this feels pretty doubtful.
- CEO likes pushing people around. CEO believes he can push me around. API Guy doesn't budge. (I probably won't, either, except to change task priorities.)
- API Guy's code is huge and awful, but functional.
- API Guy is trying to clean up the mess; CEO doesn't understand (maybe doesn't care).
- Literally nobody else knows how the code works.
- Apart from API Guy and myself, the entire company is extroverted sales people.
- None of these sales people particularly like me.
- Sales people sell and sell and sell without asking development if they can pull enough magic features out of their hat to meet the arbitrary saleslines. (because the answer is usually no)
- If I accept, I would be the sole developer (at first) and responsible for someone else's mountain of nightmarish code, and still responsible for layering on new features at the same pace as he. Pay raise likely, but not guaranteed.
- My getting the position is contingent upon the CEO and the investors, meaning it's by no means guaranteed.
- If I don't accept, likely API Guy will be replaced with someone else of unknown ability, who doesn't know the code, and whom I must answer to regardless. Potentially OK, potentially a monumental disaster.

Honestly, it feels like I'm going to be screwed no matter what course I choose.

Perhaps accepting is slightly better?

The best would be to assume the position of CTO and keep API Guy around -- but that would feel like an insult to him. I doubt he'd be okay with it. But maybe. Who knows? I doubt the CEO would seriously consider that anyway.

I feel like a lamb between a dim, angry rhino, and an oblivious one.

"Assumptions are the mother of all fuck ups"

"Nothing is unbreakable"

Today I continued working on my File Encryption Frontend, nothing functional, yet!

The icons are selfmade, I think at least the folder icon is pretty.

Our programm will have something like a Zip-Explorer feeling too it, but our aim is still encrypting files to the unbreakable point.

2 things I'm working on now:

#1 a personal project I am hoping to commercialize and turn it into my moneymaker. Hoping it'd at least be enough to pay the bills and put food on my table so I could forget 9/5 for good. But it has a potential of becoming a much, MUCH bigger thing. This would need the right twist tho, and I'm not sure if I am "the right twister" :) We'll see.

#2 smth I'm thinking of opensourcing once finished -- a new form of TLS. This model could be unbreakable by even quantum computing once it's mature enough to crack conventional TLS. I'm probably gonna use md5 or smth even weakier - I'm leveraging the weakness of hashing functions to make my tool stronger :)

I mean how long can we be racing with more powerful computers, eh? Why not use our weakneses to make them our strengths?

Unittests are already passing, I just haven't polished all the corner-cases and haven't worked out a small piece of the initialization process yet. But it's very close

I love Test-Driven Development!

And because of that fact, my heart shatters into thousands of pieces, when I recognize error events on our production nodes which are pointing onto a golden hammer function in a legacy project.

This particular function has about 300 lines with a bunch of subfunction calls and instantiations of helper-classes returning information for workflow.

Refactoring this code to apply proper unit-tests requires a way bigger investment than simply deal with 30 eventlogs a day, because this kind of payment is barely used by customers of our webshop.

This fact is a little itch each day of my work.

Guess it will make me go insane one day
¯\_(ツ)_/¯

xD

When people think 100% test coverage indicates your code is unbreakable..

Even if he's a younger guy than most other examples, my mention is:

Jordan Walke

He's the inventor of React, which probably changed the way to write (web-)apps for a lot of people and was based on a prototype written in StandardML.

He's also created ReasonML which is not only in many ways a more fitting language to write React, but also a good systems language (props to OCaml and it's unbreakable type system). Many React concepts/patterns have their origins in functional language concepts, including reducers and hooks.