Split AI Development Work by Context, Device, and Risk
Combine IDE review, desktop agents, and a remote mobile workflow by assigning each task according to context size, inspection needs, and operational risk.
Articles
Notes, essays, and observations.
Evolve Development Templates from Observed AI Workflows
Update development templates from repeated AI-assisted use, while keeping validation explicit and project-specific instructions out of universal defaults.
Store Object Keys, Not File URLs
Design file uploads around stable object keys, server-composed delivery URLs, collision-resistant names, and separately retained original filenames.
Split AI Changes into Pull Requests Teammates Can Review
Keep AI-generated code accountable by narrowing scope, rebuilding coherent commits, and splitting risky changes into pull requests teammates can understand.
AI Output Is Not the Same as Engineering Productivity
AI agents can raise output, but complex work still depends on context, memory, judgment, and the self-directed thinking of strong teammates.
Judge AI Practices by Real Workplace Utility, Not Buzzwords
Test AI practices in real work instead of chasing labels, and use firsthand experience to separate durable methods from marketing-driven fear.
Build Career Density, Not Just Study Time
Career growth comes less from unrelated study during work hours than from building dense, explainable experience through meaningful company work.
When to Split Front-Office and Back-Office Systems
Decide whether front- and back-office systems belong together by comparing purpose, lifecycle, feature overlap, team workflow, and operational cost.
How to Evaluate a Bootcamp Beyond Its Brand
Evaluate a bootcamp through concrete learning goals, mentor capability, credible outcomes, practical limits, and whether the price is justified.
Choosing Project Structure and Tech Stacks in the AI Era
Choose project boundaries and technology stacks by team size, existing expertise, reviewability, and failure cost—not AI output speed alone.
Simplify Modules and Layers for AI-Assisted Greenfield Work
Explore fewer modules, interfaces, and layers for AI-assisted greenfield work, while protecting clarity, quality, and incremental treatment of legacy systems.
Make Overwork and Leadership Failures Visible
Turn engineering overload into visible work, shared evidence, and scoped escalation so teams can negotiate resources and expose recurring leadership failures.
Model Drafts by Meaning: Status or Separate Storage?
Choose a status for ordinary lifecycle stages and separate versioned storage for distinct preparatory data, based on domain meaning and compatibility cost.
Break Sequential ID Links in Anonymous Services
Use independent random identifiers for identity-related records to remove obvious sequential links, while recognizing that UUIDs alone cannot guarantee anonymity.
Hide Preview Content at the Server Boundary, Not in CSS
Do not ship gated text and merely blur it in the client; transform previews at the server response boundary while preserving an honest layout cue.
Coordinate Account Deletion Cleanup Without a Message Broker
For small services, collect domain-specific cleanup handlers behind one interface so account deletion stays explicit without extra messaging infrastructure.
Split All-in-One Libraries into Composable Dependency Modules
Avoid hidden infrastructure, runtime cost, and dependency conflicts by splitting company libraries into modules each service can understand and compose deliberately.
Server-Driven API Responses for Mobile App Compatibility
Keep changing display policy and experiments server-side for old app versions, but isolate that translation at the API boundary to protect the domain model.
Turn an Unusual Developer Background into an Interview Strength
Keep your full work history honest, then tailor project emphasis to each role so adjacent experience gives interviewers credible reasons to hire you.
Keep a Small Documentation Set the Team Can Trust
Reduce documentation sprawl by maintaining a trusted core of policy, concepts, system flows, and API contracts with clear ownership and onboarding feedback.
Change Engineering Culture Through Trust and Small Wins
Learn a new organization before prescribing fixes, earn trust through delivery, and let visible gains from tests and shared policy work spread beyond your team.
Design Data Relationships for Organizational Reality
Prefer simple relationship cardinality, then account for observed requirement churn, decision habits, and deadline constraints instead of predicting every future change.
Turn Tacit Engineering Rules into Living Team Conventions
Document the engineering rules teammates carry in their heads, explain why they exist, permit team overrides, and keep them alive through review and onboarding.
Avoid the Admin Common Module That Owns Every Domain
Keep admin features from reversing domain dependencies. Preserve service boundaries and accept small duplication while admin requirements continue to diverge.
Build Engineering Career Range Across Company Sizes
Match company scale to your long-term path: broaden operating and leadership experience when needed, or preserve focus when deep technical craft is the goal.
Oracle to MySQL Migration with Adapters, Dual Writes, and Flags
A reversible Oracle-to-MySQL migration using compatible adapters, dormant deployments, dual writes, tested switches, deliberate rollback, and legacy cleanup.
Choose Your Next Developer Job for Experience, Not Salary Alone
Compare developer jobs by the domains, operating problems, and responsibilities you can turn into lasting capability, while respecting real financial constraints.
Engineering Leadership Starts Before the Title
Prepare for engineering leadership by already handling reviews, incidents, broad problems, and peer trust before an organization adds the formal title.
Design Your Developer Career Around Strengths and Experiments
Map your strongest capabilities, test different kinds of engineering work, and keep revising a future direction from evidence rather than vague ambition.
Code Review Health Is a Trend, Not a Comment Count
Use automation and draft pull requests to align teammates early, then track whether repeated feedback declines as shared conventions become real practice.
Account Deletion Data: Retention, Separation, and Recovery Design
Design deleted-account data around verified retention rules, isolated storage, encryption, expiry, and the operational flows that may still need recovery.
Java Optional Rules: Keep Absence at Data Boundaries
Use Java Optional where a missing return value gives callers a real choice, while keeping fields, parameters, and trusted internal flows explicit.
How to Break Long Legacy Migrations into Small, Deployable Steps
Break exhausting legacy work into small development, verification, and deployment increments that create feedback before a perfect rewrite.
Discover Domain Concepts from Information and Behavior
Use information and process or behavior from case-dependent viewpoints to distinguish transport events from domain concepts.
Why Domain Concepts Should Not Mirror Database Tables
Model business importance, hierarchy, and behavior instead of creating one domain object and repository for every persistence table.
Developer Testing Responsibility Before QA Handoff
Verify expected behavior before QA handoff so testers can pursue edge cases, reduce release loops, and build stronger cross-functional trust.
Calculate the Full Cost of a New Programming Language
Evaluate language adoption through hiring, learning, observability, shared libraries, integration, and maintenance—not technical fit alone.
Prove Domain Knowledge Through Real Problem Solving
Domain expertise grows through real operations, policy, and cross-team problems. Show it through concrete problem solving, not terminology alone.
Improve a Bad Legacy Schema Behind a Code Boundary
Hide cryptic tables behind repositories and meaningful types, regain control in code, then approach improvements to the legacy database.
Design Distributed Tracing and Safe Production Logs Together
Correlate requests across services while controlling log volume, masking sensitive fields, limiting access, and retaining only useful operational data.
Why Pagination Count Queries Slow Down Databases
Understand why exact totals can cost more than limited queries and when to consider slices, cached metadata, estimates, or product changes.
Split Batch Ingestion from Processing to Reduce Retry Cost
Stage external data, rerun internal transformations without repeating provider calls, and reduce the traffic and recovery costs of oversized batch jobs.
Refactor Spaghetti Code with Characterization Tests
Capture legacy behavior with broad API tests, refactor behind the safety net, and deploy small reversible changes while coverage grows.
Vibe Coding Still Requires Engineering Judgment
Use AI coding tools without surrendering problem definition, code review, quality standards, or the technical knowledge needed to verify results.
Agile Does Not Mean No Documentation
Agile values working software without banning documentation. Write what teams, continuity, security, and regulated operations genuinely require.
Your Company Provides Experience, Not Developer Growth
Developer growth comes from turning work, books, projects, and communities into personal judgment—not waiting for an employer to do it.
Reduce Account-to-Profile Linkability in Anonymous Services
Explore identifier separation, disposable mapping keys, minimal retention, and the recovery tradeoffs behind a privacy-oriented account model.
Keep Guest Data Masking in the Presentation Layer
Learn why guest masking and author flags belong at the presentation boundary, keeping domain logic clean while preventing raw data exposure.
What Senior Engineers Owe the Developers Who Come Next
Seniority is more than tenure: learn how maintainable code, tests, guidance, and team continuity define responsible senior engineering.
Separate Core Data from Like-Count Aggregates
Design scalable like-based ranking with separate aggregates, explicit freshness goals, async updates, reconciliation, and search boundaries that follow real demand.
Use ID Range Gaps for Safer Database Rollbacks
Separate legacy and new identifier ranges to prevent rollback collisions, simplify reverse migration, and make operational traffic easier to trace.
Split God Query Methods by Purpose
Replace universal dynamic queries with purpose-specific methods, migrate callers incrementally, and shrink the side-effect surface before deeper refactoring.
How Experienced Entry-Level Developers Can Stand Out
Prepare prior work for interviews by explaining what you did, the problem you faced, how you approached it, the solution you tried, and the action you took.
Legacy Cleanup Starts with Safe Dead-Code Removal
Shrink legacy systems safely by combining runtime evidence, database checks, API consumer verification, and incremental dead-code deletion.
Modernize Legacy Systems with Small Deployments
Reduce modernization risk with small verified deployments, practical rollback boundaries, visible progress, and value that survives a paused project.
Solve Small Problems with Proportional Engineering
Measure what existing systems can do, solve small problems proportionally, and add caches or distributed infrastructure only when evidence demands it.
Find Domain Boundaries Through Concept Lifecycles
Compare creation, reads, changes, and deletion to judge cohesion, coupling, and boundaries among products, orders, payments, shipping, and settlement.
Paginated Like Counts: Start with a Simple Query
Count likes for the current page with a bounded query before adding counter columns or Redis and their added management costs.
Separate Domain Learning from Technology Experiments
Use familiar tools to launch domain projects, and isolate unfamiliar infrastructure in minimal experiments with focused performance tests.
Developer Growth Starts with Finishing the Work
Build professional trust by completing valuable work within a quality baseline, then refactor, learn, and prepare deliberately for the next step.
Protect Order Snapshots with Soft Delete and Boundaries
Separate current products from immutable order snapshots, preserve refund history, and use status transitions or archives before destructive deletion.
Keep Core Entities Light by Delaying ORM Associations
Decide ORM associations by lifecycle and responsibility, separating searchable supporting data so core entities stay focused and adaptable.
Architecture Rules Need Team Judgment Before Automation
Balance automated layer enforcement against review capacity, repository scale, developer growth, and a team's need to reason about architecture.
Translate Exceptions at Module Boundaries
Keep implementation exceptions inside their modules and define explicit translation boundaries that prevent dependencies from leaking upward.
Why Manager and Processor Classes Are Refactoring Signals
Use vague class names as code-smell signals, then narrow responsibilities and right-size layers without denying necessary transitional design.
Swagger vs REST Docs: Choose API Documentation by Context
Compare Swagger and REST Docs by test enforcement, code intrusion, customization, and a pragmatic migration path for legacy APIs.
Reader and Writer Are Options, Not Architecture Rules
Choose Reader, Writer, and tool-layer boundaries from code size, domain distance, legacy constraints, and team conventions—not imitation.
The Common Module Trap: Organize Code Around Concrete Capabilities
Delay common modules until ownership is clear, and organize logging, exceptions, and shared protocols around concrete capabilities instead.
Join the Team Before You Try to Change It
Adapt to a new engineering team through timely questions, visible progress, early review, and small evidence-based changes after trust is earned.
How to Break Up a Giant Service Class Without Guesswork
Split an oversized service by mapping concepts, tracing responsibilities, testing boundaries, and comparing concrete refactoring options.
Keep Operational Tables Clean by Building a Separate Query Model
Design operational tables around business concepts, then serve complex history and admin searches from a separate query model.
Enums or Code Tables? Let the Rate of Change Decide
Use enums for stable values and focused tables for frequently changing ones without turning one common-code table into a dumping ground.
One Database, Separate Boundaries: Controlling Data Access by Domain
How separate entity and repository boundaries can protect core rules from integration code even when both areas share one database table.
Append, Don’t Overwrite: Designing Immutable Operational Data
An append-only repayment example that makes history and synchronization clearer, along with the storage and query costs it introduces.
What a Utility Bill Can Teach Us About Domain Modeling
How a utility bill revealed a missing delinquency concept in a repayment model and why everyday artifacts can guide software design.
Rank Your Domain Concepts Before You Spend Design Effort
Identify a small first tier of domain concepts, separate supporting flows, and spend limited design time on the service's center.
Experience, Repetition, and the Developer Who Keeps Growing
How varied experience, repeated attempts, and business awareness help developers solve unfamiliar problems and keep improving.
Before Fixing Circular Dependencies, Fix the Domain Model
Resolve confusing ownership and concept boundaries before using interfaces or dependency inversion to treat an apparent circular reference.
Create a Deliberate Messy Boundary to Keep the Core Clean
Contain unavoidable complexity in an explicit outer boundary so limited engineering time can protect the system's core concepts.
Nullable or Zero? Choosing a Kotlin JPA Entity ID Strategy
Compare nullable and zero-valued numeric IDs for Kotlin JPA entities, including new-entity detection, ambiguity, and verification.
CS Knowledge Becomes Valuable When It Solves Real Problems
Learn computer science through real engineering problems, then show the reasoning and improvements it made possible in your work.
Layering That Teammates Can Understand—and the Build Can Enforce
Define stable layer roles, constrain optional upper layers, and automate checks only when a team needs stronger enforcement.
Turn Production Incidents into Shared Domain Knowledge
Use incident reviews, working notes, concept maps, and rotated operations to reduce domain knowledge gaps across a software team.
One Project, Many Deployables: Drawing Boundaries by Runtime Role
Separate public, admin, batch, and operations workloads into runnable applications without splitting the whole codebase into separate projects too early.
Name Readers, Finders, and Searchers by Behavior
Distinguish Reader, Finder, and Searcher classes by direct reads, added filtering, and composite searches rather than result count.
Measure Before Replacing Outbox Polling
Evaluate outbox polling with realistic load tests, then consider a simpler application-level delivery path before adopting log tailing.
Publish Events Where the Business Flow Is Visible
Place event publication in the layer that understands the completed business action, while keeping implementation-specific cases explicit.
Compose My Page Data Without Inventing a My Domain
Build My page summaries through a dedicated composition layer while keeping user, order, and product responsibilities in their proper domains.
Modules, Layers, and Architecture Are Different Decisions
Separate module boundaries from code-level layers and architectural style, then extract modules only when implementation needs stronger constraints.
Earn Your Interfaces: Abstraction After Evidence
Start with concrete code, extract interfaces from proven variation, and keep one-to-one abstractions only when they create a real boundary.
Choose Hexagonal Architecture for a Reason
Choose hexagonal architecture when protocols, isolation, scale, or likely growth justify its extra structure—not because the label signals skill.
Track Database Changes with the Work That Ships Them
Collect database changes with the issue and PR that need them, test them in development, and hand off the final release set before code deployment.
Authorization Without Redundant Reads
Resolve the logged-in user once, keep access checks focused, and separate system-wide administration from channel-level permissions.
Design for Change with Core Ownership and Surrogate Keys
Centralize a shared registration rule in the core, escalate isolation only when needed, and keep changing business uniqueness out of the primary key.
Why a My Page Is Not a Domain
A My Page is a client-facing view, not a business domain. Keep orders, products, and coupons with their real owners and combine them at the boundary.
Software Is Not Done Until It Is Deployed
Stale pull requests and delayed releases make changes harder to review, deploy, diagnose, and roll back. Keep the path to production short and observable.
Separate Shared Counts from Personalized Cache State
Compose a reaction status from reusable queries, then cache the shared count without leaking one member’s personalized state to everyone else.
What Repeated Failure Teaches a Developer Career
Career failures become useful when they change how you verify opportunities, value trusted referrals, and revise the rules you made from earlier setbacks.
One Read Model for Guests and Members
Return public reaction counts and member-specific state through one read flow while keeping optional identity distinct from required authentication.
Rebuild First, Migrate Second
Design a replacement system around the problems it must solve, then handle legacy data through explicit migration mappings and retirement conditions.
Modeling Reactions from Requirements to Scale
Turn a vague like-button request into a reaction model by clarifying policy, estimating data growth, and planning when count queries must change.
Designing Domain Models Beyond the Shape of the UI
A tree-shaped API does not require a tree-shaped domain. Keep the client contract at the presentation boundary and compose it from internal concepts.
Put Logic Where Change Is Cheapest: Client vs. Server
Place display-only work near the UI, but centralize meaningful or changing values when multiple clients and shipped app versions make updates expensive.
Don't Distort Production Code Just to Make Tests Easier
Change production code when its behavior becomes clearer or legacy code needs a testing seam—not merely to expose values or methods that only tests use.
Modernize Legacy Systems Gradually—and Treat Caches as Operations
Choose legacy boundaries carefully, change them in small steps, and add a shared cache only after DB work and deployment failure modes are understood.
Reversible Design Is the Antidote to Overengineering
Build the requirement in front of you, look only a little beyond it, and keep speculative structures cheap to expand, remove, or replace.
Win Technical Arguments with Small Proofs, Not Opinions
Diagnose why a proposal is blocked, build a small proof, strengthen your reasoning, understand the opposing case, and treat new technology as company risk.
A Practical Entry Strategy for a Frozen Junior Developer Market
In a tight 2024 hiring market, broaden the first-company search, turn real work into problem-solving evidence, and show reasoning rather than a technology list.
Build APIs for Clarity, Not REST Purity
Use REST ideas where they improve an HTTP contract, but let client clarity, team consistency, domain boundaries, and change cost decide the API.
Validate at the Boundary, Simplify the Core
Turn API input into complete business values at the presentation boundary, keep nulls out of inner flows, and validate stored data when it enters the system.
From SI to Product Development: Turn Job Requirements into a Learning Plan
A move from contract work to a product team depended on help and luck; the repeatable strategy is to study target job requirements and build relevant experience.
Your First Test Can Be Messy—Refactor It Later
Start with the test that proves the behavior you care about, mock enough to make it run, and improve test design through repeated use and review.
Keep API Request Models Out of the Core Domain
Convert external request objects into business-owned values at the presentation boundary so the API depends inward and the core never depends back.
Design Performance Tests from Real Traffic Shapes
Estimate volume and arrival patterns before choosing a load test, add deliberate headroom, and require evidence only where traffic risk justifies it.
Foreign Keys Are an Operational Tradeoff, Not a Rule
Choose foreign keys, indexes, and ORM mappings from integrity needs, incident response, deployment practice, and who operates the database.
Give Cross-Domain Behavior to the Domain That Owns It
Before placing a caller-owned interface across modules, identify which domain owns the action and let callers depend on that capability.
Who Owns the Enum? Dependency Design Across Domain Modules
Put a business enum with its domain, let storage depend inward, and use a small shared enum module only while the domain boundary is still emerging.
Provider Identity and Authentication Boundaries for Platform APIs
How a small platform API resolves provider keys into a domain identity, separates tenant data, and chooses an authentication boundary that fits its scale.
Where Cross-Domain Coordination Code Belongs
Use business ownership, cohesion, imports, and a package-move experiment to place code that coordinates a primary action with another domain's rule.
Domain Models First: A Conservative Approach to JPA Associations
A cautious way to map JPA entities: start with IDs, add associations only when lifecycles truly align, and model business concepts independently.
You Can Practice High-Traffic Engineering Without Real Traffic
Build and operate a small service, create load deliberately, and show how you found and fixed bottlenecks without pretending a load test equals production experience.
Reliable Database Tests Without a Shared Test Database
Choose mocks, an in-memory database, Testcontainers, or a real database by the failure you need to catch, while keeping ordinary tests isolated from shared infrastructure.
Do Not Create a DTO for Every Layer by Habit
Use DTOs where data crosses a boundary with a different contract. Mapping has a cost, but so does letting external request shapes define the inside of a service.
Git History Is a Team Asset, Not a Work Diary
Split work before polishing commits, shape pull requests for reviewers, and leave a history that helps the next engineer understand changes and recover a release.
Put Circuit Breakers Next to the Failing I/O
Circuit breakers, timeouts, cache fallbacks, and remote-call policies belong near the implementation that performs the I/O, while domain code chooses the required behavior.
Timeouts Are Product Decisions, Not Just Client Settings
Design timeout, retry, and recovery policies from the user's waiting budget and the uncertainty of each failure instead of applying one retry rule everywhere.
Do Not Split Modules Before the Domain Has Matured
Domain maturity comes from understanding policy, behavior, and operating reality. Let those lessons reveal module boundaries instead of freezing guesses too early.
Grow Software One Boundary at a Time
Start with working code, then extract functions, classes, packages, modules, and projects as real cohesion and scale make each stronger boundary necessary.
Keep Layers Logical and Packages Cohesive
Modules, packages, and architectural layers solve different problems. Package related behavior together and let layers describe roles without scattering a feature.
Upgrade Dependencies Before the Gap Becomes a Project
Frequent, prioritized dependency upgrades keep change small, expose compatibility problems early, and prevent a maintained service from quietly accumulating debt.
Software Should Survive the Developer Who Built It
Good company software reduces debt, fits the team's operating ability, and remains understandable and repairable after its original developer leaves.
Unit Tests Should Preserve Business Intent
A business-layer unit test is useful when it guides design, records meaningful behavior, or makes the next developer reconsider a risky change.
When an AI Agent Calls the Same Tool Twice
Retries are normal in distributed systems and AI workflows. Use database constraints, idempotency keys, and bounded retries to prevent duplicate side effects.
Multi-Module Too Early Makes Design Harder
Modules should enforce boundaries discovered through implementation, not freeze guessed domains or mirror an architecture diagram before the software is understood.
Gradle Dependency Scopes Are Architectural Boundaries
Use Gradle implementation, api, runtimeOnly, and compileOnly deliberately to express module access, prevent accidental coupling, and preserve design intent.
Operate Your Toy Project Before Calling It a Service
A toy project becomes service experience only after launch: pick one goal, find real users, watch retention, and learn when to stop.
Isolate Admin Work from the Service Domain
Admin APIs have different queries, mutation needs, and release risks. Isolate them by module or repository instead of letting operational convenience reshape the core service.
Use Reader and Writer Components to Reveal Business Flow
Reader and writer components can hide storage details, narrow change, and let the business layer show policy, but only when the software's lifetime justifies them.
Carry One Trace ID across Distributed Services
Logs become operationally useful when one request can be followed across HTTP calls and asynchronous events without exposing sensitive data or flooding storage.
Define Problems from the User's Perspective
Problem-solving improves when you separate technical load from product value, launch what you build, and keep asking why a user would choose it.
Reuse Below the Use-Case Layer
When use cases call one another for reuse, business changes spread and cycles follow. Compose above them or extract focused implementation components below them.
Choose Experience and Judgment over Development Jargon
Theories and patterns are useful references, but a developer still needs to explain the code, its tradeoffs, and what happened when it was operated.
How to Split a Large Service Class by Responsibility and Layer
Use constructor dependencies and imports to diagnose an oversized service, then separate cohesive responsibilities before adding another architecture label.
Choose Normalization from Requirements and Object Relationships
Database normalization is not a score to maximize. Decide from change semantics, query cost, and the relationships the data is meant to preserve.