From Writing Web Novels to Shipping Software — Nocklock’s Developer Journey
“I think AI is most useful when it extends my thinking rather than replacing it.”
Nocklock didn't originally become a developer because programming was a lifelong childhood dream.
It started for a much more practical reason: making a living.
A few years ago, before AI became deeply integrated into everyday software development, Nocklock was looking for a practical way into the industry. In Korea, Java and Spring were widely used in enterprise and public-sector development, making them a natural choice.
But programming eventually became interesting for a reason that had little to do with career practicality.
Before becoming a developer, Nocklock had commercially published two web novels.
That experience would unexpectedly influence the way he thinks about software.
Writing fiction means creating a world, defining its rules, and allowing characters to interact within those rules.
Software isn't so different.
Programming languages have rules. Networks have rules. Data has structure. Business logic creates constraints. Developers build systems and user flows inside those constraints.
The connection between writing and programming gave Nocklock a different way of thinking about development.
Instead of seeing software only as code, he began seeing it as a system of possibilities.
And that perspective continues to influence how he builds today.
Programming Started as a Practical Choice
Nocklock's initial decision to learn programming was pragmatic.
Java and Spring offered a realistic path into professional software development, particularly within Korea's enterprise and public-sector technology landscape.
But choosing a technology for practical reasons doesn't necessarily mean remaining interested for practical reasons.
As Nocklock gained experience, he discovered that programming gave him something he had already experienced through writing:
the ability to create systems governed by rules.
When writing a novel, he might ask:
What if I were the character?
What if the situation were different?
What would happen if the rules changed?
He now brings similar questions into software development.
When building something, he tries to imagine different situations and perspectives.
What if he were the user?
What if the user knew nothing about the subject?
What if the environment were different?
What if an assumption turned out to be wrong?
That habit of questioning has become part of how he approaches development.
Learning by Shipping
One of Nocklock's strongest beliefs is reflected directly in his profile:
learning by shipping.
He discovered why this approach worked for him while studying for Korea's Engineer Information Processing qualification.
Much of the preparation involved studying and memorizing theory.
But he noticed something interesting.
He could forget information he had memorized for an exam.
Yet he could still remember errors he had encountered while working, why they happened, and how he eventually solved them.
The difference was experience.
Knowledge connected to a real problem stayed with him.
That realization changed how he approached learning.
When he encountered an AI development competition, he began building rather than waiting until he had learned everything he thought he needed to know.
He learned what was necessary while developing the project.
He made mistakes.
He investigated them.
He fixed them.
And eventually, he shipped.
That's what learning by shipping means to him.
It doesn't mean abandoning study.
It means turning knowledge into experience.
Security Lens: When the MVP Became Real
One of the clearest examples of this philosophy was Security Lens.
The original idea sounded relatively straightforward.
A user would upload an image, OCR would extract information, the system would identify potential privacy risks, and the user would receive useful results.
But building the real product exposed a much messier reality.
Real files and images didn't always behave as expected.
OCR accuracy wasn't always reliable.
Unexpected problems kept appearing.
And once the core functionality finally worked, Nocklock realized something important:
The main feature working didn't mean the product was finished.
It meant the next phase had started.
There were still improvements to make, problems to investigate, and a deadline approaching.
That experience changed his understanding of what it means to ship software.
Building the main feature is only one milestone.
Shipping means confronting the difference between:
the product you imagined
and
the product that actually exists.
The README Became a Product Review
Nocklock initially thought writing the README would simply mean documenting what he had already built.
Instead, documentation exposed problems in the product itself.
During development, he had often moved quickly from one problem to the next.
Get something working.
Move forward.
Solve the next issue.
Keep building.
But when he tried to explain the project clearly, he started noticing gaps.
Sometimes he would describe a feature and suddenly question whether the feature was necessary at all.
That changed the purpose of the README.
It was no longer just documentation.
It became a way of reviewing the product.
Writing forced him to examine:
- The project structure
- Individual features
- Development decisions
- The reasoning behind those decisions
- Whether certain features were actually necessary
In that sense, documentation became another form of development.
Sometimes explaining what you built reveals whether you should have built it in the first place.
A New Laptop Revealed Hidden Complexity
Another unexpected lesson came from something much more ordinary:
setting up a new laptop.
Moving from an established development environment to a clean machine exposed how much invisible state had accumulated over time.
JDK versions.
PATH settings.
Git configuration.
IDE settings.
Build synchronization.
Environment variables.
Small setup decisions that had gradually become invisible.
On the old machine, those things simply worked.
On the new one, they didn't.
Suddenly, when something behaved unexpectedly, Nocklock had to ask:
Is this a problem with my code?
Is it the build state?
The JDK?
The IDE?
The environment configuration?
That experience led to an important realization:
The development environment is part of the system too.
A clean machine can reveal what you genuinely understand and what your previous environment had quietly been doing for you.
Debugging Doesn't Stop at the Code
Deployment reinforced the same lesson.
Local development can feel comfortable.
Then the application gets deployed.
Suddenly, ports, environment variables, runtime differences, external services, configuration and hidden assumptions all become part of the problem.
Nocklock experienced this while deploying Security Lens to Railway.
It also helped him understand why tools such as Docker became so important.
Docker doesn't eliminate every deployment problem.
But making the runtime environment reproducible can remove a significant category of differences between machines.
As a result, his approach to debugging has expanded.
He doesn't look only at the code anymore.
He also considers:
- Configuration
- Runtime
- Environment
- External dependencies
- Deployment conditions
- Assumptions connecting those pieces
Sometimes the bug isn't in the code.
Sometimes the code is behaving exactly as written inside an environment you misunderstood.
Why Java and Spring Still Matter
Nocklock originally chose Java and Spring because they were practical.
After working with them professionally, however, he developed a different appreciation for the ecosystem.
What stands out to him is its maturity and structure.
Backend services can quickly become complicated.
They may involve:
- Business logic
- Databases
- APIs
- Security
- External integrations
- Multiple requirements
- Different environments
In that situation, conventions and proven patterns can become extremely valuable.
Spring provides abstractions that help developers build quickly while still leaving a deeper ecosystem underneath those abstractions to understand.
But Nocklock doesn't believe Java or Spring should automatically be used for every problem.
The technology should fit the problem.
That idea connects directly to one of his broader principles:
follow the problem, not a fixed stack.
AI Should Extend Thinking, Not Replace It
Nocklock's approach to AI is deliberately different from simply asking an AI model to write everything.
His first step isn't:
“Write this for me.”
Instead, he tries to explain what he's curious about, why he's curious about it, and how he thinks the pieces might connect.
Then he asks AI to help explain the subject.
Only after understanding the direction does he use AI for implementation, code review, identifying mistakes or suggesting improvements.
That distinction matters to him.
AI can provide an enormous amount of knowledge.
Its ability to interact with tools and take action is also growing quickly.
But Nocklock wants the important questions, judgment and decisions to remain his responsibility.
The ideal relationship isn't human versus AI.
It's human thinking enhanced by AI.
AI becomes a multiplier for understanding rather than a substitute for understanding.
Following the Problem Instead of the Stack
Nocklock doesn't want technology to be the starting point of a project.
He starts with the problem.
What is being built?
How quickly does it need to be built?
What constraints exist?
What can realistically be maintained?
What can be verified?
Sometimes Java and Spring are the right choice because they are familiar and fit the requirements.
Sometimes another technology is better.
AI has made experimenting with unfamiliar technologies easier, but that doesn't mean every new technology deserves to be added to a project.
In fact, sometimes following the problem means deliberately choosing something familiar and boring.
That's an important distinction.
Being flexible doesn't mean constantly chasing new technology.
It means choosing technology based on what the problem actually requires.
The Cost of Moving Too Fast
One mistake Nocklock continues to notice in himself is focusing heavily on implementation and assuming the structure can always be cleaned up later.
Security Lens made this particularly obvious.
Because of the competition deadline, he often solved the next problem in front of him and moved on.
That approach helped maintain momentum.
But later, while documenting the project, he could see where the structure had become messy.
He could also see that some features probably didn't need to exist.
The lesson wasn't that moving quickly was wrong.
It was that speed doesn't remove the cost of decisions.
It simply delays when you see that cost.
Today, Nocklock tries to create small moments during development where he can step outside the code and ask:
Does what I'm building still make sense?
That pause can prevent a lot of future cleanup.
What He's Exploring Next
Nocklock's interests are increasingly moving toward the intersection of:
Backend development.
AI.
Security.
Real products.
Security Lens began as a tool for detecting privacy risks in files before they are uploaded.
Working on it opened up broader questions about digital content.
How do we know whether an image or piece of content is authentic?
Where did it come from?
Was it generated or modified by AI?
Can AI-generated media be used to imitate another person?
These questions have made areas such as content provenance and identity risk particularly interesting to him.
At the same time, he remains interested in building smaller experimental products.
The goal is to test an idea quickly, receive real feedback and then decide whether the idea deserves further investment.
Build Something Smaller
When asked what advice he would give other developers, Nocklock's answer is straightforward:
Build something smaller than the thing you originally wanted to build.
It's easy to remain in preparation mode.
There is always another:
- Course
- Framework
- Tutorial
- Concept
- Technology
that could be learned first.
But developers don't need to understand everything before starting.
Build something small enough to finish.
Let it break.
Deploy it.
Let another person use it.
Then examine what goes wrong.
Those problems will often tell you what you genuinely need to learn next.
For Nocklock, one real error that requires investigation can teach more than memorizing ten definitions.
Experience creates context.
Context makes knowledge stick.
Becoming More Than a Framework Developer
Nocklock doesn't want to become a developer defined by a single framework.
Java and Spring are an important foundation, but his longer-term goal is broader.
He wants to become someone who can move comfortably between:
- Engineering
- AI
- Product thinking
- Deployment
- Problem solving
- Communication
He wants to understand a problem, choose appropriate tools, build the system, deploy it, explain it clearly and improve it based on what actually happens.
In other words:
Not simply someone who writes code.
Someone who can take an idea and keep working on it until it becomes something another person can actually use.
From Writing Stories to Building Systems
There is an interesting connection running through Nocklock's entire journey.
Before software, there was storytelling.
He created fictional worlds, defined their rules and imagined what could happen inside them.
Then came programming.
Different syntax.
Different constraints.
Different tools.
But a surprisingly similar creative process.
Software also involves defining rules, creating systems and imagining what happens when different pieces interact.
Today, AI adds another layer to that process.
It can help him explore unfamiliar concepts, test ideas and move faster.
But he still wants to be the person asking the questions.
The person deciding what matters.
The person choosing what to build.
And ultimately, the person responsible for shipping it.
Knowing What Not to Build
When Nocklock first started programming, he thought becoming a better developer mostly meant knowing more.
More syntax.
More frameworks.
More technologies.
His perspective has changed.
Technical knowledge still matters.
But software development is also about understanding the problem, questioning assumptions, debugging beyond the code, communicating decisions, working within constraints and actually shipping something people can use.
He has also learned that knowing what not to build can be just as important as knowing how to build something.
Code remains at the center of the work.
But it isn't the whole job anymore.
The Developer Journey Continues
Nocklock's journey began with a practical career decision.
It developed through Java and Spring.
It was shaped by an earlier life as a published web novelist.
It accelerated through learning by shipping.
Security Lens taught him the difference between building an MVP and actually shipping a product.
Documentation taught him to question his own decisions.
Deployment taught him that the environment is part of the system.
AI taught him another way to learn and work.
And his current interests are taking him toward the intersection of backend engineering, AI, security and real-world products.
His philosophy can be summed up simply:
Start with the problem.
Build something small.
Let reality test it.
Learn from what breaks.
Ship it.
Then do it again.
About Nocklock
Nocklock is a developer building useful things with Java, Spring and AI.
His approach centers on learning by shipping, documenting what works and following the problem rather than committing to a fixed technology stack.
His current interests include backend development, AI, security, content provenance and experimental product development.
View Nocklock's profile on CoderLegion
Visit Nocklock's website
CoderLegion Developer Stories
Real developers. Real journeys. Real experiences.
Developer Stories at CoderLegion gives developers a place to share how they think, what they build, the problems they encounter and what they learn along the way.
Interview & Story by Mehadi Hasan
