Remote IT Concierge Startup Weekly (7) - Order Explosion

Hi, I’m Xianmin, your Remote IT Concierge, and this is my startup weekly journal.

Week 7 Startup Actions

This week exploded with orders.
Starting from Monday, I’ve been busy non-stop, working overtime every evening.
As of Sunday night at 10:30, I still have two orders incomplete.

Even with the explosion of orders, income remains limited because the hourly rate is fixed, and the working hours per day are also fixed.
My current pricing method is to assess the workload based on the client’s requirements, estimate the time needed, and multiply by my hourly rate.
My hourly rate has gradually adjusted to the current 80 per hour after conversations with multiple clients.
The quoted hourly rate is not the actual hourly rate, as initial communications and subsequent maintenance are not calculated in the time.
So my actual hourly rate is probably around 50.
This income is quite average, I would say - won’t starve, but won’t get rich either.
Compared to regular employment, it’s a bit more flexible, but ultimately I’m still selling my time, and when it gets busy, there’s not much freedom to speak of.

This week, I took on a variety of jobs.

I. Consulting

I posted an advertisement last week, and someone actually wanted to chat with me, haha!
I was quite busy that day, so we only talked for an hour, mainly about personal emotional matters.
Although I’m not a relationship expert, my price is low, and being a fellow programmer, I can perhaps empathize better.
I shared my theory of first-hand experience and second-hand experience with him, which essentially means going on more dates with girls to gain first-hand experience.
My consulting service is priced low, mainly because I want to gain more first-hand experience in this area while also making new friends.

II. Teaching

This is somewhat of a regular client.
The first time I helped him solve dependency issues in his development environment, I discovered he was using AI for programming but didn’t understand code or project management, so the code written by AI was a mess, difficult to maintain, and even AI itself couldn’t improve it.
I advised him to simply restart with a new project, and I demonstrated to him the best practices for modern AI programming.
For example, how to use Git for version control, techniques for coding with AI, how to break down code, and how to solve bugs, etc.
There were a few near misses, but the AI managed to save the situation.

III. Project Internationalization

This was secondary development based on a medium-sized open-source project.
The original project was only in English, and with a large codebase and numerous text elements, it was a time-consuming task though not technically difficult.

Small businesses with limited staff can’t handle all the work, but hiring more people increases costs. Hiring me is a perfect fit—I can immediately start working, establish a temporary collaboration, and leave when the job is done. Solving big problems with minimal cost.

IV. Docker Deployment

Remotely helping a client set up an entire application.
Although Docker is already quite convenient, in reality, it’s still a troublesome thing for non-developers.

V. Linux Server Application Deployment

Another service for a regular client.
His application was running normally on the local machine but had errors on the server.

The main task here was debugging to find the cause of the error.
Without specific error messages, even AI would struggle.
I located the faulty file, had AI write a test for it, which ran fine locally but helped pinpoint the error location on the server.
After that, having AI fix it was simple.

VI. ECharts Visualization

The client mentioned that someone had worked on it for 2 days before giving up.
If it were me, I would have abandoned it much earlier if there was no progress after half a day…

Why was it difficult? In the end, I discovered that the data provided by the backend was problematic.
If the data is flawed, the generated charts will always be incorrect.

How did I discover this? First, I used simulated data to create a correct chart, at least proving that the chart could be generated normally.
Then I examined the data from the backend and how it was processed, using console.log to print it out.

VII. Why Do I Seem to Know a Bit of Everything?

To sum it up, I’m a programmer trained through the school of hard knocks and real-world experience—broad in technical knowledge but not deep in any particular area.

To this day, I don’t know if this is good or bad.
In my early years, I studied C language, learned about assembly, and wanted to delve into the Linux system’s underlying layers, but never had practical opportunities.
I started with Python, then entered the frontend world because of market demand.

Later, I faced reality: life is short, and whether it’s a black cat or a white cat, a cat that catches mice is a good cat…

Conclusion

Should programmers choose technical depth or technical breadth?

如果你在生活中，遇到任何计算机相关的技术问题，欢迎扫描下方二维码，免费咨询。