Following a previous question of mine, in which I try to find ways to be quicker on expense of more dirty code, I think I managed to get more stuff done today, with the premise that when they break, neither I (nor others) will be able to do so again, and the fix will be slow & dirty.
I have now reached several situations in which the boss, being a boss, still expects things to be quick.
He is not dumb, and he is technically capable and very smart. He understands the value of order and infrastructure, and chooses to delay that in favor of getting things done now. When he does things, he does manage to be even more dirty, while holding in his head where things break, and what he can handle later. Despite trying my best, I currently can't.
How can I deal with his expectations of me, which I sometimes find unrealistic? From his perspective they are realistic, also backed up by another developer who is able to work this way. I view her as a genius, remembering absolutely everything from years ago, and being very fast coming up with hacks.
Both their codes are horrible: adhere to no standards, using no existing infrastructure, and many times containing bugs which are only encountered later.
I need a way to communicate being just an ordinary human, who thinks in an organized manner, unlike them, being able to think in some different way. At least until I get used to another way of thinking.
There is also a performance review looming, in which I already know the verdict: "Your work is of very high quality, but you are slow. We need a different balance of you [and we can't tell you HOW to do that {I asked multiple times}]"
From the comments, the gist of the question:
I want to communicate to my boss that the reason why I cannot provide a quick solution to a problem is because of the technical debt that has accumulated from previous quick and dirty solutions [created mostly by him], though I have a coworker who is capable of doing quick and extra dirty solutions in these situations. Result being my boss thinks I should be able to do likewise.
What I tried
- I tried to explain that when hotfixing, it becomes very hard to understand the source of problems, thus costing more time, not even in the long term.
- I tried to prove that stable code saves time by actually writing it.
- I tried to show that if we work together, one of us can do work for everyone instead of all of us working solo ad-hoc.
He replies: "We are building a ship after we are already in the ocean ." [True]. He doesn't see the code that doesn't make problems, he sees code that does. So, when I try to automate things and introduce a bug, it is a problem, but if I had done it ad-hoc and introduced a problem, it's fine b/c I tried to save time.
He doesn't buy in to the working together frame "until we have a stable workflow [how? we aren't building one!], at which point automation will make sense".
He is very startup-minded.