←

A Short Stint at DUKUMU & horizontal/vertical development

2024-08-06

Table of Contents

I really wanted to like DUKUMU (names have been altered, but the all-uppercase name is pristine). A small, friendly company, based in both the US and Japan, who hired me to work on a product, BYOLD (also all-uppercase), really well-aligned with my own interests and professional experience. Unfortunately, I was only there for about a month.

The interviews went well, and I started on June 13th, 2024. I loved the people in their Tokyo office, and I bribed tried my best to make them like me too (brought donuts, a home-made fruit pie, gifted a milk frother to make cappuccinos, etc.). I suggested some changes here and there and made little tools to help streamline things, all enthusiastically welcomed. People told me later on that they had enjoyed my “fresh and creative” take on things and were looking forward to more.

Alas, it was not to be.

Disclaimer

For most of my career, I’ve been insanely lucky (I might say spoiled) as an employee. I worked for large organizations that treated their workforce extremely well. Most workers in the world do not have the luxury of criticizing how their manager behaves with them, or complain about someone’s bossy tone. Most don’t have the financial stability to quit a job after just one month if they don’t like it.

That being said, this is my extremely pedantic and unforgiving post, partly to get this out of my system (I tend to do that), and partly to have something to reference when people ask me.

Reason #1: Basil

I’ll start with a simple situation.

Because it’s a navigation

BYOLD, a web application, had wording that I found odd when I first used it. The initial page had a button that read “Go to Sign In”. Once logged in, another link read “Go to Sign Out”. Most applications would simply read “Sign in / out” (or “Log in / out”), and I thought the “go to” wording may be confusing to users.

We were 3 engineers working on the BYOLD team. Mehari, based in Tokyo like me, was sitting next to me as I noticed the unusual wording, so I asked him what he thought. He agreed and said he had been mildly bothered by it as well.

So I prepared a very simple proposal to change it. If anything, it was a bit over-polished, with before/after screenshots, for such a small and (I thought) uncontroversial change. But I was still new on the team and wanted to show that I was thorough, even for something small like this.

Enter Basil, the third engineer on the team, who was working remotely. Apparently I had stepped on a piece of Basil’s protected garden, because he promptly replied: ‘It’s “go to” because it’s a navigation.’ (the 👑 icon is, obviously, my addition):

That reply struck me as 1) unnecessarily condescending, 2) rather terse, and 3) not really welcoming any further discussion. I was baffled. Note that in my reply below, I am trying my best not to be assertive (question marks) and to include examples of well-known applications for support.

Still unsure about whether I was being weird about finding this so obvious, I tried to gather more data, and went back to the rest of the team (designers, etc.), asking for “yay/nay/suggest other wording” for this change, on Slack.

Basil saw that thread but decided to refrain from interacting nor explaining a little more why he preferred “go to”. I quite like, from the rules of ensemble playing, rule #11 “If you alone are right and everyone else is wrong, follow the wrong.”

Maybe he realised he would have to back down, so he reverted to criticising the “how” instead of the “what”, so that he could feel he was still right?

The idea of “tweaking text strings” in “one pass across the app” was so fundamentally contrary to my conception of software development that I was even more baffled.

In my mind:

Is it a common approach, if a given issue is small (or the fix not “impactful” enough), that we should actively refrain from fixing it, and instead make a note of it and fix all the small issues together at the end? After having been increasingly bothered by all the small kinks left unfixed until then? Playing the devil’s advocate, for something like the change of a colour, that could make sense, because all colours interact with one another, and it’s perhaps better to change them all in one go. But in this case, I am still scratching my head. While we’re at it, if we need to launch on Sept 1st, let’s do exclusively new features starting July 1st until August 30th, make sure we never actually use the application, then on August 31st morning ask our friends to test it, and on the afternoon, fix all the bugs.

Anyway, this wasn’t a hill I was prepared to die on, and what was right or wrong here in terms of the actual wording is almost besides the point. It was more about the nature of the interaction. Bumpy start.

Questioning

