ETC_遠通電收股份有限公司
Pros

There are office desks

Cons

TL;DL Software engineers, don't come here. You won't learn a thing, and when putting out fires, you'll be treated as the source of the problem.

The pay is low, yet you still have to take on call duty and may even have to travel. I strongly recommend avoiding all departments related to overseas business.

The computers are terrible. Even a fresh Windows 10 installation will crash the IDE repeatedly because there isn't enough memory.

Every horror story you've heard online exists here—none are missing.

Even people who don't know how to use an IDE can come here; all you need to know is how to turn on a computer.

Projects are transferred via USB/OneDrive. There is no version control, or every file—including built binaries—is checked into version control. Every one of these horror stories exists here.

Most projects are ancient legacy systems.

Whether a project can be updated or whether a configuration error can be fixed is unclear; there is supposedly a team, but no one knows whether work can even begin.

How bad is the code?

1. Catching an Exception with try-catch and then using goto to go back and redo it—this kind of operation that creates a program deadlock by design is something I've seen for the first time in my life.

2. Even where deep copies aren't needed, things are serialized and then deserialized in the same sequence, and serialization and deserialization are performed using different APIs.

If you still don't find the two points above outrageous enough, welcome to come put out fires. It's all stuff written by predecessors who themselves had no idea what they were writing.

Even a night-school, diploma-mill vocational high school student using AI vibe coding couldn't write code of this caliber.

Most projects use distributed-system architectures, making it difficult to debug communication between projects through breakpoints. But the loggers written by those who came before are completely useless: how are you supposed to find the root cause of a problem when they throw a custom message without a stack trace?

Because this place worships "mediumship"—every day, the mediums "greet" one another by obediently asking whether they've done it yet.

The source code you receive is already corrupted garbage. The logic is very simple, yet it can't even be built. So what exactly is running in the production environment?

When something goes wrong after deployment, the blame goes directly to the developers; when you put out the fire, you're treated as the problem-maker.

The managers' decision-making is also bizarre. They say they want to optimize the database. Propose normalization, flattening and creating relational tables, or hash compression—none of that is acceptable; instead, they insist on destroying the original data-storage format.

No normally educated computer science graduate would handle it this way.

The processes are extremely chaotic. A user may suddenly rush over and demand an update on the project's progress, even though before that there was no requirements meeting and no requirements document in sight.

The handover principle here is simply that seeing the code repository counts as a completed handover. Even asking the person handing over the work for a development specification is extremely difficult.

Code quality, Clean Code, and SOLID principles, as well as software engineering concepts such as DDD and N-tier architecture, are all completely absent here. This is a place that discriminates against software expertise.

You can't debug through mediumship? Are you a Junior who can't do anything?

Reply
1
Agree
3
Disagree
0
Show all 1 replies