The VP that I work with acts as a code review czar in the company. I didn’t realize how demoralizing such dictatorship can be until recently.
I have been trying to push a PR that implements a convenience function that I use in jupyter notebook. The whole point of convenience functions in my opinion is that they can be written relatively quickly, and iterated over time, that is, the goal is to achieve efficiency quickly, rather than through extensive polishing.
The VP however wants it to be extremely high quality, in the event it gets used by others in production. Now I am not unused to such strict code reviewers, coming from google. So I offered to move the function to a non-critical file in the mono-repo. He didn’t like the idea, presumably because he thought it would still be abused somehow.
Now I would call that highly misplaced code review priorities, let alone mistrust in senior engineers. There are far more low quality code strewn throughout the code base than the one I was contributing.
In the process of code review negotiation, which I have never been fond of, I offered under his suggestion, to rename the function to something like unsafe_slow_xyz, and to add plenty of warning in the doc-string to indicate non-prod use. I am certainly not well trained to write bullet proof production level code. However I do understand when to exercise such caution and when not to. I found the fact that a VP spends so much time torturing me over a single function implementation to be unwise. It breeds distrust, inefficiency, and represents a form of intellectual enslavement. In the end, I closed the PR as a soft slap in the face to him. I hope he has learned the subtle lesson. Maybe he is so much of a nerd that he doesn’t care about others’ feeling.
A few more things I can add about this: doing such strict code review takes away the fun of data science IMO. All I am trying to do is fill a well-needed gap in the offline exploratory tooling. By enforcing strict code review standards, I am much less inclined to do such altruistic things in the future. Maybe it’s the reason why I don’t have a high rating on stackoverflow.
A second incident happened after I implemented an ad hoc wrapper around popular deep learning framework. This solved the urgent need that the existing wrapper was not able to train production models correctly. To appease the ego of implementers who are a decade younger than myself, I carefully named the project with the prefix “ad hoc” to indicate that it’s in no way a power-grabbing move.
I believe the project was well received, but then there is the initiative to merge it into the existing framework, to become a part of the latter. I had no issue with that either, but what I did wrong was to accept the task of doing the merging. The trouble is that I had no desire to try to understand the design choices of an in-house wrapper of an already very handy open source ML framework. I’d much rather spend my time understanding the latter and doing the least I can to adapt it for in house use, without introducing any unnecessary boilerplates.
But being a nice person that I always appear to be in public, I accepted the task. In the end, I never found time to complete it, but it left the impression of indecisiveness and empty-promise to my colleagues.
The perhaps single source of frustration so far, however, is the use of dependency injection, in an attempt to discipline coders into the most schematic form of writing. By playing with such disciplinary tools, I come to appreciate the value of self-discipline, rather than externally enforced ones. After all, an adversarial can always get around the disciplinary boundary. Massive amounts of effort are currently being spent migrating code to be DI conformant. Several criticisms of DI are in order.
First, the error log is extremely opaque, since the stack trace needs to unwind all the nodes in the DI graph. Now our VP has promised to make the DI stack trace more transparent. But to me that seems to royally distract from the mission of the startup company. This is far better suited for a well-established company, trying to sell an IDE or related productivity software. To hijack the whole company’s engineering culture with a personal pet project seems ridiculous.
Secondly, the use of globals are generally frowned upon in any language, but in DI, the entire graph, which encodes much of the actual logic, is a giant global variable. As one can see easily, this does not play nicely with IDE’s.
Lastly, the implementation of DI in languages other than python is spotty at best. So much boilerplate code has to be added to support it. There is probably a reason my previous jobs never required me to write DI code, even though it has been around for ages. Initially I thought DI will make it much easier to write unit tests, for instance, through free-mocking. It turns out in the ideal world, the different providers are small enough units to tested easily through UTs. But in reality they have so many upstream dependencies that they are just as hard to test as ordinary functions or classes. So their value becomes much less clear to me.
From now until I quit my current job, I will maintain my opinion about certain tradeoffs between convenience and formality. I simply do not believe the various coding standards being enforced have any scientific justification, to quote a colleague who abuses that phrase. It’s more of a strong personal opinion, that must be followed to establish an intellectual pecking order.
I will probably try not to be surrounded with young and testosterone-driven colleagues in the future either: it distracts me from the really important work that matters to me personally. I am surprised that people are willing to give up money to be surrounded by such people. Such people are indeed pretty rare, and I simply made an uninformed bet to be one of them myself. This may be the first job I will leave without reaping the full first year reward, and possibly need to regurgitate some back. But the very reason I left my previous job was to regain the freedom of career change, so I won’t be deterred by such minor financial details.
In the end, work should be fun, not only a so-called learning experience. Of course I am speaking from a highly privileged position.
Aquazorcarson's Blog 