AI Translated Document
- This document was translated using an AI translation tool.
- Due to the nature of AI translation, some sentences or terms may be interpreted differently from the original intent.
- There may be mistranslations or inaccuracies, so please refer to the original text or consider additional review if accuracy is critical.
- Your suggestion for a better translation would be highly appreciated.
Original Document in Korean
Documents (EN): Architect HJ's Records¶
โBeyond code, I record my thoughts.โ
This space contains the essence of technology, architectural decisions, and the intuition and experience of an architect.
Author's Note¶
The writings here are not mere information.
They are insights gained from real projects, concerns, and repeated moments of architectural judgment.
Every choice is bound by causality. Technical decisions are not limited to technology alone, but extend to the success or failure of maintenance, operations, and management.
As an architect, I organize risks, seek optimal solutions, and record reproducible decisions.
List of All Documents¶
- Design Patterns Are Meant to Be Modified
- Distrustful Coding vs Trustful Coding
- How to Become a Software Architect
- Software Architecture Is Decision-Making, Not Imitation
- Software Architecture Is Determined by Invariants, Not Extensibility
- Architecture Is a Structural Solution
- Static Typed Languages (TS) vs Dynamic Typed Languages (JS): Different Approaches
- Please, Reduce catch
- You Must Follow Intuition to Make Code Readable, and Readable Code Is Easier to Modify
- Proof of the Possibility of a One Man Framework
- Don't Use Restful So Blindly
- TDD - Unit Tests Did Not Provide Value
- What Is a Technical Asset in the IT Field
Reading Suggestion for Non-Developers¶
[Note] Technical choices are tied to other perspectives by causality.
The basis for IT decisions inevitably contains technical content.
If you are a non-expert, focus on the 'causal relationship' that controls business value and risk, rather than the technical evidence itself.
- Focus on 'Why' rather than 'How'. Execution is a professional domain, but the business advantages (stability, cost reduction, speed) gained from it are the language of management. Follow the causal relationships behind the technical evidence.
- Technical evidence is the 'basis for risk/benefit'. Unfamiliar terms in the articles are names of 'potential risk factors' or 'sources of business benefit' discovered by the architect. Even if you do not understand the detailed workings, it is enough to read with the perspective of "How does that name affect our service?".
- Please understand these as records of decision-making. These documents are not just knowledge transfer, but records of the architect's best decisions in specific situations. The purpose is to share the 'thought process' of 'giving flesh to take bone' against technology.
Recommendation for "Managers Considering Sustainable Business Speed"¶
[Business Impact] Excellent architecture is not just a technical choice but a survival strategy for business. It provides insight into why blindly following popular technologies is dangerous, and how defining the 'unchanging core' of our business leads to long-term cost reduction. It contains strategies for setting up the initial structure so that the development team is not held back during planning changes or market responses. Recommended for leaders who want to maintain 'development speed' in the long term.
- Proof of the Possibility of a One Man Framework
- Architecture Is a Structural Solution
- Software Architecture Is Determined by Invariants, Not Extensibility
- Don't Use Restful So Blindly
Recommendation for "Decision Makers Who Must Consider ROI of Technology Adoption"¶
[Business Impact] Technologies or methodologies (TDD, REST, etc.) that are 'trendy' in the industry do not always guarantee business success. It discusses the importance of 'practical decision-making' that selects the most efficient tools for our team's situation, stripping away formalistic development practices. Recommended for leaders who are concerned about efficient resource allocation.
- TDD - Unit Tests Did Not Provide Value
- Don't Use Restful So Blindly
- Please, Reduce catch
- Design Patterns Are Meant to Be Modified
- Distrustful Coding vs Trustful Coding
Recommendation for "Those Who Want to Understand the Culture of Technical Organizations and Communicate with Developers"¶
[Business Impact] Engineering is not just a process of creating functions, but of organically building complex information processing structures. It explains what developers value and how it connects to products. By understanding developers' criteria, you can build deeper trust with technical organizations and lay the foundation for smooth communication.
- You Must Follow Intuition to Make Code Readable, and Readable Code Is Easier to Modify
- How to Become a Software Architect
- Please, Reduce catch
- Software Architecture Is Decision-Making, Not Imitation
Reading Suggestion for Developers¶
Recommendation for "Juniors to Mid-levels Experiencing Growing Pains"¶
[Reason for Recommendation] Beyond the 'usage' of technology, it is a stage that corrects the 'fundamentals of engineering'.
- How to Become a Software Architect
- Architecture Is a Structural Solution
- Please, Reduce catch
- You Must Follow Intuition to Make Code Readable, and Readable Code Is Easier to Modify
Recommendation for "Mid to Seniors Confused Between Practice and Theory"¶
[Reason for Recommendation] For those who wonder why textbook methodologies (TDD, design patterns, REST) become 'burdens' in the field.
- Design Patterns Are Meant to Be Modified
- TDD - Unit Tests Did Not Provide Value
- Don't Use Restful So Blindly
- Software Architecture Is Decision-Making, Not Imitation
Recommendation for "Seniors and Above Who Want to Delve into Technical Depth and the Essence of Architecture"¶
[Reason for Recommendation] A high-level stage that explores the 'unchanging principles of design' beyond technological trends.
)