天空вℓσи∂ @skyblond@qoto.org

Every time I update my Android project, I have to pick up what I forgot. Google is every helpful.

Until I finished all my tasks. About to build the release APK. Then I realized that I forgot the password of my signing keystore.

Everytime. Literally everytime. I spend a lot of time trying to remember the password. Then forget it again.

@boxcars Here is a detailed version of why I made that decision. Currently I don't have next offer available, so I'm being unemployed again. I'm starting to get used to that😂

So today is the day I should sign the contract. I had a short chat with my boss, who interviewed me and who charged the tech thing in the company.

As I struggled in the past week to decide it's whether my problem (being too picky) or it's a toxic managed company. Yesterday I got a conclusion that with the current bad code base, it the boss wants to set up a rule to try to improve that situation, I will keep working there. Here are some examples of that bad code base. The first one is the database design for a USER entity. Say a user can have a passport, and you want to know if the user has one, instead of query the `passport_id` is null or not, they designed a new field called `has_passport`, updated along with the `passport_id`. This is not a rare issue, I encountered multiple times since my first task is to prepare for a database migration. Another example is the backend code, with the help from IDE, it's not that bad, I can handle it. But to make the code worse, they use Chinese Pinyin for namings. For example, what is `paramsCi`? It's a map, containing SQL parameters for query the secondary thing, which is "次要" in Chinese, pronounced like "tsu yao", we write "CiYao" as Pinyin. And there are things like "GCS", which is the first letter abbreviation in the pinyin of engineer (GongChengShi). It's not a bad code in terms of logic, but it is bad in readability. The frontend is not my major field, but I think it would be better to separate the layout rendering and data process. They do layout rendering along with processing data. For example, you get a json from the server, once you processed certain field, you render a form. Later if someone needs to add more logic to this process, it would be a nightmare since the same layout is rendered multiple times in different if-else branches. (6 times, that frontend form is another main reason that pushes me to quit)

So under this situation, even if it's my problem to be picky, I think it's a long-term suffering if it can't make it better.

However, before I asked the boss about this issue, he told me that he wants me to take charge of the frontend as well. My title during the interview is "Backend Developer", and I agree to such a low salary because I think it's fair if I work healthily, meaning no overwork, no hurry in working. I said my idea to the boss and we both agreed.

Now he told me I'm going to take charge of the frontend without a salary rise? Well, let's take the example of McDonalds' big mac. With my current monthly salary, I can buy 189.5 of big mac. So I guess you now have a general idea of what I got in where I'm living.

I asked first about the code base. The boss said the clients are always in a hurry and they have no time to step back and tidy things up. It's a pretty big red flag to me. When I work at DiDi (UBer sold their Chinese business to this company), the tasks are coming non-stoppable, but my leader always told me to take your time to design before writing code. At that time, the code base is already start to corrupt. I mean, there is a core functional method that has more than 1500 lines of golang. Nobody wants to change it, and it's too time-consuming to change it and it's risky. But at least they know it's bad and keep their best to not add more bad code.

So... No code improvement procedures. No salary rise. But additional work load and pressure to work overtime.

I decided, fuck ya, I quit.

@boxcars Thanks. Now I'm heading home and later I'll report what happened and what finally made me decide to quit the job.

Update: I quit my job. Now packing up my things.

By "following the right thing", I mean, with current bad code base, with limited delivery time from clients, at least set up a basic rules on how to write normal code. Just stop copy and paste the code when you need it, instead extract it into a method or function. Try think a little bit before writing, try to considering the future.

Today when I saw a spring controller imported both the service and it's implementation class, I was shocked.

Someone think the service is not exposing enough details to do the task, so instead of designing new functions, he just autowired the impl class and skipped the service interface.

These days I have been reading a lot. Mainly about whether I want to leave this company. This is not a happy job to me, sometimes I even feel pain when dealing the code, where the same code piece being copied over and over again, and spring's autowire give them the opertunity to invoke anything at anywhere.

The conclusion I got is: bad practise can always have excuses, and good practise is always a right thing to follow. If the company keep saying things like "clients are important" to deliberately avoid following the right thing, I think I'd just leave no matter what.

As always, I want to learn different views, so any comments are welcome, feel free to judge me.

Getting home is now more like a sport to me.

Every day since working, I'm actively trying my best to get home as soon as possible.

In general, the map said I need precisely an hour to get home. But today, I only used 57 minutes. And it's not a fluke.

With what I got: no bike (too cold), public transportation only, with some luck, if there is a sharing bike, I can shorten the walking time by 5 minutes, and with carefully calculated the time and try not late, I can catch the first available subway after 1730, wasting no time on waiting.

That's the daily sports to keep me healthy