How to Turn New Graduates into Technical Experts: 5 Practical Steps

Redefining the Expert

An expert is defined as someone with broad knowledge or ability in a specific research or professional field; even a seasoned 996 programmer can be considered an expert under this simple definition.

An expert builds a categorized conceptual space in their domain and can flexibly enrich it through analogies.

In software development, a technical expert possesses a rich knowledge system of concepts such as Spring Boot, microservices, distributed architecture, design patterns, and continuous integration/deployment pipelines.

Spring Boot is a framework for building microservices . Microservices are a style of distributed architecture; the most common architectural pattern is the design pattern . Distributed architecture connects multiple deployment units via remote protocols. Applications built with Spring Boot can be a deployment unit and are built through continuous integration , then continuously deployed to a container platform .

Knowing the whole system of concepts and their relationships makes one an entry‑level “expert”. When new concepts appear—e.g., the recently revived Cells‑based architecture—experts must incorporate them into their mental framework.

1. Finding Continuous Growth Motivation

The first question is why become a technical expert. Sustained motivation drives persistent behavior and desire until the goal is achieved. The author references the CHAMPFROGS model (Curiosity, Honor, Acceptance, Mastery, Power, Freedom, Affinity, Order, Goal, Status) to help identify personal motivators.

“Regardless of the level of motivation, maintaining it enables continued pursuit of the goal and psychological desire until the goal is perceived as achieved.” – Wikipedia

Chasing higher income is discouraged because compensation is often industry‑driven rather than skill‑driven; focusing solely on money can erode intrinsic growth motivation.

2. Building Clean Coding Habits

Clean code issues listed include useless comments, commented‑out code, chaotic style, lack of design/refactoring, missing automated tests, overuse of println/console.log, and not leveraging IDE shortcuts or snippets.

Useless comments

Commented‑out code

Chaotic coding style

Lack of design or refactoring

Missing automated tests (relying on println/console.log)

Not using productivity tools (IDE shortcuts, snippets, Emmet, etc.)

…

New programmers are advised to adopt a modern IDE; the investment in tooling pays off through increased productivity.

3. Establishing Problem‑Location Methods

Effective problem location involves mastering Google search, using GitHub for code examples, and reading official documentation. Common novice mistakes include ignoring obvious error messages, only looking at final results, and failing to search error texts.

Ignore obvious error information (e.g., the word “error”).

Only look at the final outcome or take screenshots.

Do not consult official documentation.

Do not know how to search documentation.

Ignore searching error messages, which is the most effective method.

Do not use proper technical keywords (e.g., “Spring Boot JPA Query”).

Unaware that GitHub issues can be searched.

Additional techniques such as code review, rollback, and automated tests can aid in pinpointing issues.

4. Learning Existing Patterns and Best Practices

Most problems faced by beginners are known and searchable. The author recommends buying books or consulting curated reading lists (e.g., a Douban list) to quickly familiarize oneself with established patterns and best practices.

5. Frequent Self‑Summaries

Daily or weekly reports should focus on technical insights rather than mere status updates. Summaries can include how to apply a framework, step‑by‑step adoption, and analysis of underlying principles.

Other: The Curse of Knowledge

When experts are too familiar with a concept, they struggle to explain it to novices, leading to repeated clarification. The author illustrates this with a Git example: explaining a multi‑megabyte commit is easier by simply checking the size with .git directory rather than delving into blobs and indexes.