The topic of the discussion below is almost comically minor, but it’s also pretty much irrelevant. Again, regardless of who was right or wrong, what I find interesting here is that 1) despite Mehari’s mild attempts to assert his continued disagreement (note his “thinking” emoji after Basil’s “magic URL” remark) and very slightly passive-aggressive “if it bothers you” and “Well. It’s closed :-) “, Basil seemed less keen on finding a common ground than on obtaining compliance (shall I say “obedience”?), and 2) despite having the only two other members of the team disagree with him, Basil showed no sign of questioning his position or trying to understand ours.

The Answer’s No

In a video meeting with Basil, Mehari, the team’s designers Louise and Alexandra, and myself, Basil was getting increasingly annoyed because I disagreed with him on a particular point, and because I was trying to let the designers be tie-breakers. Towards the end of the meeting, I asked Louise a question. Before I could finish asking it, Basil cut me off and said “The answer’s no.” I had an urge to reply sarcastically “thank you, Louise”, but I managed to control myself.

Let’s Discuss Until You Agree I’m Right

After a couple of weeks of this, I was already on the verge of quitting. I think Basil may have realized something, because he set up a one-on-one video call with me for the first time. To his credit, he tried to defuse some of the tension. I also tried to be conciliatory, seeing the good side of his trying to control everything as a love for a job well done. But in that discussion as well as subsequent ones, I noticed that as soon as I showed my willingness to go along even though I disagreed (because after all I was the newest team member and should adapt to the team’s views), Basil would say “right on” and the discussion would stop abruptly. I came to realize that these weren’t so much “discussions” but rather “let’s chat until you admit you are wrong and I am right”.

Oh actually…

In the following discussion, I made a drive-by suggestion. Again, note my trying not to be too assertive, and contrast with Basil’s peremptory tone.

Immediate reaction: nope, I’m right you’re wrong. After a while: oh, actually… Kudos for the willingness to eventually consider the suggestion seriously, which I believe should be the standard, good-faith approach.

Because?

Sometimes Basil wouldn’t even try to pretend like he was willing to discuss.

(We hadn’t mentioned this matter before.)

The king hath spoken. Reasons, rationales, explanations? Those are for weaklings.

Hierarchy

I remember distinctly that one instance of Basil’s attitude and what seemed to me like arguments of authority prompted me to seek the company’s org chart for the first time. DUKUMU was proud of its very flat structure (on paper, my direct supervisor was the CEO), so I had implicitly assumed that there wasn’t any obvious hierarchy within the engineering team. Then I noticed that Basil had the word “lead” on the org chart. “We’re flat, but I’m still the boss.”

Fixing things?

Why not bring up the problem and discuss, rather than weaseling out by quitting after one month? The answer is a combination of:

Summary of reason #1

Have I been overreacting? Probably. But what is a relationship made of, if not the sum of those daily, almost mundane interactions? If they are minorly but consistently toxic, it makes one’s daily life miserable and quickly obliterates the joy of working on an interesting project. Ironically, I had stated several times during the interviews (and I know the message was received because it was then repeated to me as a good thing) that at this point in my career, the people I worked with were more important to me than the project I worked on.

Am I the baddy? Please disagree with me. This blog doesn’t have comments, but please send me an email (address in my resume, ‘about’ page).

When I sent my resignation letter and was asked what my reasons were, my reason #1 was “I have found [Basil] to be very hard to work with. And if I say this, I am guessing he probably hasn’t enjoyed working with me either, so I am not sure I am able to bring value to the team as it is. I can provide more detail or examples if necessary. In a large company, I would likely try to switch to another team — not practical in this case.”

Reason #4: Infantilization

(Yes, I know these are out of order. Sorry. More below.)

As I wrote in my resignation explanation: “This is probably attributable to differences in company/country cultures, but I have found that employees tend to be more infantilized than I am used to. Again — matter of perspective, and happy to provide examples.”

Some specific examples:

