1. Government-agency style; salary is paid on the 1st of the month

2. The office is located on the NTHU campus, with convenient parking

3. Lots of university benefits

4. Low technical requirements

Many programs are assembled from beginner-level code, making them friendly to newcomers and those with less exposure to cutting-edge technologies ​

5. Backend engineers’ working hours are mostly fixed

​Outside peak periods, if I happen to write quickly enough, I have quite a lot of time to rest

​However, the Analysis Team has a pattern of regular overtime

6. The Engineering Team colleagues are all very nice

7. You can improve your communication and stress-management skills

8. There is a lot of bad code, so you can feel a sense of accomplishment from improving it every day

9. There are many areas where you can contribute, making it easy to build up achievements for your résumé

1. A little hot

Although there is air conditioning, the temperature is fairly high

If, like me, you need strong air conditioning, I would not really recommend it; you will be soaked in sweat every day

2. No overtime

It does not actually mean that people do not work overtime. If you need to work overtime, you must submit an application in advance, and only work overtime after your supervisor approves it

So even if you really did work overtime, you might only be told that you should have applied in advance

In practice, there are only two choices:

Put down the work at hand, or quietly absorb the overtime yourself

The most annoying part is that you still have to clock out on time

It is precisely because you are so absorbed in writing code that you do not want to leave your current state,

but if you have enough free time to clock out, wouldn’t it be better to just go home?

PS: At the monthly meeting,

for meetings held out of town, the meeting’s scheduled end time is the cutoff time for overtime,

and travel time for the return trip is not counted

3. No professional PM

Because there is no PM here, work may suddenly flood in, resulting in being extremely busy at some times and extremely idle at others

4. Issues with accountability

My backend supervisor and I planned and implemented an error-collection system and discovered a long-standing vulnerability

We urgently reported it to upper management and patched it

This vulnerability resulted from an oversight in the Analysis Team’s management

Because my colleague did not follow the standard operating procedure, the vulnerability was recorded under their responsibility

In the end, my colleague was blamed for not following the standard procedure

They could only look for another job

My backend supervisor was removed from their management position, and the Engineering Team was placed directly under the Analysis Team

The assignment of accountability was rather strange

5. Authoritarian management style

The current main managers are very insistent on their own opinions and do not really allow differing views

Basically, engineering staff can still get along fine as long as they do not have too many opinions

The managers are not very willing to admit their own mistakes

Their reasoning is that previous engineers caused a mess, so if they are not strict now,

the work environment will become even worse in the future

I personally also encountered a situation where a requirement said PDF generation was too slow

I switched to a new generation method, reducing the generation time to 30–40% of the original

After I had replaced half of it, the manager suddenly told me to stop switching

because the package required by the old generation method had more recent updates and more stars on GitHub......

They also told me that a part-time engineer said it was not faster. I asked them to come over personally so I could demonstrate it,

but they were unwilling to come over and look at the results directly

They insisted on returning to the original generation method

(There are also some issues with the part-time engineers, but I will not elaborate here)

6. The Analysis Team is the client, not the PM

Engineers face the Analysis Team as if they were dealing directly with a client

The Analysis Team only has some ideas about the business

but lacks concrete planning, and does not really consider existing rules and data

Nor do they consider the cost of maintaining the code

For example:

There was originally a module for controlling permissions. The current requirement is for specific pages to display different messages depending on permissions

At first, the simple implementation was to use the original module to configure the correct display permissions, with only the middleware needing to be changed to display different messages

But later, the Analysis Team insisted that they did not want to adjust the display permissions and wanted engineers to add the changes page by page

Yes, they really wanted engineers to add the messages one page at a time!!!

If you are fortunate enough to join this company, be sure to appreciate the document I left behind explaining the whole background and reasoning

7. Extremely high technical debt; it may lead newcomers astray

Many programs are assembled from beginner-level code

You will encounter a lot of logically confusing code, with if statements nested several layers deep

Methods do not follow atomicity, and naming is inconsistent

You can find basically every example of poor coding practice here

Then they put Composer packages in Git

and directly modify the packages’ source code

The frontend and backend are mixed together; every bizarre coding style imaginable is allowed—if you can think of it, it can be done

You can write a student list into a URL and send it via GET, only to cause a 414 error when there are too many students

Vue components are not separated; everything is written as one huge block

Poor UI/UX design causes problematic interaction logic and many exceptional cases

Database design is completely neglected; the database is used directly as if it were Excel

The UI here is designed using Excel, so friends who use newer tools may want to take note

8. Fixed practices and low acceptance of change

Originally, after explaining the technical aspects to the backend supervisor, change was still possible

But after the backend supervisor was demoted, making technical changes became somewhat difficult

After the UI/UX colleague joined, they expressed a desire to use newer tools

But this place insisted that they also use Excel for drawing

Moreover, because they were categorized as

and followed the Analysis Team’s training process,

they had to take on customer-service duties and memorize the relevant regulations to understand the business

Project-management tools are not considered

They insist that everyone manually organize and report their work progress for the day

9. LINE is the primary communication tool

This varies from person to person

For me, it is a drawback because it feels like my private life is being intruded upon

I feel that work should use Slack or other software instead, so work and personal life can be separated

10. This is a fixed-term contract position

Summary:

For me, this was not a suitable job

The following applies specifically to backend engineers

People with the following characteristics may be a better fit:

You have no opinions of your own, obey, and do exactly as you are told

You have your own opinions, and even if communication fails, you persist without letting it affect your mood

After work, you do not get frustrated when you are halfway through handling a problem, because you can easily let go and leave it unfinished

After work, you do not get frustrated when you are halfway through handling a problem, because you can choose to quietly work overtime

You do not get frustrated when you see lousy code, because you can contribute a little while you are at it—if something breaks, you can fix it later anyway

You do not get frustrated when you see lousy code, because you have an extraordinarily strong ability to read minds and can travel through time to understand what the author was thinking at the time

You can ignore it and do not want to change the quality of the existing code

You can ignore the managers’ belief that your progress is slow while still wanting to improve the quality of the existing code

When facing requirements that are repeatedly changed, you can adopt the attitude that the company’s time is being wasted, and you are simply being paid to do the job

When facing requirements that are repeatedly changed, you can adopt the attitude that this is your contribution and that you are incredibly strong-minded

You are already capable enough and do not need to pursue further self-improvement at work

You do not want to do any other job for the rest of your life and do not need to pursue further self-improvement at work

Your Laravel, PHP, and OOP concepts are strong enough for you to refactor the code

Your Laravel, PHP, and OOP concepts are weak enough that you do not notice anything strange