So we started a new Unity video game project for mobile in June 2021. Hooray!

Being a mobile project, one of the earliest things we think about is scaling the interface across all sorts of device screen resolutions and aspect ratios, right? Well, to preemptively solve this problem early on, I decided to letterbox the game view - just choose one aspect ratio for the game and pad black bars to the sides of the screen. Simple, solves the game's world space problem without trying too hard, and it automatically adapts to Android's split-screen mode.

I showed the early builds to management as well as game design team and they gave me some general nods. Sounds like green light ahead. I spent the next few months building the game logic and scale the UI around a consistent letterboxed game view. If you had experience scaling Unity UI to a letterboxed area, you should already knew that it takes a whole paradigm of its own that's kinda hard to break out of, but the fact that it stays consistent across all screen aspect ratios is so worth it. Regardless, the biggeer benefit of letterboxing is simpler world space setup. You don't worry about whether this particular area will be overflowed horizontally or vertically in a particular device or not. You have a 9:16 window to view the world through, nothing needs to move at runtime and that's about it.

Fast-forward to early September 2021 and 40+ builds later, the GD started having concern that the playing area is not filling up his phone screen and that the letterboxes are bothering him. He wants to get rid of the letterboxes and wants the game world as well as UI to fill up his screen.

Yes. After 40+ builds, for all of which the letterbox was present, nobody in the project raised a concern about the letterbox. It's only NOW that they all of the sudden side with the GD and demand the removal of the letterbox. I feel like almost half of my effort on this game has been wasted. These clueless guys didn't spend one second looking at the early builds thinking of the possibility that the black bars at the top and bottom of their phone screens (which I repeat: has been around since the very first build) is gonna bother them? Somebody must be playing a cruel joke at this company. They had all the chances to bring this up as a potential issue and TODAY is the first time I hear of it.

See, designers. You waste our time and your time by doing this kind of thing. Please raise your issues early. Complain to us ASAP. If you wait for so long before raising an issue that has been in-your-face the whole time, I can't fault any developer for assuming you're trying to play a long prank. I can tell designers right now: it's not funny.

So at our company, we use Google Sheets to for to coordinate everything, from designs to bug reporting to localization decisions, etc... Except for roadmaps, we use Trello for that. I found this very unintuitive and disorganized. Google Sheets GUI, as you all know, was not tailored for development project coordination. It is a spreadsheet creation tool. Pages of document are loosely connected to each other and you often have to keep a link to each of them because each Google Sheets document is isolated from each other by design. Not to mention the constant requests for permission for each document, wasting everybody's time.

I brought up the suggestion to the CEO that we should migrate everything to GitHub because everybody already needed a Github account to pull the latest version of our codebase even if they're not developers themselves. Gihub interface is easier to navigate, there's an Issues tab for bug report, a Wiki tab for designs and a Projects tab for roadmaps, eliminating the need for a separate Trello account. All tabs are organized within each project. This is how I've seen people coordinated with each other on open-source projects, it's a proven, battle-tested model of coordination between different roles in a software project.

The CEO shot down the proposal immediately, reason cited: The design team is not familiar with using the Github website because they've never thought of Github as a website for any role other than developers.

Fast-forward to a recent meeting where the person operating the computer connected to the big TV is struggling to scroll down a 600+ row long spreadsheet trying to find one of the open bugs. At that point, the CEO asked if there's anyway to hide resolved bugs. I immediately brought up Github and received support from our tester (vocal support anyway, other devs might have felt the same but were afraid to speak up). As you all know, Github by default only shows open issues by default, reducing the clutter that would be generated by past closed issues. This is the most obvious solution to the CEO's problem. But this CEO still stubbornly rejected the proposal.

2 lessons to take away from this story:

- Developer seems to be the only role in a development team that is willing to learn new tools for their work. Everybody else just tries to stretch the limit of the tools they already knew even if it meant fitting a square peg into a round hole. Well, I can't speak for testers, out of 2 testers I interacted with, one I never asked her opinion about Github, and the other one was the guy mentioned above. But I do know a pixel artist in the same company having a similar condition. She tries to make pixel arts using Photoshop. Didn't get to talk to her about this because we're not on the same project, but if we were, I'd suggest her use Aseprite, or (at least Pixelorama if the company doesn't want to spend for Aseprite's price tag) for the purpose of drawing pixel arts. Not sure how willing she would be at learning new tools, though.

- Github and other git hosts have a bit of a branding problem. Their names - Github, BitBucket, GitLab, etc... - are evocative of a tool exclusively used by developers, yet their websites have these features that are supposed to be used by different roles other than developers. Issues tabs are used by testers as well as developers. Wiki tabs are used by designers alongside developers. Projects and Insights tabs are used by project managers/product owners. Discussion tabs are used by every roles. Artists can even submit new assets through Pull Requests tabs if the Art Directors know how to use the site interface (Art Directors' job is literally just code review, but for artistic assets). These websites are more than just git hosts. They are straight-up Jira replacement with git hosting as a bonus feature. How can we get that through the head of non-developers so that we don't have to keep 4+ accounts for different websites for the same project?

Got a CTO at my Unity job that's younger than me, which by itself is fine, but the only reason this guy was put into that position was because the previous CTO left the company at the time where I was relatively new and he is the person most familiar with the codebase of our primary project than I was at the time.

I understood the decision at the time, but still, having a position of power being handed to them just as a matter of inheritance doesn't command my respect. Nevertheless, I withheld my judgement at the time to see how his leadership goes.

Not even 1 year in and this young CTO started making jabs at me, calling my code hard to read and incomprehensible, to my face, in front of everybody else.

Motherfucker, I don't find his code easy to read either but I went out of my way to frequently ask him, the previous CTO and other teammates to clarify what they wrote here and there. He on the other, made no attempt to ask me for clarification and instead waited until company meetings to air these grievances.

Our boss started to ask me to follow SOLID principles (even though he can't recite what that acronym means) due to complaint from the CTO guy, even though the CTO guy doesn't even follow SOLID himself! But I took the higher road and didn't flip it right back on him.

What I did propose in return though, is that the dev team start using pull requests and have a code review process if the CTO wants to sign off on everything that gets in the codebase. Sounds reasonable enough, right? Not for this guy! He immediately starts complaining that reviewing pull requests would be more work for him. Motherfucker, you refused to go to my table to ask for clarifications about my code yet still want to understand what goes on, then do code review.

It was at this point that I realized that this guy doesn't actually want me to write good, clear code. He wants me to write code HIS way so that he can understand. Yeah okay, I can accept that idea in isolation. Some open-source projects require contributors to follow certain coding convention to make the maintainers' job easier too. One project that immediately came to mind is "In-game Debug Console for Unity 3D" (disclosure: I am a contributor to this project)

But guess what?

THIS COMPANY DOESN'T HAVE A FREAKING CODING CONVENTION. NOT WRITTEN DOWN ANYWHERE. NOT EVEN A VOCAL ONE.

What this CTO guy wants from me is a complete blackbox.

To all fellow devs out there, I hope you don't work with a CTO like this, or become one.