Developers can't write?
 |
Description
Book Introduction
Documentation is a skill, and writing is another code.
Developers are still writing today.
From commit messages to readmes, release notes, and technical blogs, writing is necessary in many aspects of our work.
This book is a practical guide for developers who want to become better at writing such articles.
From frequently encountered writing topics like comments, example code, and getting started documents to accurate and concise technical documentation, email and messaging tips, and ChatGPT usage tips, we've compiled content tailored to your specific needs.
As writing accumulates, it becomes a document, and the document soon becomes a skill.
For developers who often hesitate before writing, this book will be a solid first step toward improving their writing skills.
Developers are still writing today.
From commit messages to readmes, release notes, and technical blogs, writing is necessary in many aspects of our work.
This book is a practical guide for developers who want to become better at writing such articles.
From frequently encountered writing topics like comments, example code, and getting started documents to accurate and concise technical documentation, email and messaging tips, and ChatGPT usage tips, we've compiled content tailored to your specific needs.
As writing accumulates, it becomes a document, and the document soon becomes a skill.
For developers who often hesitate before writing, this book will be a solid first step toward improving their writing skills.
- You can preview some of the book's contents.
Preview
index
Recommendation 12
Beta Reader Review 18
Opening 20
PART I Are developers really bad at writing?
1. Do developers communicate through code? 27
2 Repeat, repeat again 29
3 Writing has a purpose 31
4 Stop referring to the translation 34
PART II Developers who write well are different from the start in their code.
5 Writing a Commit Message 41
43 Reasons Why You Should Write Good Commit Messages
Design your commit 46
[Break] Anatomy of a Commit Message 47
Write a commit message title 49
Writing a commit message body 64
Try writing a commit message 68
Commit Message Hotspot 70
6 Developers are 72 name writers
Naming Functions Appropriately 74
Function Naming Practice 84
7 Write error message 100
Error Message Components 101
I saw an error message and I don't know what it means 103
I don't know how to solve it 107
I followed the instructions in the error message, but it didn't work. 109
I don't know where to look for a solution 109
[Take a break] I give you what I have, even though I don't have gold and silver. 110
8 API Annotations 111
API Annotation Format 116
API Description Basic Rules 118
Practice 124
Formatting the Description 128
[Break] Should API descriptions be in English? 130
Writing with OpenAPI Specification 131
Don't trust tools too much 133
[Break] Please write for your future self! 134
PART III Developer's Writing is PR
9 Rhythm 139
Please Read Me 142
What information should I include in the rhythm? 143
Writing a practical reading 148
[Break] Judging "Information Everyone Knows" 153
If possible, choose a red skirt 154
Templates, prepared for you 157
10 Example Code 159
Where should the example code be 160
161 Examples other than source code
Order 168: Creating Source Code Examples
[Break] Hiding Internal Information in Example Code 172
Sample Program 173
[Break] Are the cURL examples also REST API example code? 175
If it doesn't work, it's not code 177
11 Disability Report 179
[Break] The Inconvenience We Experience When Service Stops 181
What is a Disability Report? 181
What do you write in a disability report? 183
Who writes the disability report? 192
When do I write a disability report? 193
Where do I write a disability report? 195
12 Release Notes 206
Release notes? Changelog? 207
[Break] You're right in your rebuttal, but could I be right too? 210
Let's take a look at the release notes 211
[Break] It ain't over until it's over! Deprecated means "not yet." 213
[Break] What if the release notes get too long? 221
[Break] Should Documents Also Write Release Notes? 228
Let's take a look at the change log 229
[Break] If there is no relevant information, state that there is none. 234
13 Getting Started Document 236
Introduction to Getting Started: Signing Up and Installing 238
Getting Started: Performing Basic Functions 240
End of the Beginning 243
Problem Finding Exercise 246
14 Tech Blogs 253
What do you want to achieve? 254
Blog, Basic Framework 257
Blog: What Should I Write? 268
[Take a Break] Try Selling Through Words 270
276 Things to Consider When Writing a Blog
[Break] Digestible Writing 277
Let's start blogging 283
Blogging is hard, right? 289
PART IV There is a technique to technical writing.
15 Accuracy 295
Using Correct Terminology 298
[Break] 305: Packaging Technical Documents Using Practical Expressions
Imperative and Declarative Sentences 307
When can you express both imperative and declarative sentences? 316
[Take a break] Take a break when you can! 317
Reflecting the latest information 317
16 Conciseness 326
Writing in parentheses 328
List and Table 335
[Break] Is a document written solely with a list of points really easy to read? 341
[Break] Cell Merging: Annoying but Unavoidable 345
Diagram 348
17 Completeness 363
Writing an Introduction 364
[Break] Print out the glossary in a short pop-up 371
[Break] Content and purpose are more important than form and technique 374
Write and erase 374
Writing in Korean 387
[Break] Do you know what I'm talking about? 389
[Take a break] We can do it in Korean, in our own language too 396
APPENDIX Messages and AI tools both begin with writing.
A Write an email or message 403
Write an email or leave a message 404
Direct and Respond 406
Report a problem 408
B Using ChatGPT 411
"Help me" instead of "You do it" 411
Writing API Comments 413
Checking Rules 419
Illustration source 426
Beta Reader Review 18
Opening 20
PART I Are developers really bad at writing?
1. Do developers communicate through code? 27
2 Repeat, repeat again 29
3 Writing has a purpose 31
4 Stop referring to the translation 34
PART II Developers who write well are different from the start in their code.
5 Writing a Commit Message 41
43 Reasons Why You Should Write Good Commit Messages
Design your commit 46
[Break] Anatomy of a Commit Message 47
Write a commit message title 49
Writing a commit message body 64
Try writing a commit message 68
Commit Message Hotspot 70
6 Developers are 72 name writers
Naming Functions Appropriately 74
Function Naming Practice 84
7 Write error message 100
Error Message Components 101
I saw an error message and I don't know what it means 103
I don't know how to solve it 107
I followed the instructions in the error message, but it didn't work. 109
I don't know where to look for a solution 109
[Take a break] I give you what I have, even though I don't have gold and silver. 110
8 API Annotations 111
API Annotation Format 116
API Description Basic Rules 118
Practice 124
Formatting the Description 128
[Break] Should API descriptions be in English? 130
Writing with OpenAPI Specification 131
Don't trust tools too much 133
[Break] Please write for your future self! 134
PART III Developer's Writing is PR
9 Rhythm 139
Please Read Me 142
What information should I include in the rhythm? 143
Writing a practical reading 148
[Break] Judging "Information Everyone Knows" 153
If possible, choose a red skirt 154
Templates, prepared for you 157
10 Example Code 159
Where should the example code be 160
161 Examples other than source code
Order 168: Creating Source Code Examples
[Break] Hiding Internal Information in Example Code 172
Sample Program 173
[Break] Are the cURL examples also REST API example code? 175
If it doesn't work, it's not code 177
11 Disability Report 179
[Break] The Inconvenience We Experience When Service Stops 181
What is a Disability Report? 181
What do you write in a disability report? 183
Who writes the disability report? 192
When do I write a disability report? 193
Where do I write a disability report? 195
12 Release Notes 206
Release notes? Changelog? 207
[Break] You're right in your rebuttal, but could I be right too? 210
Let's take a look at the release notes 211
[Break] It ain't over until it's over! Deprecated means "not yet." 213
[Break] What if the release notes get too long? 221
[Break] Should Documents Also Write Release Notes? 228
Let's take a look at the change log 229
[Break] If there is no relevant information, state that there is none. 234
13 Getting Started Document 236
Introduction to Getting Started: Signing Up and Installing 238
Getting Started: Performing Basic Functions 240
End of the Beginning 243
Problem Finding Exercise 246
14 Tech Blogs 253
What do you want to achieve? 254
Blog, Basic Framework 257
Blog: What Should I Write? 268
[Take a Break] Try Selling Through Words 270
276 Things to Consider When Writing a Blog
[Break] Digestible Writing 277
Let's start blogging 283
Blogging is hard, right? 289
PART IV There is a technique to technical writing.
15 Accuracy 295
Using Correct Terminology 298
[Break] 305: Packaging Technical Documents Using Practical Expressions
Imperative and Declarative Sentences 307
When can you express both imperative and declarative sentences? 316
[Take a break] Take a break when you can! 317
Reflecting the latest information 317
16 Conciseness 326
Writing in parentheses 328
List and Table 335
[Break] Is a document written solely with a list of points really easy to read? 341
[Break] Cell Merging: Annoying but Unavoidable 345
Diagram 348
17 Completeness 363
Writing an Introduction 364
[Break] Print out the glossary in a short pop-up 371
[Break] Content and purpose are more important than form and technique 374
Write and erase 374
Writing in Korean 387
[Break] Do you know what I'm talking about? 389
[Take a break] We can do it in Korean, in our own language too 396
APPENDIX Messages and AI tools both begin with writing.
A Write an email or message 403
Write an email or leave a message 404
Direct and Respond 406
Report a problem 408
B Using ChatGPT 411
"Help me" instead of "You do it" 411
Writing API Comments 413
Checking Rules 419
Illustration source 426
Detailed image
Into the book
A well-structured commit range will not only make it easier to write a title, but will also help in the event that a rollback is needed.
Let's say the code that fixed a bug introduces a new bug.
Rolling back may remove the code that caused the problem, but it will also remove the code that modified the UI text.
If you had committed the code that fixes the bug and the code that fixes the UI strings in separate commits, you could keep the version that fixes the UI strings.
--- p.46
If you're having trouble coming up with a function name, try changing the order of your work and writing the title of the message you want to commit first.
You look at the message title, derive a list of functions to perform, then look at the list and derive the function names.
If it's a simple function, you can probably figure it out just by looking at the title.
--- p.74
Error names are abbreviated, such as INVALID_ARGUMENT, TEMPORARILY_UNAVAILABLE, Duplicated Id, or Does not exist.
An error description contains a sentence explaining why the error occurred.
The error message should contain the cause of the error in a sentence so that the user can accurately understand the situation.
--- pp.104-105
If there is example code, most developers will look at the code first and then read the explanation.
Because of this, there is a misconception that everything will be fine if you just have example code.
Some people just post a bunch of code without any explanation, saying, “Why bother writing something when you can figure it out by looking at the code anyway?”
(...) Well-written example code is not just pasting the entire source code of a completed sample program.
A good example code is one that clearly explains in writing how to use a specific function and then extracts and includes only the code related to that function.
It doesn't necessarily have to be complete code, as it focuses on explaining the functionality.
Complete, working code can be shown all at once after the explanation is complete, or provided in a separate repository.
--- p.160
Please write the disability details in two parts: a summary of the disability and a detailed description.
Write a brief description of the issue in two or three sentences, keeping it easy to understand for readers who may not be developers.
Rather than simply stating that a problem occurred with a product or service, clearly state what inconvenience the problem caused the user.
For example, instead of ending with "The server is overloaded due to increased traffic," write "Users of ○○ service cannot log in due to increased traffic and server overload."
--- p.184
What if you can't write an introduction without introducing new terms or abbreviations? In this case, it's better to use the terms as they are, but link them rather than explaining them in detail in the introduction.
For example, if you absolutely must use the term PSS in the introduction, link to another page that explains the term (either an external site, a glossary within the current document, or a related article).
This allows you to introduce new terms without wasting introductory space.
Let's say the code that fixed a bug introduces a new bug.
Rolling back may remove the code that caused the problem, but it will also remove the code that modified the UI text.
If you had committed the code that fixes the bug and the code that fixes the UI strings in separate commits, you could keep the version that fixes the UI strings.
--- p.46
If you're having trouble coming up with a function name, try changing the order of your work and writing the title of the message you want to commit first.
You look at the message title, derive a list of functions to perform, then look at the list and derive the function names.
If it's a simple function, you can probably figure it out just by looking at the title.
--- p.74
Error names are abbreviated, such as INVALID_ARGUMENT, TEMPORARILY_UNAVAILABLE, Duplicated Id, or Does not exist.
An error description contains a sentence explaining why the error occurred.
The error message should contain the cause of the error in a sentence so that the user can accurately understand the situation.
--- pp.104-105
If there is example code, most developers will look at the code first and then read the explanation.
Because of this, there is a misconception that everything will be fine if you just have example code.
Some people just post a bunch of code without any explanation, saying, “Why bother writing something when you can figure it out by looking at the code anyway?”
(...) Well-written example code is not just pasting the entire source code of a completed sample program.
A good example code is one that clearly explains in writing how to use a specific function and then extracts and includes only the code related to that function.
It doesn't necessarily have to be complete code, as it focuses on explaining the functionality.
Complete, working code can be shown all at once after the explanation is complete, or provided in a separate repository.
--- p.160
Please write the disability details in two parts: a summary of the disability and a detailed description.
Write a brief description of the issue in two or three sentences, keeping it easy to understand for readers who may not be developers.
Rather than simply stating that a problem occurred with a product or service, clearly state what inconvenience the problem caused the user.
For example, instead of ending with "The server is overloaded due to increased traffic," write "Users of ○○ service cannot log in due to increased traffic and server overload."
--- p.184
What if you can't write an introduction without introducing new terms or abbreviations? In this case, it's better to use the terms as they are, but link them rather than explaining them in detail in the introduction.
For example, if you absolutely must use the term PSS in the introduction, link to another page that explains the term (either an external site, a glossary within the current document, or a related article).
This allows you to introduce new terms without wasting introductory space.
--- p.370
Publisher's Review
Documentation is as important as code, and now we'll teach you how to write it.
“Developers can’t write?”
If developers are so terrible at writing, who writes all those technical articles and blog posts? They're all written by developers.
I write commit messages, name variables, write readme, and reply to Slack messages every day, constantly writing.
Yet, many developers find writing difficult.
Because I never learned what to write and how to write it.
This book provides practical answers to that confusion.
This guide, with practical examples, explains practical writing strategies you can immediately apply in your work: how to write clean, one-line commit messages, principles for clearer variable and function names, how to refine error messages and comments from a user perspective, how to easily structure readme and getting started documents, and even tips for enhancing explanatory power in technical blogs.
This comprehensive guide covers the technical writing essential to today's developers, from essential collaborative writing like email and Slack messages to prompts for asking and explaining questions to ChatGPT.
Developers can't write? No.
With this book, even developers can become good writers.
Key Contents
● How to write commit messages, error messages, and comments clearly
● Naming principles for creating good variable and function names
● How to structure readme, release notes, and getting started documents in practice
● How to improve your explanations with technical blogs and example code
● Three techniques for writing accurate and concise technical documentation
● Tips on writing good emails and messages and using ChatGPT
“Developers can’t write?”
If developers are so terrible at writing, who writes all those technical articles and blog posts? They're all written by developers.
I write commit messages, name variables, write readme, and reply to Slack messages every day, constantly writing.
Yet, many developers find writing difficult.
Because I never learned what to write and how to write it.
This book provides practical answers to that confusion.
This guide, with practical examples, explains practical writing strategies you can immediately apply in your work: how to write clean, one-line commit messages, principles for clearer variable and function names, how to refine error messages and comments from a user perspective, how to easily structure readme and getting started documents, and even tips for enhancing explanatory power in technical blogs.
This comprehensive guide covers the technical writing essential to today's developers, from essential collaborative writing like email and Slack messages to prompts for asking and explaining questions to ChatGPT.
Developers can't write? No.
With this book, even developers can become good writers.
Key Contents
● How to write commit messages, error messages, and comments clearly
● Naming principles for creating good variable and function names
● How to structure readme, release notes, and getting started documents in practice
● How to improve your explanations with technical blogs and example code
● Three techniques for writing accurate and concise technical documentation
● Tips on writing good emails and messages and using ChatGPT
GOODS SPECIFICS
- Date of issue: November 20, 2025
- Page count, weight, size: 428 pages | 170*225*20mm
- ISBN13: 9791194587637
You may also like
카테고리
korean
korean
![ELLE 엘르 스페셜 에디션 A형 : 12월 [2025]](http://librairie.coreenne.fr/cdn/shop/files/b8e27a3de6c9538896439686c6b0e8fb.jpg?v=1766436872&width=3840)
