10x engineers Technology Radar Over the past few months, the term “10x engineer” has drawn intense attention. A widely shared Twitter thread essentially suggested that companies should forgive antisocial and destructive behavior in order to retain engineers believed to have massive individual output. Fortunately, many people on social media mocked the idea, but the stereotype of the “rockstar developer” remains widespread. In our experience, great engineers emerge not from individual output but from collaborating within great teams. Building a team that mixes different experiences and backgrounds yet is full of talented members, and providing strong support for teamwork, learning, and continuous improvement, is a far more effective approach. These 10x teams move faster and are more resilient—without tolerating bad behavior.
Overview
Essential Complexity Essential Complexity
Accidental Complexity Accident Complexity
Choose the right way of doing things to reduce the workload caused by accidental complexity; Principles
- Begin with the end in mind
- Task decomposition
- Communication and feedback
- Automation
Thinking Framework
- Where are we ?
- Where are we going ?
- How can we get there ?
Begin with the End in Mind
How do we make sure our effort isn’t wasted?
Everything is created twice: first in the mind, an intellectual creation, and only then in practice, the actual construction.
For those of us who build software, we should define the “end” as building software that is valuable to users. Only by bringing value to others can our own value be realized.
tips: Design a project or example that begins with the end in mind
The Value of DoD
Definition of Done
User Story
Use scenario walkthroughs to refine requirements
- Theme
- Overview
- Details
- Acceptance criteria
In acceptance criteria, the most important part is the description of exception flows, similar to validating exception logic in test cases.
Continuous Integration
What R&D needs to deliver is not a pile of code files, but runnable software or systems. Although we all write code and develop in the same era, at the level of technical practice, different teams seem to live in entirely different ages
Lean Startup
Most people in the IT industry are not professional enough. We must think independently, ask “why” a few more times, and minimize the number of times we fall into a pit before calling for help.
Lean Startup: creating new things in the face of uncertainty. What Lean Startup gives us is a framework for thinking about products, and most products we encounter can be examined within this framework.
The build—measure—learn loop
By default, don’t build any requirement until you figure out why it should be done.
Inside and Outside the Pit
Differences between roles: the real difference between roles at work lies in context. When writing the same code, some people see the trees while others see the forest and can think globally.
When all you have is a hammer, everything looks like a nail.
Spending enormous effort solving a problem that may not actually be a problem is a common blind spot for many programmers.
Deduction
The last mile: if we want to reach the goal, what must we do at the very end?
- Start from the outcome and see what factors the final launch needs to consider
- Deduce a step-by-step executable plan, using the factors considered earlier as the yardstick
- Summarize the tasks to be done based on the deduced plan Begin with the end in mind, but the path to the result matters even more.
Quantification
Insight: it depends on a person’s long-term accumulation in a field—in a sense, it is a form of big data.
Planning&Prepare
Design your own Iteration 0 checklist
Task Decomposition
How many civilizations similar to ours are there in the Milky Way? The Drake equation: N= R* x Fp x Ne x f1 x fi x l
Elon Musk’s Mars exploration plan: send a person from Earth to Mars at one-millionth of the cost.
Testing
For every programmer, only by writing both the code and the tests well during development are you qualified to say that what you deliver is high-quality code. The ice-cream cone testing model: A time-consuming and labor-intensive testing model
- Manual regression testing
- Automated end-to-end testing
- Integration testing
- Unit testing
- UI
- Service
- Unit
The lower-level the test, the fewer things it involves, while higher-level tests cover a broader scope. Write more unit tests
TDD: Test-Driven Development
Tests drive code: an example of a static method—how to test a static method, and how to do it better under OOP thinking.
Test Driven Development
Test Driven Design
Write testable code
The Master Programmer’s Secrets
- Where did TDD come from?
- Extreme Programming Explained
- Test-Driven Development
Decompose tasks—the smaller, the better.
Task Decomposition Exercise
Requirement: a user logs in by entering a username and password.
Excellent Test Code
A journey: A-TRIP
- Automagic
- Thorough
- Repeatable
- Independent
- Professional
Cutting Requirements
Principles for evaluating user stories:
INVEST
- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable
To manage requirements well, first break them down into small pieces
How can requirement estimation be done more reasonably, with minimal error?
Recommended books
- User Stories Applied (Chinese edition)
- Aglie Estimating and Planning (Chinese edition)
Requirement Management
Requirement priority management: importance and urgency
Minimal Cost
MVP: Minimum Viable Product
Communication and Feedback
Life doesn’t go your way eight or nine times out of ten.
Communication and feedback are ways to improve encoding, decoding, and the algorithm itself.
Writing Maintainable Code
Any fool can write code that a computer can understand. Good programmers write code that humans can understand. ------Martin Fowler
Program in the language of the business
Domain-Driven Design
Recommended reading Clean Code — Robert Martin
22 Lightweight Communication: Why Are We Always in Meetings
Meetings are meant to solve problems, but the reality is that meetings solve few problems while creating the problem of too many meetings.
Meetings that work particularly well are almost always for information sync; meetings that go poorly are basically ones for discussion.
Improving meetings:
- Reduce the number of attendees
- Communicate face to face
- Stand-up meetings
Visualization: A More Direct Way to Communicate
Technology Radar: a structured way to learn new knowledge
Fast Feedback: How to Do Continuous Integration Well
- A continuous integration monitor that shows CI status in real time
- Respond to problems immediately
Retrospective
Don’t be defeated by the same trick twice The benefit of retrospectives: objectification—looking at problems from someone else’s perspective
Retrospective: replaying the process, discussing and analyzing it, and finding ways to improve yourself. This approach provides an objectified perspective, allowing you to view everything that happened more objectively.
Hold retrospectives regularly, pinpoint the root causes of problems, and keep improving.
Listen to the Voice of the User
Whoever is closest to the user has the right to speak, whatever your role
Spend more time with users
A product manager is the mouthpiece of user needs
Fail Fast
If there is a problem, expose it as early as possible.
The earlier a problem is exposed, the lower the cost of fixing it.
Structured Learning: Be Good at Writing Documentation
There are many ways to structure scattered knowledge, and output is a critical part of it.
How to write good documentation: there is no secret—practice makes perfect.
Recommended reading
The Presentation Secrets of Steve Jobs
The Nature of Laziness
Doing valuable things matters most—and “valuable” here doesn’t just mean what you do; saving time and cost by not doing things is also valuable.
Start with automating your daily work and build your own automation toolkit
The capability needed to build automation tools for others: software design
In software development, everything else is volatile; only the variability of design is under your own control.
The three virtues of a great programmer: laziness, impatience, and hubris.
Project Automation
Automate the work process.
Scattered Operations Knowledge
Systematize scattered operations knowledge—but how?
Continuous Delivery ≠ Continuous Integration
How to build a continuous delivery system
Take deployment into account during development
Acceptance Testing
BBD: Behavior Driven Development The BBD testing framework Cucumber
The key point: automate acceptance testing
Gradually Decaying Code
The best punishment for a programmer is to make him maintain the code he wrote three months ago
Software design principles: SOLID
- Single responsibility principle
- Open-closed principle
- Liskov subsitution principle
- Interface segregation principle
- Dependency inversioni principle Keep functions short
MVC Layered Design
The value of layering: building a good abstraction
How to Build a Taobao with 50,000 Yuan
Recommended book: Ten Years of Taobao Technology
Systems of different magnitudes are simply not the same system
Solve problems with simple technology until the problems become complex
Do DDD Well Before Talking About Microservices
DDD: Domain-Driven Design
Recommended books
- Patterns of Enterprise Application Architecture
- Domain-Driven Design
- Implementing Domain-Driven Design
- Domain-Driven Design Distilled
How to Maintain a System
When transforming a legacy system, one key point is: don’t go back to the old ways.
Recommended book
How to Stay Competitive
Master one specialty while developing multiple skills—become a T-shaped talent
Work and grow in the learning zone.