Lastly, I find it mildly amusing that immediately after asking why I thought the company infantilized its employees in my resignation explanation, it was deemed necessary for me to move out of the project because I may throw a tantrum and sabotage it, and to stop interacting with the rest of the team because I may have a bad influence on them.

Reason #2: Horizontal, vertical, and over-engineering

The day I started and looked into how to run BYOLD locally so I could start contributing, I realized how over-engineered it was, and not just because it took me a couple of full days to actually get it running. Let me start by listing all the technologies on top of which it was built:

“Postgresql” for storing the data. “Prisma” as an abstraction layer on top on that. “pnpm” package manager. Four different binaries (a conversion service, a backend, a user-facing web app, a partner-facing web app). “turborepo” for managing all these within the same repository. “Node JS” for all the servers. “Nginx” used as a reverse proxy for local hostname management. “Typescript” which gets compiled down to JavaScript. “Firebase” / OAuth from Google for authentication. “GraphQL” for client-server communication. “Vue JS” for the frontend. “urql” for interfacing GraphQL and Vue. “Prime Vue” for some UI components. “Intlify” for internationalisation. “Tailwind” for the styling. Multiple other small libraries providing “composables”. “Nuxt JS” and on top of that, a bunch of custom-made UI components, half of which weren’t actually used anywhere yet.

Looking at this, of course the optimistic view would be: reuse, don’t reinvent the wheel, this looks great (except perhaps for all the components that were developed in-house before there was a need for them). Each of these technologies was a perfectly reasonable choice for the specific problem it was solving.

The problem was that despite the robust architecture, the application was still in its early stages and had very limited functionality. The user-facing web app wasn’t much more than a blank slate: four pages made of mostly placeholders and a navigation bar between them. It was nicely responsive to screen size though. But it didn’t have much to show. And even when it did, the various pieces didn’t really work well together. Custom tooltips would often appear off-screen. The feature supposed to speed up development by instantly making changes reflected in the running application didn’t work most of the time. Parts of the fancy dynamic styling wouldn’t load until after waiting half a minute. The theming code had several layers of indirection with a good hundred CSS variables even though the app was planned to launch with two, and then one, theme.

The payment system was ready for all countries. The developers had done a very thorough survey of all the world’s currencies and how they mapped to countries, concluding that places like Namibia, Venezuela, and Palestine, were edge cases. Would the application ever have users in Namibia? Probably not.

Was this good engineering? Definitely. Was it a clever use of engineering resources? In my opinion, absolutely not.

The whole project was a repository of textbook “YAGNI” examples (“you ain’t gonna need it”).

Of course xkcd has long had a comic for this:

Moreover, because pieces of the app had been built independently (among other “historical” reasons), there was a fair amount of duplication in the UI code, as well as competing/confusing pieces in the shared database schema. When I suggested some fixes, they were deemed great in principle, but too much effort in the roadmap. So not only did the team go generally against what I thought were widely accepted practices (build a “minimum viable” application and iterate, favor small changes, etc.), but it was actively getting me used to what I consider bad practices.

The main disagreement here may be about building vertically versus building horizontally. In my experience, it is smarter to start simple, and iterate. Build a “minimum viable” application, after having laid out the foundations to support it. Start with a good, solid, simple core experience. Make it work end to end and start testing it with your team, company, friends, selected testers. If you make a video game, start with just “wireframes”, make just a couple of levels to iterate on and see if it’s fun to play: if it isn’t, the time spent making the character pixel-perfect is wasted. That’s what I would call building “vertically”.

In contrast, it felt like the BYOLD team, in trying to build a house, laid out enough foundations for a megalopolis, but with just a bike shed on top of it. That’s what I would call building “horizontally”. Of course, this is fine if you know in advance that your end goal is indeed a megalopolis, that you have unlimited funding, already have all the plans, and that those will not change during development. In that case, it doesn’t really matter in what order you build things (though I would still argue that building things vertically will allow for more efficient resource management and testing/dogfooding flow). But 1) if you are a small company, you don’t know that you’ll have enough success and resources to reach the megalopolis goal, and 2) plans that don’t change? Has anyone ever seen that? The “final” mock-ups for the UI pieces I was trying to build changed several times in pretty major ways during my one-month tenure, and that’s how it should be! Designers need to be able to iterate depending on how the real UI (not static mocks) feels.

