Tag: programming

Clear Thinking > Fast Typing

I came across this “relic” today – my old IBM Flowcharting Ruler.

In the “good old days,” before typing a single line of code onto a punch card, we had to be incredibly intentional. Computer time was expensive and punch cards weren’t free. We used these rulers to meticulously map out program logic, followed by hours of “desktop debugging” before the hardware ever saw our work.

Fast forward to 2026, and the game has changed. We are in the age of Chat-to-Code. With a simple Product Requirements Document (PRD) or a solid implementation plan, AI can generate entire application with hundreds line of code in seconds.

But here is the reality: The tool has changed, but the “Golden Rule” hasn’t.

Clear Thinking > Fast Typing

Just because we can generate code instantly doesn’t mean we should do it blindly. In the age of AI, your clear thinking is still your most valuable asset.

➡️ Garbage In, Garbage Out: If your requirements or logic is fuzzy, your AI-generated code will be a hallucinated mess.

➡️ Architectural Integrity: AI is great at writing functions; humans are still the masters of designing systems.

➡️ Efficiency: A well-structured prompt born from a clear plan saves hours of “prompt-tweaking” and debugging later.

The Lesson from the Ruler

Back then, we planned to save punch cards. Today, we plan to save technical debt and architectural drift.

Whether you’re using a plastic stencil from the 70s / 80s or the latest LLM, the secret to great software remains the same: Understand the requirements and logic before you touch the keys.

How much time do you spend “ruling out” your logic before you ask AI to build?

#SoftwareEngineering #GenerativeAI #Flowchart #Programming

Obsession

Couple of days ago, there was a blog post about how Gmail team improved the loading sequence, trimmed the 24 http requests down to just 4 requests. A few utilities and tips were covered in the post, but I think the key messages they sent across were “the need for speed” and “the obsession of great performance”.

In the good old days, we measured the greatness of a program by how fast it could run, how small the runtime file was and how smart the logic we coded. It’s the obsession of great programming, you know. Compare this to the generation of developers we have now, the first question they usually ask about a new task of programming is “where can I copy it ?”. What a difference ?!

I can understand the merit of DRY (Don’t repeat yourself), but really, there is no shortcut to be a great developer. The only way is – obsess to your work !!