Boost Your Tech Skills with Cognition and Human Nature

Yesterday while browsing Juejin I came across an article that resonated with me on technology selection, troubleshooting, technical interviews, online incidents, code reuse, and open‑source perception, so I decided to share it here.

Using cognition and human nature to raise your technical level

I recently gave a team talk titled “Using Cognition and Human Nature to Improve Your Technical Skills.” The response was positive, so I’m整理 (organizing) the content for a wider audience. The core idea is that excellent product‑manager thinking and excellent programmer thinking share the same underlying cognition and human nature.

Two key concepts

Understanding human nature helps elevate cognition.

“Narrow” technology (Java, PHP, Android, Spring, Vue, etc.) are merely tools that aid cognition; they are not cognition itself.

Below are concrete examples that illustrate these ideas.

Example 1 – Technology Selection

Problem: Flutter is gaining popularity as a cross‑platform mobile framework. How can a mobile developer evaluate it without being misled?

Cognition: Flutter boosts cross‑platform productivity and offers better performance than many front‑end frameworks.

Explanation: Cognition means extracting a seemingly ordinary statement that, after deep thought, reveals real value. Before Flutter, I mistakenly believed front‑end frameworks like React or Vue would replace native clients. By analyzing our user base and growth stage, I concluded that improving cross‑platform efficiency without sacrificing performance was more important than rapid feature updates. This insight led us to adopt Flutter despite its immaturity.

Human nature: Google’s parallel development of Kotlin and Flutter reflects internal competition—different departments trying to outdo each other. Remember that corporate decisions are driven by human motives, not pure technical logic.

Example 2 – Debugging Online Issues

Problem: Investigating production incidents feels painful, stressful, and slow.

Cognition: 1) Debugging is the cheapest way to train logical thinking; 2) Focus on the root cause and capture the “first scene of the incident.”

Explanation: Many developers dread production bugs because they force overtime and interrupt learning. However, debugging forces you to think clearly, trace the exact failure path, and understand system internals—far more efficient for sharpening reasoning than writing routine code. For static languages like Java, the true “first scene” may be the initial failure or server startup, not the latest request. For a MySQL deadlock, examine the bin‑log rather than the application log. Missing the first scene accounts for 99% of unresolved incidents.

Human nature: People prefer low‑effort tasks and may undervalue debugging, seeing it as “low‑status.” Recognize this bias and treat debugging as a valuable learning opportunity.

Example 3 – Technical Interviews

Problem: Even experienced engineers often fail to assess candidates accurately.

Cognition: The key interview metric is a candidate’s ability to solve problems independently; technical depth mainly influences salary.

Explanation: Interviewers should ask candidates to describe a high‑impact project and probe deeply until the candidate’s independent problem‑solving ability is evident. Relying on a checklist of technical questions leads to hiring “knowledge‑only” engineers who cannot handle real issues.

Human nature: Candidates may hide laziness, face‑saving, over‑confidence, or self‑doubt, which affect their performance.

Example 4 – Severe Production Outages

Problem: What causes critical production failures—individual skill gaps or process flaws?

Cognition: Individual mistakes rarely cause major outages; collective cognitive errors do.

Explanation: In micro‑service architectures, a missing configuration (e.g., a critical DB parameter) can cascade because developers treat configuration as “non‑code” and therefore less important. When the whole team shares this mistaken belief, the outage becomes inevitable. Preventing collective cognitive bias is essential.

Human nature: Blind confidence, herd behavior, and laziness lead teams to accept unsafe shortcuts.

Example 5 – Code Reuse

Problem: Opinions differ on when to abstract common code.

Cognition: Reuse capabilities, not business logic; “separate long‑term capabilities from short‑term features.”

Explanation: Capabilities are stable, reusable functions (e.g., a payment SDK). Business‑specific features (e.g., login vs. registration UI) should not be forced into shared modules because they increase risk.

Human nature: Rigid rules cannot handle complex, changing environments; flexibility is required.

Example 6 – Open‑Source Motivation

Problem: Why are Chinese internet companies emphasizing open‑source now?

Cognition: Open‑source directly impacts cost, talent pool, and market positioning.

Explanation: Contributing open‑source projects builds brand reputation, attracts top graduates, and creates downstream revenue opportunities (e.g., users adopting your cloud platform after using your open‑source queue).

Human nature: Open‑source contributors seek reputation and profit; adopters seek cheap, reliable solutions and prestige.

Key Takeaways – How to Elevate Cognition

Keep a Simple Heart

People with a simple, pure mindset achieve higher levels faster. Simplicity means focusing on core goals rather than peripheral concerns.

Leverage Cross‑Disciplinary Power

Innovation often arises from combining domains (e.g., iPod + phone = iPhone). Diverse interests enrich technical insight.

Follow Guidance from Higher‑Cognition Individuals

Leaders and architects usually possess higher cognition; trust their advice to accelerate your growth.

Practice Relentlessly

Only real, high‑pressure projects (not idle demos) can truly upgrade cognition. Align practice with business goals to create meaningful challenges.

In summary, today’s competitive edge lies in the height of one’s cognition rather than sheer knowledge. Programming languages, frameworks, and tools are merely vehicles for training cognition. Strive to be “both a programmer and not a programmer” by continuously expanding your mental model.