Thinking Methods: The Way of Survival for Programmers

Looking back at my first decade in the IT industry, this post captures my evolution from a pure tech-geek to a design-focused developer, and finally, to someone who understands that thinking methods trump technical stacks. Here, I share my core philosophy on problem-solving, customer-centric development, and a practical "binary search" approach to troubleshooting. Note: This is a archived post migrated from my old Blog: https://blog.csdn.net/felomeng/article/details/51404776

I started transitioning into IT back in 2006, and looking back, it has been nearly ten years! Here is a small summary of the lessons and experiences I've gathered along the way.

In the first few years, I was incredibly passionate about technology itself—a true "tech geek." I believe every passionate programmer goes through this stage, constantly seeking depth, breadth, and perfection in their technical skills.

Later on, I grew fond of design. Once you accumulate a certain level of technical experience, you naturally want to make a bigger leap forward, which brings you to the design stage (though I had studied it a lot earlier, design is something that absolutely must be grounded in sufficient practical experience). I spent another few years like this.

Now, I have finally seen the light. Here is what I’ve learned:

Success in the workplace relies not only on technology but even more on politics. Everyone needs to understand a bit of it.
Technical success isn't about what technologies you know or master, but about the rigorousness of your thinking (as noted in the title).
Focus more on the user and discard tech-driven mindsets. You can only achieve true success by catering to your clients.

I made quite a few mistakes regarding points 1 and 2, and honestly, I still only have a superficial understanding of workplace politics. Today, I specifically want to share my summary of thinking methods:

Programmers encounter countless problems every day. The key to solving a problem is first finding where the real problem lies. (I highly recommend reading Are Your Lights On? when you have time; it’s very enlightening.)

For example: You’ve built a website and deployed it on a server. It runs very slowly on port 80, but it’s quite fast on any other port. Where is the problem? As a programmer, you should think of all possibilities (and it must be all of them). Since it runs fast enough on other ports, it proves the website itself isn't slow. So why is port 80 slow? There are two major possibilities: port 80 is congested, or the website configuration limits port 80. Expanding on this: another program might be heavily using port 80; a firewall might be restricting it; or the website itself might have a specific restriction on that port (though this is less likely since you built it yourself)...

Problem-solving requires a plan. You need to analyze the situation based on all possibilities, sort them by likelihood, and test them one by one. There is a trick to doing this sequentially: see if the problem can be split and solved using a binary search approach—most of the time, it can. For instance, if you know a massive code change caused a bug, which exact part is responsible? In this scenario, you can roll back half of the changes and see if the issue persists. If it does, the bug is in the remaining, un-rolled-back code; if it doesn't, it's in the code you just removed. Keep the problematic half of the code and repeat the steps above. This allows you to efficiently isolate all potential causes. This is the binary search method for troubleshooting.

Alright, that’s enough bragging for today. I hope this helps you all.