Chapter 1: Beginning the Journey

〉 My first step as a developer, what path will unfold in the future?
Let's set goals
Map for your journey
__beginner
__Storm and Stress Growth
__Trusted Contributor
__Ocean of Operations
__Land of the Able
Forward, forward!

Chapter 2: Conscious Efforts to Increase Competency

〉What you need to do to become a competitive developer
Self-directed learning methods to master before actual practice
__Warming up for serious study
__Let's learn by experiencing it firsthand
__Let's try various experiments to understand the code's behavior.
__The habit of reading documents must become second nature.
__Let's find the presentation video and watch it.
__Sometimes we also attend meetups and conferences
Experience and collaborate with senior engineers.
__You can also learn from personal project activities.
Let's ask the right question
__Let's solve the problem ourselves
__Let's set a time limit
__Share the methods you tried
__Do not disturb your colleagues
__Let's try asynchronous multicast communication
__Send synchronous requests all at once
Overcoming obstacles to growth
__mask syndrome
__Dunning-Kruger effect
Developer's Essential Checklist
Reading for Leveling Up

Chapter 3 Dancing with the Code

〉 Our approach to legacy code
Software entropy tends to increase.
Technical Debt That Can Never Be Avoided
__How to Pay Off Technical Debt
To reduce the pain caused by code changes even a little bit
__Let's use the legacy code change algorithm
__Let's keep the code cleaner than before
__Let's change it gradually
__Let's do refactoring pragmatically
Let's use __IDE
__Let's use the recommended techniques of the version control system.
To avoid the pitfalls that are easy to fall into in software development,
Let's use proven technologies as much as possible
__Please don't be a troublemaker
__Forking without upstream commits is prohibited
__Resist the urge to rewrite code
Developer's Essential Checklist
Reading for Leveling Up

Chapter 4: Writing Code Considering the Operating Environment

〉 The development environment and the production environment are clearly different.
Defensive programming strategies for handling failures
Avoid using __null values
__Let's use immutable variables
__Let's use type hints and static type checking
__Let's check the input value
Let's use exceptions
__Let's define exceptions specifically
Throw exceptions early and handle them as late as possible.
__Retry wisely
Let's make the __system idempotent
Let's release the __resource
Logging methods to find the cause of the problem
Let's use __log level
__Let's write logs atomically
__Let's record the log quickly
__Do not log sensitive data
How to Use Metrics to Measure Application Behavior
__Let's use the standard indicator library
__Let's measure everything
Tracing has become increasingly important in today's distributed environment.
To easily adjust runtime behavior with settings:
__Overly creative settings are prohibited.
__Let's log and verify all settings.
__Let's provide default values
__Let's group related settings
Let's test the __settings as well as the code.
__Keep your settings files clean
__Do not change the deployed settings
Sometimes tools can make or break an operation.
Developer's Essential Checklist
Reading for Leveling Up

Chapter 5: Managing Unavoidable Code Dependencies

The truth about dependency that you only realize after writing a complex program
Essential Concepts for Understanding Dependency Management
__Semantic versioning
__Transitive dependence
The hell of dependency that everyone in the field has experienced at least once
__Let's escape from dependency hell
Let's isolate the __dependency
__Add dependencies carefully
Let's fix the __version
__Let's narrow the scope of dependency
__Beware of circular dependencies
Developer's Essential Checklist
Reading for Leveling Up

Chapter 6: Testing! A Strong Supporter for Developers

〉 A test method that verifies system operation while reducing workload.
Do I really need to take the test?
Types and techniques of testing
Various testing tools
__Mocking library
__Test Framework
__Code Quality Assurance Tools
Let developers write their own tests
__Let's write tests neatly
__Avoid excessive testing
Test determinism: To always produce the same test results
__Let's use an appropriate seed value for the random number generator.
__You should not call remote systems from unit tests
Let's inject a __clock
__Avoid using sleep and timeout
__Close network sockets and file handles
Let's bind to port __0
__Create unique paths for files and databases
__Isolate and release the state of the previous test
__Don't rely on the order in which tests are run
Developer's Essential Checklist
Reading for Leveling Up

Chapter 7: Code Review: Giving and Receiving Correctly

〉Aiming for smooth team collaboration and high code quality
Why is code review necessary?
How to Get a Proper Code Review
__What to prepare for a code review
__Having a draft review can reduce risk
__Submitting reviews for test runs is prohibited
__When there are many code changes, it is more detailed
__Don't be too obsessed with your own code
__Be empathetic, but don't tolerate rudeness.
__Let's take the initiative
How to do a proper code review
__Let's screen review requests
__Let's make time for a review
__Understand the code changes
__Let's provide comprehensive feedback
__Let's acknowledge the good points
__Let's clearly distinguish between issues, suggestions, and minor flaws.
__Random reviews are a no-no
__Don't rely solely on web-based review tools
__Don't forget the test review too
__We have to come to a conclusion somehow
Developer's Essential Checklist
Reading for Leveling Up