Here is a very symptomatic instance of this horizontal vs vertical disagreement. At one point I was building the “user settings” page. A page where users of the app would change their name, avatar, preferences, etc. There was a mock-up showing all the input fields and their arrangement. Even though it was marked as “final”, it was obviously not quite final because it included many things that we agreed wouldn’t be part of the initial version. It was also a static image, while the page needed to have more complex interactions, including validating the inputs locally and/or with the server, problems nicely communicated to the user, etc., none of which appeared in the mock. In my usual “start simple and iterate” approach, I started with a proposal with just one field for the user’s name. The idea was that we would use this as a “trail blazer”, iterate on the way data was entered, validated, saved, etc., and use it as an example for incrementally building the rest of the page. Vertical. Basil didn’t like my approach and thought (“respectfully” — when Basil starts a sentence with “Please” or “Respectfully”, brace yourself) that I was wasting the team’s time because it looked nothing like the (“final”) mock-up — which of course it wasn’t meant to.

So, my resignation reason #2 was “I don’t know much about the history of BYOLD, but from what I saw I think the application is very bloated and over-engineered in comparison to what it can actually do right now (which leads to low eng velocity), and I think the general approach to build it is not right (my opinion — obviously). At this point I do not feel like it’s my place to suggest deep changes in the app or in the process. I have no desire to prove I am right and I am often wrong, but I do want to try and bring something to the team, and at least have a general expectation that these attempts would be welcomed with an open mind. This may very well be my fault for not having been able to build enough trust yet.”

Reason #3: Hiring Profile

“The team has been specifically hiring for senior engineers, but I am questioning whether this is really what the eng team wants at this stage. I think they may want someone who is an efficient executant able to do things the team wants, exactly the way the team wants them done. If this were the sole problem, I would be happy to try my best and adapt as necessary.”

By “the team” I really meant “Basil”. As a side note after those 4 “reasons”, I said all the things that I liked about DUKUMU, and I mentioned that I believed BYOLD needed someone playing the role of a product manager.

Flange

During my own interview process, and when I was being trained on interviewing candidates, I was a little surprised at how lengthy and selective the hiring process was, which helped explain that DUKUMU was having a hard time hiring people. I think the CEO took a well-known company, Flange, as a model — both for the flat hierarchy and for the hiring practices. While I share his admiration for that company’s model, I think it overamplifies the “buy” side of the hiring transaction, and discounts the “sell” side. If you’re Google, you can afford to make candidates go through lengthy obstacle courses. But you’re not Google, you’re DUKUMU. At least not yet?

Coda

My first day was June 13th, 2024. I sent my resignation letter on July 19th. Since the agreement mentioned a 1-month notice, I said my last day would be August 19th. But then (see above) the CEO started sending some indirect signals (I never actually had a one-on-one meeting with him) that he was hesitating to keep me on the BYOLD project. In addition, I had a one-week vacation planned between July 29th and August 2nd (that had been planned and agreed upon during my interviews, family obligations). So I started feeling a little guilty about taking a one-week vacation over a total of ~2 months tenure.

Trying to play nice, on July 22nd (Monday), I offered them 3 options and made it clear that I had no intention of being paid for a month doing nothing:

The CEO replied by advancing my last day to July 23rd (the next day). Legal, given the contract and then my proposal? I have no idea. But at the end of the day, while my early resignation was certainly inconvenient for the company, it was well within the letter and the spirit of the contract’s idea of a probation period (which goes both ways), and I think it the company’s last move was not super cool. Oh well. Regardless, I am hoping I can soon see an awesome BYOLD launch as a user myself, and I send love and good vibes to everyone at the Japanese and American offices, especially to 小湖さん who hired me and was a pleasure to work with. ❤️