Chapter 8: Delivering Software to Customers!

〉 The final destination for software that will finally settle into the production environment
The Four Stages of Software Delivery
Branching Strategies for Effective Version Control
Build steps
__Let's specify the version in the package
__Let's package each resource separately
Release phase
__Don't treat release as someone else's business
__Publish the package to the release repository
__Let's make release immutable
__Let's release often
__Let's share the release schedule transparently.
__Let's publish change logs and release notes
Distribution phase
__Let's automate distribution
__Let's perform distribution atomically
__Let's deploy the application independently
Rollout phase
__Let's monitor the rollout
Let's use the __feature flag
__Protect your code with circuit breakers
__Let's upgrade the service version in parallel
__Let's launch in dark mode
Developer's Essential Checklist
Reading for Leveling Up

Chapter 9 Emergency Response On-Call Work

〉 Procedures and measures to respond to obstacles that may occur at any time
On-call work responding to urgent emergency situations
Must-have on-call skills
__Always be ready to respond at any time
__Don't let your guard down and stay focused
__Let's prioritize our work
__Let's communicate clearly
__Track your work progress
Five Steps to Handling Disabilities
__Selection
__tuning
__mitigation
__solve
__Follow-up measures
Support work is also strictly on-call work.
Don't try to be a hero
Developer's Essential Checklist
Reading for Leveling Up

Chapter 10: Technical Design Process for Robust Software

〉 Software design and documentation techniques suitable for large-scale changes
Cone-shaped technical design procedure
To design the right technology
__Let's define the problem
__Let's investigate the solution
__Let's try various experiments
__Let's invest enough time
How to Create Design Documents for Communication
__Let's document important changes.
__Understand why you're writing a design document
__Let's learn how to write
__Keep your design documents up to date
Basic structure of a design document template
__outline
__Current status and context
__Reason to change
__Requirements
__solutions to consider
__The solution you want to adopt
__Design and Architecture
__Test Plan
__Rollout Plan
__Pending Matters
__supplement
Collaboration is important even during the design process.
Understand Team __'s design review process
__Let's not create sudden situations
Let's brainstorm and discuss the design.
__Let's participate in the design
Developer's Essential Checklist
Reading for Leveling Up

Chapter 11: Implementing an Evolving Architecture Considering the Software Lifecycle

〉 Core principles for creating growing and evolving software
Understanding Complexity
Design Principles for Evolving Architectures
__YAGNI Principle: If it's not immediately necessary, don't implement it.
__Principle of Least Impact: Don't surprise your users.
__Domain knowledge must be encapsulated
Design Principles for Evolving APIs
__Keep the API size small
__Expose a well-defined service API
__Maintain compatibility with API changes
__Let's manage the API version
Design Principles for Evolving Data
__Isolate the database
Let's use the __ schema
__Let's automate schema migration
__Maintain schema compatibility
Developer's Essential Checklist
Reading for Leveling Up

Chapter 12: Agile Culture for Effective Collaboration

〉Agile, which everyone knows but is not easy to put into practice
Agile Manifesto
Agile Methodology Framework
Agile development method using Scrum
__User Story
__task
__Story Point
__Backlog Classification
__Sprint Planning
Stand-up meetings for rapid work sharing
Reviews that require honest feedback
Retrospective for reevaluation and adjustment
Establishing a roadmap for mid- to long-term planning
Developer's Essential Checklist
Reading for Leveling Up

Chapter 13: Working with Managers, Team Leaders, and Supervisors

〉 With one mind and one purpose, towards a common goal
What managers do
Let's establish procedures for successful performance and evaluation.
__One-on-one meeting
__PPP meeting
__OKR
__Performance Evaluation
Even your team leader or superior needs your management.
If the team leader doesn't give enough feedback, ask for it actively.
Team Leader __ also wants your feedback
__Let's have an open discussion with your team leader about your goals.
__If you tried everything and it still doesn't work
Developer's Essential Checklist
Reading for Leveling Up

Chapter 14 Advice on Career Management

〉 The sooner you start managing your career, the better.
Senior Engineer, and towards higher ground
Career Advice
Become a T-shaped person
__Participate in various programs for developers
If you want to get promoted, do this
__Carefully change jobs
__Just beware of burnout
In conclusion

| What this book covers |

- What happens when you first join a company and start working?
- How to address and prevent technical debt, write and deploy software safely, and manage dependencies.
- How to keep your code cleaner than before by using a legacy code change algorithm.
- How to write code that takes the operating environment into account through logging, metrics, configuration, and defensive programming.
- How to build deterministic tests, perform code reviews, and evaluate other programmers' code
- How to review and test code with other developers and collaborate effectively with colleagues, team leaders, and superiors.
- Overall steps of the technical design process, including experimentation and problem definition, documentation, and collaboration.
- How to handle failures that occur in a production environment during emergency response on-call work.
- How to make code changes easier by applying architectural techniques
- How to utilize agile methodologies such as sprint planning, stand-up meetings, and retrospectives.
- Career management and interpersonal skills, such as how to naturally advance to a senior or higher position

| Target audience for this book |

All developers working in IT organizations or as software engineers, including job seekers, fresh graduates, new hires, job changers, and experienced developers.
And non-development management positions that need to understand developers

| Structure of this book |

Anyone who wants to reach their destination needs a map.
This book covers what you need to start your career.
First, we start with the 'beginner' level, which is where all new developers start.
Then you move on to the "storm and stress" phase where you start coding and learn the rules and procedures.
Next, you move on to the 'Trusted Contributor' stage, where you release meaningful features.
Releasing a feature means navigating the rough waves of the 'sea of ​​operations'.
Eventually, you will land in a safe paradise called 'Land of the Able'.
You will develop the skills of a full-fledged software engineer who can continuously deliver valuable features while collaborating with a team.
This book is intended to help you embark on a long journey alone.

| Author's Note |

You now have a new job: a developer, where you can solve difficult problems, write high-quality code, and use what you create yourself.
What a wonderful thing! Congratulations.
I look forward to solving interesting challenges and creating useful things with wonderful, smart, and passionate colleagues.

But you'll soon realize, or perhaps you already know, that writing programs (using computers to solve problems) isn't everything.
While programming is one of the most important skills to becoming an effective software engineer, you also need to acquire other skills that are never taught in school.
This book is one that can help you learn such skills.

This book presents modern practices for implementing, testing, and running production software.
It also explains behaviors and methods for building strong teams and better teammates.
We'll provide practical advice on how to get help from others, write design documents, deal with legacy code, handle emergencies, create work plans, and communicate with your manager and team.

Of course, this book doesn't cover everything you need to know.
Not only is that impossible, but even if it were all included, it would be tiring to read.
Instead, we focus on providing the most important information that is not typically covered in undergraduate computer science courses.
Because these topics are so in-depth, we've added a "Level Up Reading" section at the end of each chapter, offering recommended additional resources if you'd like more information.

The first few chapters explain what you can expect when you start your career as a developer at a company.
From the middle part, it moves into technical content, introducing writing quality code suitable for production environments, efficient testing, code reviews, continuous integration and delivery, design documentation, and recommended architectural techniques.
The final three chapters cover softer skills, such as agile planning, collaboration with managers, and career management advice.

This book is based on our experience building teams at several unlisted Silicon Valley companies that grew rapidly with venture capital investment.
Your individual circumstances may differ from what is covered in this book, and that's okay.
Although the specifics may differ from company to company, the basics are not very different.

I wish we had this book when we first started our careers as new recruits.
I actually decided to give this book as a gift to a new engineer who joins our team.
By the time you finish reading this book, you'll know what it takes to become a professional software engineer.


| Translator's Note |

One thing I've learned from working as a software engineer in companies in many countries, including Korea, Australia, the US, and Canada, is that building a good engineering culture is difficult regardless of language or culture.
In fact, the definition of a good software engineering culture is not very specific.

Nevertheless, through continuous research, effort, and development, this field has gradually refined the definition of a good software engineering culture.
And this is the book that introduces this culture that has been concretized in that way.
Having been born and raised in Korea as a software engineer, I feel that the content presented in this book still differs significantly from the current software engineering culture of domestic companies.
I think this isn't just a problem with the engineering team, but rather a problem stemming from a difference in the overall corporate mindset.

I lived abroad for about 10 years and recently spent a little over a year working as a principal software engineer at a Korean company.
The engineering team culture I pursued during this period is largely consistent with what is presented in this book.
I do wish this book had been published a little earlier and put into the hands of my colleagues, but I wonder if it would have been a little easier to build the culture I wanted.

Because it is nearly impossible to build a good engineering culture through individual efforts alone.
No matter how much a leader who has experienced a good culture tries to create a good culture, it is useless if colleagues do not understand and follow it.
No matter how much a colleague who has experienced a good culture tries to create a good culture, it is useless if the leader does not support his or her intentions.
Perhaps those of you reading this book have had similar experiences.

That's why this book is highly recommended not only for new engineers just entering the software engineering field, but also for senior engineers, engineering leads, and even CTOs—anyone who wants to foster an engineering culture in their teams that fosters effective communication, mutual respect, and collaborative efforts to achieve goals.
Moreover, if the entire engineering organization works together to adopt the culture presented in this book, its impact and effectiveness will be even more powerful.

I am now at a point where I am ready to challenge myself with another goal in a new place.
I have no doubt that this book will serve as an excellent guide and guidance for me and for you in the future.