DEV Community: nocklock

Git on a New Windows PC: init vs clone, origin, -M, -u, and Your First Push

nocklock — Sun, 04 Oct 2026 23:12:05 +0000

I recently set up Git again on a new Windows laptop.

Installing Git itself wasn't difficult.

What was more interesting was seeing commands I had used many times before as if I were looking at them for the first time again.

git config
git init
git remote
git branch -M main
git push -u origin main

I knew how to use them.

But while setting up a new machine, I caught myself asking:

Why am I setting user.name and user.email again?

What's the actual difference between git init and git clone?

What exactly is origin?

And what do -M and -u actually mean?

So instead of just copying the commands and moving on, I went through the flow again.

This is the version I wish I had when I first started using Git.

1. First, make sure Git is actually installed

After installing Git on Windows, I start with:

git --version

If Git is available from the terminal, you should see the installed version.

Simple, but I like checking the command itself instead of assuming the installer finished everything correctly.

2. Configure your Git identity

On a new machine, Git does not automatically know who should be recorded as the author of your commits.

Set your name:

git config --global user.name "Your Name"

And your email:

git config --global user.email "you@example.com"

You can check them again with:

git config --global user.name
git config --global user.email

Or inspect the configuration:

git config --list

One thing that confused me when I first learned Git was thinking this was basically my GitHub login.

It isn't.

These values are used as author information for commits.

If Git does not know your identity when it needs to create a commit, you may run into messages like:

Please tell me who you are.

or:

fatal: unable to auto-detect email address

So on a new development machine, this is one of the first Git settings I check.

3. `git init` vs `git clone`

These two commands are easy to mix together at first because both can be part of "starting a Git project."

But they start from different situations.

You already have a project on your computer

If you have a local folder and want Git to start tracking it:

git init

This initializes a Git repository inside the current directory.

I think of it as:

I already have this folder.
Now I want Git to manage it.

The repository already exists remotely

If the project is already on GitHub or another Git server:

git clone <repository-url>

For example:

git clone https://github.com/example/project.git

This downloads the existing repository and its Git history.

So the simple version is:

Existing local project
→ git init

Existing remote repository
→ git clone

You normally do not need to run git init before cloning an existing repository.

4. Add your files and create the first commit

After initializing a local repository, I usually check its current state first.

git status

Then stage the files:

git add .

And create a commit:

git commit -m "Initial commit"

At this point, the commit exists in the local Git repository.

It is not on GitHub yet.

That distinction is important.

git commit
→ records the change locally

git push
→ sends commits to a remote repository

5. What does `origin` actually mean?

After creating a repository on GitHub, you can connect the local repository to it.

git remote add origin <repository-url>

For example:

git remote add origin https://github.com/example/project.git

When I first used Git, origin felt like some special Git keyword.

It isn't.

origin is simply the conventional name Git uses for a remote repository.

You could technically give the remote another name.

But origin is the standard name you will see almost everywhere.

You can check the configured remotes with:

git remote -v

So when you later run:

git push origin main

you can roughly read it as:

push
my main branch
to the remote repository named origin

That mental model made the command much easier to remember.

6. What does `git branch -M main` mean?

GitHub often shows this command when connecting a new local repository:

git branch -M main

The important parts are:

main
→ the branch name

-M
→ rename the branch, forcing the rename if necessary

So this command renames the current branch to main.

The uppercase -M is effectively the force version of the branch rename option.

For most new repositories, the practical thing to remember is simply:

git branch -M main

means:

Make the current branch name main.

7. What does `-u` mean in `git push -u origin main`?

Now comes the command I had typed many times without really thinking about every part of it:

git push -u origin main

We already know:

origin
→ the remote repository

main
→ the branch being pushed

So what does -u do?

-u is shorthand for:

--set-upstream

It connects your local branch with the corresponding remote branch as its upstream tracking branch.

After that first push, you can usually use:

git push

instead of:

git push origin main

And similarly:

git pull

can use the configured upstream relationship.

So I now think of:

git push -u origin main

as:

Push main to origin,
and remember that relationship for later.

That is much easier to remember than treating -u as a mysterious flag.

8. The full flow from a local project to GitHub

For a new local project, the basic flow looks like this:

git init

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

git add .
git commit -m "Initial commit"

git remote add origin <repository-url>

git branch -M main

git push -u origin main

After the upstream relationship is configured, the normal daily flow becomes much shorter.

git status
git add .
git commit -m "Describe the change"
git push

That is the part I actually use all the time.

What changed for me after setting Git up again

None of these commands were new to me.

I had used Git for years.

But a development machine that has been configured for a long time hides a lot of setup.

On my old machine, Git already knew my identity.

The repositories already had remotes.

The branches already tracked their upstream branches.

I could just open a project and start working.

A new laptop removes all of those assumptions.

And once I had to configure them again, commands like:

git config
git init
origin
-M
-u

stopped looking like one long setup recipe.

I could see what each step was actually doing.

I still don't think every Git option needs to be memorized.

But knowing whether a command is:

creating a local repository
recording a commit
connecting a remote
renaming a branch
or pushing code

makes Git much less confusing when something goes wrong.

One thing I would not do

When a Git command fails, I try not to immediately paste a force command from the first search result.

Commands such as:

git push --force

or destructive reset options can change history or discard work.

Before using them, I want to understand why Git is refusing the operation.

That is especially true once other people are working on the same repository.

After the first push

Getting the repository onto GitHub is only the beginning.

The next confusing Git questions tend to be things like:

What is the difference between git fetch and git pull?
Why was my push rejected as non-fast-forward?
What does detached HEAD actually mean?
When should I use revert, reset, or restore?

Those deserve their own explanations rather than being squeezed into a first-push guide.

Shipping the project after Git is ready

Getting your code into Git is one step.

Shipping a Spring Boot project is another.

I put the basic version of my release workflow here:

Ship Your Spring Boot MVP — Free Edition

Get the free Spring Boot MVP checklist on GitHub

If you want the complete checklist and release workflow:

Ship Your Spring Boot MVP — Full Edition

Get the Full Edition

If I had to keep only one mental model from this setup, it would be this:

init starts local Git.

commit records locally.

remote connects somewhere else.

push sends commits there.

The flags are much easier to remember once the flow itself makes sense.

IntelliJ Java Version Mismatch: Project SDK, Gradle JVM, and JAVA_HOME Explained

nocklock — Sun, 04 Oct 2026 23:07:51 +0000

IntelliJ Java Version Mismatch: Project SDK, Gradle JVM, and JAVA_HOME Explained

I recently set up a new development laptop from scratch.

JDK 17 was installed.

The terminal looked fine.

java -version

It returned the version I expected.

That should mean my Java environment is ready, right?

Not necessarily.

While setting up IntelliJ again, I was reminded of something that is easy to forget once a development machine has been configured for years:

The Java version shown in your terminal is not always the Java version IntelliJ or Gradle is actually using.

There are several places where Java versions can be configured, and they do not automatically mean the same thing.

1. Start with the Java version your terminal is using

The first thing I check is still the simplest one.

java -version

I also check the compiler version.

javac -version

On Windows, you can also inspect JAVA_HOME.

Command Prompt

echo %JAVA_HOME%

PowerShell

$env:JAVA_HOME

And if multiple JDKs have been installed before, it is useful to check which Java executable is actually being resolved.

Command Prompt

where java

PowerShell

Get-Command java

This tells you what your terminal sees.

But this is only the first layer.

2. Check IntelliJ Project SDK

In IntelliJ IDEA, check:

File
→ Project Structure
→ Project
→ SDK

This is the JDK configured for the project inside IntelliJ.

A common assumption is:

java -version = 17

therefore:

IntelliJ Project SDK = 17

But those are separate settings.

Your system may use one JDK while IntelliJ points to another.

That is why checking only the terminal can be misleading.

3. Do not forget the Gradle JVM

For Gradle projects, there is another setting that is easy to overlook.

Settings
→ Build, Execution, Deployment
→ Build Tools
→ Gradle
→ Gradle JVM

The important distinction is:

Project SDK
→ JDK configured for the IntelliJ project

Gradle JVM
→ JVM used to run Gradle

So this configuration is completely possible:

System Java: 17
Project SDK: 17
Gradle JVM: 11

At first glance, everything looks like a Java 17 project.

Then the Gradle build starts behaving differently.

That is usually the point where the setup becomes confusing.

Project SDK and Gradle JVM are related, but they are not the same setting.

4. Check what Gradle is actually running with

If the project uses the Gradle Wrapper, you can check it directly.

Command Prompt

gradlew.bat --version

PowerShell

.\gradlew.bat --version

The output includes the JVM Gradle is running with.

This is useful when IntelliJ looks correct but the build is still complaining about Java versions.

Instead of changing random settings, you can verify which JVM each layer is actually using.

5. Your project may define its own Java requirement

The project itself can also specify the Java version.

For example, using a Gradle Java Toolchain:

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

Older or existing projects may also contain something like:

sourceCompatibility = '17'

The exact configuration varies between projects.

The important point is that your machine configuration is not the only thing that matters.

The project may have its own Java requirement too.

Why Java version problems become confusing

The problem is not simply "Java 17 vs Java 21."

The confusing part is that Java can appear in several places:

Windows Java
     ↓
JAVA_HOME / PATH

IntelliJ
     ↓
Project SDK

Gradle
     ↓
Gradle JVM

Project
     ↓
build.gradle / toolchain

These settings are related.

But they are not identical.

That is the part I had almost stopped thinking about because my previous development machine had already been configured for years.

On a new laptop, all of those invisible assumptions become visible again.

When I see a Java version error, this is what I check first

Situation	First things to check
Terminal and IntelliJ show different Java versions	`JAVA_HOME`, `PATH`, Project SDK
Gradle build complains about Java version	Gradle JVM, `gradlew --version`
`invalid source release`	Project SDK, Gradle JVM, project Java configuration
A dependency requires a newer JVM	Gradle JVM and runtime JVM
Project worked on the old machine but not the new one	JDK, environment variables, Gradle JVM, project configuration

The exact error may be different.

But checking which layer is actually using which Java version is usually more useful than immediately copying the first fix from a search result.

The setup order I use on a new machine

For my new laptop, I kept it simple:

Install JDK
↓
Check java -version
↓
Install IntelliJ
↓
Check Project SDK
↓
Check Gradle JVM
↓
Run an existing project

That last step matters the most.

A development environment is not really finished just because the IDE opens.

For me, it is finished when an existing project can build and run again.

Setting up a new machine reminded me that many things we think of as "automatic" are really just configuration that was done a long time ago.

Once you rebuild everything from zero, you start seeing those dependencies again.

And Java version configuration is a good example.

Shipping the project after the environment works

Getting the environment running is only the first step.

Actually shipping a Spring Boot project comes with a different set of checks:

configuration
deployment
verification
release decisions

I put the basic version of that workflow here:

Ship Your Spring Boot MVP — Free Edition

Get the free Spring Boot MVP checklist on GitHub

If you want the full checklist and release workflow:

Ship Your Spring Boot MVP — Full Edition

Get the Full Edition

If you're setting up Java on a new machine, the main thing I would remember is this:

Don't ask only, "Which Java version did I install?"

Ask, "Which Java version is each part of my development environment actually using?"

That question usually makes the problem much easier to trace.

AI Wasn't the Beginning. We Had Already Started Outsourcing Parts of Ourselves to Smartphones

nocklock — Sat, 03 Oct 2026 05:49:53 +0000

People worry that we're becoming too dependent on AI.

It writes for us.

Searches for us.

Helps us code.

And increasingly, we ask it what we should do next.

I understand the concern.

I think about it too.

But recently I started wondering:

Did this really begin with AI?

The more I thought about it, the less it seemed that way.

We've been outsourcing small parts of ourselves to technology for a long time.

AI is just making it much easier to notice.

I used to memorize phone numbers

When I was younger, I knew several phone numbers by memory.

Family.

Friends.

Sometimes even friends' home numbers.

You needed to know the number if you wanted to call someone.

I barely do that anymore.

I search for a name and tap it.

The phone remembers for me.

And honestly, this doesn't feel like a loss most of the time.

It's convenient.

There is very little reason for me to store dozens of phone numbers in my head when a device can do it better.

So I stopped.

Not because someone forced me to.

Because the technology made remembering unnecessary.

I stopped memorizing routes too

Something similar happened with navigation.

If I visited the same place often enough, I used to remember the route.

Which station.

Which street.

Which building meant I needed to turn.

Today, I can visit somewhere completely unfamiliar without thinking much about it.

I open a map.

If I take the wrong turn, it recalculates.

If traffic changes, it finds another route.

Again, this is better in almost every practical way.

I don't want to go back.

But there is a difference between:

I know how to get there.

and:

My phone knows how to get there.

I notice that difference whenever my battery gets low in an unfamiliar place.

Discovery changed too

Restaurants are another example.

There was a time when finding a place meant remembering somewhere you'd visited, hearing about it from someone, or just walking past it.

Now I usually search first.

Ratings.

Reviews.

Photos.

Maps.

Social media.

Recommendation algorithms.

The chance of making a bad choice goes down.

But something else goes down too:

the number of times I discover something without already knowing that other people liked it.

Technology didn't remove choice.

It changed how I arrive at the choice.

Then AI arrived

Contacts remember phone numbers.

GPS remembers routes.

Search engines retrieve information.

Recommendation systems decide what might be worth our attention.

Now generative AI is moving into a slightly different layer.

It doesn't just remember or retrieve.

It participates in the process of thinking.

How should I structure this?

What am I missing?

How could I implement this?

What are the alternatives?

That might be why AI feels different.

Previous tools outsourced pieces of memory and navigation.

AI can outsource pieces of reasoning.

I'm not arguing that we should stop using it

I use AI constantly.

I use it while developing.

I use it to explore ideas.

I use it to find gaps in my own thinking.

I use it when writing.

I'm not interested in pretending that avoiding useful tools somehow makes the work more authentic.

I don't carry a paper map just to prove I can navigate without GPS.

But I do think there is a useful question hidden underneath all of this:

What do I still want to keep as mine?

I don't care that I can't remember everyone's phone number.

I don't care that Google Maps remembers streets better than I do.

But I do care whether I can explain why I made a decision.

I care whether I understand the code I'm shipping.

I care whether an opinion is actually mine or something I accepted because a system gave me a convincing answer.

Convenience has always had a trade

Smartphones didn't suddenly make us incapable.

They made certain abilities less necessary.

And when an ability becomes unnecessary often enough, we naturally practice it less.

AI may be another step in the same direction.

Only this time the thing becoming less necessary might not be remembering a number or memorizing a route.

It might be parts of the thinking process itself.

That doesn't automatically make AI bad.

But it does make the boundary worth noticing.

Technology rarely arrives and says:

Give me this part of yourself.

It gives us something useful.

Something convenient.

Something we quickly stop wanting to live without.

And little by little, we decide what we no longer need to do ourselves.

So when people ask whether AI is making us too dependent on technology, I'm starting to think the answer didn't begin with ChatGPT.

AI wasn't the beginning.

We've been making this trade for a long time.

I Set Up a New Windows Laptop for Java and Spring Boot. Here’s What I Checked First.

nocklock — Sat, 03 Oct 2026 05:38:13 +0000

I recently got a new LG gram Pro 17.

My first reaction had almost nothing to do with development.

How is a 17-inch laptop this light?

The screen felt huge compared to what I was used to, and the laptop looked great on my desk.

For the first few minutes, I was mostly just enjoying the fact that a 17-inch machine didn't really feel like one.

But after that came the less exciting part.

I had to rebuild my development environment.

That reminded me of something I rarely think about on my old machine:

A lot of my development setup only feels simple because it has already been configured for years.

On the old computer, Java was there.

Git was there.

IntelliJ already knew my projects.

Dependencies had already been downloaded, and environment settings existed somewhere.

I could just open a project and start working.

A new laptop removes all of that.

So instead of treating this as a list of programs to install, I used one simple condition to decide when the setup was actually finished:

Can I take an existing Spring Boot project and run it on this machine?

I started with Windows, not IntelliJ

My first instinct was to install IntelliJ immediately.

I didn't.

Since this was a completely new Windows machine, I first finished the basic system updates.

My rough order was:

Windows Update
LG driver updates
Reboot
Check for updates again

Nothing interesting here.

But I wanted the machine itself to be stable before adding my development tools on top of it.

It also makes troubleshooting easier later.

If something goes wrong, I would rather not wonder whether it came from a driver update, a Windows restart, or something I had just changed in my Java environment.

Then Java

Most of the Spring projects I work with are based on Java 17, so I installed JDK 17 and checked it from the terminal first.

java -version

This is simple, but I like checking the runtime outside the IDE before doing anything else.

If Java itself isn't where I expect it to be, there isn't much point debugging IntelliJ yet.

I also checked the environment variables and made sure the machine was actually using the JDK version I wanted.

One thing worth remembering is:

Java being installed on Windows does not automatically mean your IDE or project is using the same JDK.

That becomes important a few steps later.

Git came next

After Java, I installed Git.

Again, I checked it from the terminal.

git --version

The point wasn't just to make git available.

I wanted to bring an existing repository onto the new machine instead of creating a clean demo project.

A new sample project can hide problems.

An old project usually doesn't.

It already has dependencies, configuration, build scripts, and assumptions that have accumulated over time.

That made it a much better test for the new environment.

Then IntelliJ

After installing IntelliJ, one of the first things I checked was the Project SDK.

This is the kind of setting I barely notice on a machine I've used for a long time.

On a fresh install, it matters immediately.

Windows may know about Java 17 while IntelliJ is still pointing somewhere else.

So before changing plugins, themes, keymaps, or anything else, I made sure the project itself was using the right JDK.

I also had to give IntelliJ time to do what IntelliJ does on a new project:

indexing
resolving dependencies
loading the project structure

For a moment, some things didn't behave exactly the way I expected.

My first instinct was to start changing settings.

Then the project finished loading.

Things started behaving normally again.

That was another small reminder that not every strange thing on a fresh machine is a configuration problem.

Sometimes the IDE is simply still working.

The real test was Spring Boot

At this point I had:

JDK installed
Git installed
IntelliJ installed
my repository cloned

That still wasn't enough.

The real question was:

Does the project run?

I opened an existing Spring Boot application, let the dependencies resolve, built it, and started the application.

When the server came up normally, that was the moment I considered the basic environment ready.

Not when IntelliJ opened.

Not when java -version worked.

Not when Git cloned the repository.

When the application actually ran.

Because a real project depends on more than an IDE.

There can be build dependencies, environment variables, database settings, local files, ports, or configurations you stopped noticing a long time ago.

A new machine has a nice way of exposing them.

A fresh laptop exposes hidden state

Nothing I did here was technically advanced.

I've installed Java before.

I've installed Git before.

I've configured IntelliJ before.

I've run Spring Boot applications many times.

But doing it again from zero made the existing environment look different.

On my previous machine, years of configuration had become invisible.

Everything simply worked because I had already solved those problems sometime in the past.

A fresh machine removes that hidden state.

And that makes a useful question easier to ask:

How reproducible is my development environment?

I don't mean that every developer needs a fully automated local setup.

But if I can't explain what a project needs to run on another machine, there are probably dependencies I don't understand as well as I think I do.

That feels very similar to deployment.

A project working on my laptop is one thing.

Being able to reproduce the environment somewhere else is another.

This is also where shipping starts to feel different from coding

I've run into a similar problem while building small Spring Boot projects.

The main feature works.

The API responds.

The application runs locally.

At that point, it is easy to feel like the project is almost done.

Then you try to move it outside your machine.

Ports matter.

Environment variables matter.

Configuration matters.

Deployment exposes assumptions that localhost was quietly hiding.

I ended up turning the checklist I was using for that process into a small guide.

Ship Your Spring Boot MVP

It's a practical checklist for checking a Spring Boot MVP before calling it ready to ship.

It focuses less on writing another feature and more on things like:

build verification
configuration
environment variables
deployment checks
evidence that the application actually works outside your local setup

👉 Check out Ship Your Spring Boot MVP

I made it after realizing that getting an MVP to work and getting it ready to leave my machine were two different skills.

About the LG gram Pro 17

I'm still too early into using this laptop to call this a proper developer review.

The model I'm using has a Core Ultra 7 and 32GB of RAM, and my first impression of the 17-inch screen and weight is very positive.

But I haven't spent enough time yet running my normal workload.

I still want to see what happens when I have:

IntelliJ
Spring Boot
Docker
a database
browser tabs
documentation
the rest of my usual tools

running together for hours.

I also want to watch battery life and thermals during real development instead of judging them from the first day.

So for now, I'm separating two things:

The laptop's first impression: very good.

A proper development performance review: not yet.

I'll write that after I've actually used it enough to have something useful to say.

What I'm testing next

The basic Java/Spring Boot environment is ready.

Next I'll use the laptop the way I normally work:

IntelliJ, Spring Boot, Docker, DB, browser tabs, documentation, and probably too many windows open at once.

That's also why I chose 32GB of RAM this time.

Not because Java suddenly requires 32GB.

Mostly because I don't want to think about memory every time my development environment gets busy.

That's another topic I'm testing separately.

For now, I'm just glad the old project runs on the new machine.

The laptop was new.

The code wasn't.

But setting everything up again made the old project look a little different.

AI Made Me Faster. It Also Exposed What I Didn't Understand

nocklock — Fri, 02 Oct 2026 12:55:04 +0000

There was a point while building Security Lens when I realized I was fixing problems faster than I could explain them.

The error disappeared.

The application started.

Deployment worked.

Great.

Then I looked at the configuration I had just changed and thought:

Wait. Why did that actually work?

That happened more than once.

AI helped me move faster while building the project. So did documentation, Stack Overflow, GitHub issues, and a lot of searching.

But the faster I could get an answer, the easier it became to accept a working fix before I had built a mental model of what was happening.

A few small configuration problems made that painfully obvious.

1. `server.port=${PORT:8080}`

I used this while deploying my Spring Boot application to Railway.

server.port=${PORT:8080}

At first, my understanding was basically:

Railway needs this.

I changed the configuration.

The server started.

Problem solved.

Except I couldn't really explain the line.

What is PORT?

Who sets it?

Why is 8080 still there?

Why does the same application use 8080 locally but something else after deployment?

Once I stopped treating the line as magic, it became much simpler.

PORT is an environment variable.

Railway provides a port to the running application.

Spring Boot reads that value.

If PORT is not available, 8080 becomes the fallback.

So on my local machine:

PORT does not exist
        ↓
Spring Boot uses 8080

On Railway:

Railway provides PORT
        ↓
Spring Boot uses that value

The configuration wasn't really about Railway.

It was about letting the environment decide something that should not be hardcoded.

That was a much more useful thing to understand.

2. `8081:8080` was not just two random ports

Docker gave me a similar moment.

I was running something like:

docker run -p 8081:8080 ...

Two ports.

Both looked like ports.

I knew the command worked.

But for a while my knowledge was basically:

Use this and the container becomes accessible.

That wasn't enough.

The first port belongs to the host.

The second belongs to the container.

localhost:8081
      ↓
Host port 8081
      ↓
Container port 8080
      ↓
Spring Boot application

So:

8081:8080
HOST:CONTAINER

Once I understood that, another thing started making more sense.

localhost is not one universal place.

localhost from my PC means my PC.

localhost from inside a container means that container.

That sounds obvious after you understand it.

It was not obvious when I was simply copying commands until something connected.

3. Ollama wasn't broken. Port 11434 was already being used.

Another time, I tried to run:

ollama serve

and got an error because port 11434 was already in use.

My first reaction was basically:

Why isn't Ollama starting?

So I restarted things.

Tried the command again.

Still failed.

Eventually the more useful question became:

What is already using port 11434?

That changed the way I looked at the problem.

Ollama normally runs its local server on port 11434.

If something is already listening there, another process cannot simply bind to the same address and port.

The problem was not necessarily:

Ollama is broken

It was:

Process A
    ↓
already owns :11434

Process B
    ↓
tries to use :11434

    ↓

conflict

The error message had been telling me something fairly specific.

I just wasn't reading it at the right level yet.

4. Environment variables were not just a deployment trick

The same thing happened when I started handling API keys.

Putting a value directly into application.properties is easy.

It also works.

Something like this is much better:

openai.api.key=${OPENAI_API_KEY}

Initially, I thought of environment variables mostly as another thing I needed for deployment.

Then I realized several concerns were connected here.

The application needs configuration.

Different environments may need different values.

Secrets should not be committed to the repository.

And the source code should not need to change just because the application moves from my machine to another environment.

So this:

Application code
+
Environment-specific configuration

started making much more sense than:

Application code
+
Whatever values happen to be hardcoded on my machine

Again, the syntax itself wasn't difficult.

The part I had been missing was the reason the boundary existed.

AI made this pattern easier to notice

AI was genuinely useful during all of this.

I could paste an error.

Ask what was wrong.

Get a configuration example.

Change the code.

Try again.

That made development much faster.

But it also created an interesting problem.

Sometimes the answer arrived before the understanding did.

There is a big difference between:

I have a fix.

and:

I understand what changed.

AI made the first one much faster.

It did not automatically give me the second one.

I still had to trace the environment, the process, the port, the configuration source, or the network boundary myself.

And I don't think the solution is to stop using AI.

I definitely don't want to go back to doing everything slowly just to prove that I can.

Instead, I'm trying to add one small step after certain fixes.

When something starts working, I ask:

Who provided this value?

Which environment does this address or port belong to?

What exactly would break if I removed this configuration?

I don't do this for every error.

Sometimes I just need to fix something and keep building.

But if the same concept keeps appearing — ports, environment variables, localhost, processes, configuration — I try not to leave it at:

It works now.

Writing about the problem exposed the gap

The funny thing is that I noticed many of these gaps while writing development notes.

While coding, this felt sufficient:

Error
↓
Search
↓
Change configuration
↓
Works
↓
Next

Writing about it forced me into another step:

Error
↓
Search
↓
Change configuration
↓
Works
↓
Why?

That's where I realized I couldn't clearly explain some of the fixes I had already used.

So I went back.

I looked at how Railway provides its port.

I looked again at Docker port mapping.

I checked which process was using 11434.

I thought more carefully about why configuration and secrets were coming from the environment.

None of these were huge discoveries.

But they started connecting.

And that connection feels more valuable than memorizing another command.

This happened while I was building Security Lens

Most of these examples came from building and deploying Security Lens, a Spring Boot project that analyzes images and documents for privacy risks using OCR, EXIF metadata, rule-based detection, and an AI-assisted explanation layer.

The project gave me a reason to touch deployment, containers, external services, configuration, and AI integration in one place.

Apparently it also gave me several opportunities to discover things I thought I understood.

I documented the architecture, implementation decisions, and what I learned in the public case study:

-> Security Lens — Technical Case Study on GitHub

AI is still making me faster.

I just don't want to confuse faster problem solving with deeper understanding.

For now, when an error disappears, I'm trying to leave myself one last question:

Why did it disappear?

I Used to Think Getting Better at Coding Meant Writing More Code

nocklock — Thu, 24 Sep 2026 23:47:34 +0000

For a long time, I thought becoming a better developer mostly meant knowing more things.

More Java.

More Spring.

More libraries.

More tools.

So whenever I felt like I wasn't improving fast enough, my answer was usually the same.

I needed to study something new.

Lately, I'm starting to think I had the wrong measurement.

I used to care mostly about whether the code worked

When I was building something, getting the feature to work felt like the finish line.

The API returned the response I expected.

The button worked.

The data showed up on the screen.

No errors in the console.

Good.

Next feature.

I don't think that way was necessarily wrong.

When you're trying to build something, you need to make things work.

But while building my recent project, Security Lens, I started noticing something.

The questions I was asking had changed.

Instead of only asking:

Does this work?

I started asking:

Why does this work?

And sometimes:

Where will this stop working?

That second question has caused me a lot more trouble.

But I think it has also taught me more.

Deployment made this painfully obvious

I've written about this a few times recently because deployment exposed a lot of assumptions I didn't know I had.

My Spring Boot application worked locally.

Then I tried to move it outside my machine.

Suddenly, things I barely thought about became important.

Ports.

Environment variables.

External services.

Configuration.

Build behavior.

All the little differences between localhost and a real deployment.

At first, each one just looked like another problem to fix.

Fix the port.

Fix the configuration.

Deploy again.

But after doing this repeatedly, I noticed my behavior changing.

Now when something works locally, I'm less likely to immediately think:

Done.

I start wondering what made it work.

Is there a local configuration I'm depending on?

Is something running on my machine that I forgot about?

Would another person be able to run this project?

What happens if the environment changes?

I definitely didn't ask all of those questions before.

I also started reading errors differently

This one is harder to measure.

Before, when I saw an error, my instinct was often to get rid of it as quickly as possible.

Search the message.

Find a similar problem.

Try the solution.

If it works, move on.

I still search error messages, of course.

Probably always will.

But now I try to spend a little more time understanding what the error is actually telling me.

Not because I've suddenly become extremely disciplined.

Mostly because I've learned that fixing something without understanding it has a strange habit of bringing the problem back later.

Sometimes in a slightly different form.

And usually when I don't want it to.

Even README files started looking different

I used to think of documentation as something you wrote after development.

The code was the real work.

The README explained the real work.

That changed when I tried to write a README that someone else could actually use.

I had to explain how the application starts.

What configuration it needs.

What services it depends on.

What someone needs before running it.

And while writing those things down, I found assumptions in my own project.

Things that were obvious to me only because I had built it.

That was uncomfortable.

But useful.

Documentation wasn't just explaining my code anymore.

It was testing whether I actually understood the environment around my code.

The strange part is that I'm writing less code sometimes

This is probably the biggest change.

There are moments now when I spend more time checking logs, reading documentation, looking at configuration, or trying to understand a failure than actually typing code.

A few years ago, that probably would have made me feel like I wasn't really developing.

Now I'm not so sure.

Writing code is obviously part of being a developer.

But maybe the job isn't measured by how much code I can produce.

Maybe it's also about how many assumptions I can notice before they become someone else's problem.

I'm still learning this.

And I still have plenty of moments where I change something, see that it works, and think:

Great. Don't touch it.

So I'm definitely not claiming some dramatic transformation here.

But something has changed.

My questions are different now

I don't know if I'm a better developer than I was a few months ago.

That's difficult to measure from inside your own head.

I still get stuck.

I still search things that I feel like I should already know.

I still break things.

But the questions I ask while coding are definitely different.

It used to be:

How do I make this work?

Now, more often, it's:

Why does this work?

What am I assuming?

What happens when the environment changes?

Could someone other than me run this?

Maybe getting better at development isn't always about knowing more answers.

Sometimes it's noticing that you're starting to ask better questions.

And lately, that feels more like progress to me.

15 Things I Check Before Shipping a Spring Boot MVP

nocklock — Thu, 24 Sep 2026 05:53:43 +0000

I used to think an MVP was almost finished when the main feature worked.

The API responded.

The UI did what I wanted.

The application started without errors.

On localhost, everything looked fine.

Then I tried to deploy it.

That was when I realized I had been checking whether my application worked, not whether it was actually ready to leave my machine.

Ports behaved differently.

Environment variables mattered.

A service I had casually called through localhost suddenly didn't exist anymore.

Something could deploy successfully and still not be usable.

That experience changed the way I look at the last part of an MVP.

Now, before I consider a Spring Boot project ready to ship, these are the things I check.

Does the project build from a clean state?

This sounds obvious.

But during development, an IDE can hide a surprising amount of context.

Cached dependencies, local configuration files, already-running services, and files that were never committed can all make a project look healthier than it really is.

Before shipping, I want this to work without relying on my current IDE session.

./gradlew clean build

If the clean build fails, deployment is not my first problem yet.

Are the tests actually running?

A green build doesn't mean much if the tests I expected were never executed.

I check the test output instead of only looking at:

BUILD SUCCESSFUL

For a small MVP, I may not have a huge test suite.

That's fine.

But I still want to know exactly what was tested and what was not.

Can the application start without my IDE?

This was one of those things I underestimated.

During development, pressing the Run button in IntelliJ becomes normal.

Production doesn't have an IntelliJ Run button.

So I try starting the built application directly.

java -jar build/libs/app.jar

This often reveals configuration assumptions that were invisible during normal development.

Is anything hardcoded to localhost?

This one hit me directly.

Locally, code like this feels completely normal:

http://localhost:11434

or:

http://localhost:8080

But localhost always means:

this machine

Once the application moves to another environment, "this machine" is no longer my laptop.

That sounds obvious now.

It wasn't always obvious while I was building.

So before deployment, I search the project for things like:

localhost
127.0.0.1

and ask whether each one still makes sense outside my development machine.

Is the application port configurable?

Locally, I normally used a fixed Spring Boot port.

Then deployment platforms forced me to think differently.

Instead of assuming:

server.port=8080

I prefer something like:

server.port=${PORT:8080}

Locally, it still runs on 8080.

In an environment like Railway, the platform can provide the actual port.

One small configuration change removed an assumption I didn't even know I had.

Are secrets outside the repository?

API keys and credentials should not live inside source code.

That includes things like:

API keys
database passwords
access tokens
private credentials

I now treat environment configuration as part of the deployment itself, not something to think about after deployment.

A project that only works because my local .env file happens to exist isn't ready yet.

Do I know every external dependency the application needs?

A Spring Boot application rarely lives alone.

Mine started depending on things outside the JVM:

a database, external APIs, AI services, storage, and other processes.

Locally, those dependencies were already there.

Production started asking a more useful question:

What does this application need in order to stay alive?

Writing those dependencies down helped more than I expected.

Can production actually reach those dependencies?

Knowing that a dependency exists isn't enough.

The deployed application also needs to reach it.

For every important dependency, I check things like:

host
port
credentials
network access
timeout
production URL

This is especially important when something worked locally because another service was running on the same machine.

Do I know what configuration is different in production?

Local and production environments are never completely identical.

The dangerous part is not that they are different.

The dangerous part is forgetting how they are different.

I want to know which values change between environments.

Not every value needs to be documented in a massive configuration system.

But I should at least know what I'm changing.

Do I know which commit is actually deployed?

This sounds boring until something breaks.

If I deploy several times while fixing an issue, I eventually need to answer:

Which version is running right now?

"I think it's the latest one" is not a great answer.

At minimum, I want the commit SHA or release point associated with the deployment.

That single piece of information makes debugging much less vague.

Does a health check pass after deployment?

A successful deployment message is useful.

But:

Deployment successful

does not mean:

Application verified

I want the running service to prove that it is alive.

Even a simple health endpoint is better than relying entirely on the deployment platform saying the container started.

Did I test the actual critical user flow?

This was another mindset change for me.

A server being alive doesn't mean the product works.

If the important flow is:

Upload
→ Analyze
→ Process
→ Return result

then I want to test that exact flow in the deployed environment.

Not only /health.

Not only the home page.

The part the user actually came for.

Do I know where the logs are?

When something fails locally, I immediately see the console.

When something fails in production, the first question becomes:

Where did the error go?

Before shipping, I now make sure I know how to find the application logs.

It sounds like a tiny operational detail.

But the first production error becomes much less stressful when I already know where to look.

Do I have a rollback point?

For my early MVPs, I mostly thought about one direction:

build → deploy → done

Now I also think about the reverse direction.

deploy → something breaks → ?

I don't need an enterprise-grade rollback system for every small MVP.

But I do want to know:

what the previous working version was
whether I can redeploy it
whether database or configuration changes prevent rollback

A release without a way back is more fragile than it needs to be.

What is still NOT VERIFIED?

This might be the most useful question on the list.

Especially when using AI.

I use AI constantly while developing now.

It helps me review code, inspect configuration, find possible deployment problems, and think through things I missed.

But I noticed a dangerous pattern.

I could ask:

Is this application production-ready?

and get a very convincing answer.

The problem is that AI can reason about the information I gave it.

It cannot magically verify a production environment it has never seen.

So I started separating these three things:

VERIFIED
INFERRED
NOT VERIFIED

For example:

Build passed
→ VERIFIED

This environment variable appears to be configured correctly
→ INFERRED

Production database connection works
→ NOT VERIFIED until tested

That distinction became much more valuable than asking for a generic "production readiness score."

Confidence is not evidence

This is probably the biggest thing I learned while turning an MVP into something I could actually deploy.

A project can feel finished.

AI can say the configuration looks good.

The deployment platform can show a green status.

None of those things automatically prove that the release works.

What I want now is evidence.

Did the build run?

Did the application start?

Did the health check pass?

Did the critical flow work?

Which commit was tested?

What still needs verification?

That is a much more useful definition of "ready" for me.

I turned this into a checklist

While working through these problems, I started writing the checks down instead of trying to remember them every time.

I eventually turned the lightweight version into a free GitHub checklist:

👉 Spring Boot Release Checklist — Free on GitHub

It includes the main release blockers and an evidence-based way to review them.

If that is enough for your project, use it.

I also made a more detailed 58-page runbook for developers who want a repeatable workflow with evidence fields, failure actions, AI review prompts, deployment checks, and rollback guidance:

👉 Ship Your Spring Boot MVP — Full 58-Page Runbook

I originally started writing all of this because my application worked perfectly on localhost.

Deployment was what showed me how many assumptions localhost had been hiding.

I Built the MVP. Then I Realized Shipping Was a Different Skill.

nocklock — Wed, 23 Sep 2026 05:14:56 +0000

I Built the MVP. Then I Realized Shipping Was a Different Skill.

A few days ago, I wrote about something I had learned the hard way:

Building the MVP first and writing the README later made me realize how much I had assumed.

I thought that was mostly a documentation problem.

It wasn't.

The deeper problem was that building something and shipping something are two different skills.

The MVP was working

I recently built Security Lens, a Spring Boot-based privacy risk analyzer for images and documents.

The basic flow was working:

Image Upload
      ↓
OCR
      ↓
Personal Information Detection
      ↓
EXIF Metadata Analysis
      ↓
Risk Scoring
      ↓
LLM-assisted Analysis
      ↓
Risk Explanation

It could detect things such as:

phone numbers
email addresses
EXIF GPS information
capture timestamps
device metadata

and turn the results into a simple privacy risk score.

At that point, I had something that worked.

I thought I was almost done.

I wasn't.

"It works" was only the beginning

Once I tried to actually ship the project, a different set of questions appeared.

Not:

Does this method work?

But:

Which exact version is deployed?

What happens if an environment variable is missing?

Did I actually verify the production configuration?

What if the database or external integration behaves differently from localhost?

What evidence do I have that the deployed application is healthy?

Can I roll back?

Those questions were not really about writing more code.

They were about operating the thing I had already written.

Deployment exposed assumptions

Localhost is forgiving.

Your machine already has:

your environment variables
your tools
your configuration
your ports
your dependencies
your development habits

Production does not care about any of that.

It only gets what you actually configured.

While working through deployment, I ran into issues around ports, environment setup, AI integration, and the difference between an implementation that works locally and one that can actually run as a product.

That changed how I looked at "done."

AI made this even more interesting

I use AI tools heavily while building.

They are extremely useful.

But I also noticed a dangerous pattern.

It is very easy to ask:

"Is this production-ready?"

and get an answer that sounds convincing.

The problem is that confidence is not evidence.

So I started using a different rule:

If the evidence is missing, the result is NOT VERIFIED.

Instead of asking AI to make the release decision for me, I ask it to help inspect:

configuration
logs
build output
deployment settings
security assumptions
missing evidence

The AI can be a reviewer.

It should not silently become the owner of the release decision.

That became a checklist

While repeatedly asking myself the same deployment questions, I started writing them down.

Eventually, those notes became a small public project:

👉 Spring Boot Release Checklist

It focuses on things like:

clean builds
expected tests
configuration and secrets
database connectivity
external integrations
production smoke tests
rollback points
evidence-first AI review

The main idea is simple:

A successful deployment is not the same as a verified release.

Then I noticed something else

The checklist helped me catch blockers.

But I still wanted a better way to answer:

What did I actually verify?

Where is the evidence?

What still remains uncertain?

Should I ship this version?

That eventually became a more structured release workflow with interactive checks, evidence fields, AI review prompts, and ship / no-ship decisions.

I ended up turning it into a 58-page deployment runbook.

That was another new experience for me.

For the first time, I was not only building software.

I was taking something I had learned while building software and turning it into something another developer could actually use.

Shipping forced me to learn things coding alone did not

The interesting part was not setting up a product page.

It was everything around it.

I had to think about:

what the product actually solves
how to explain it in one sentence
what should remain free
what someone would reasonably pay for
how a buyer receives the files
how the download flow works
what happens after payment
how the public GitHub repository connects to the full version

None of these problems required a complicated algorithm.

But they still required engineering decisions.

My definition of "done" is changing

Before:

Feature works
→ done

Now:

Feature works
→ build succeeds
→ configuration is verified
→ deploy
→ production smoke test
→ evidence recorded
→ rollback understood
→ documentation updated
→ then maybe done

It is slower.

But it feels much closer to building something real.

One more thing I learned

I used to think "shipping" was mostly the final step after development.

Now I think it changes how you develop from the beginning.

When you know you will actually deploy something, you think differently about:

configuration
secrets
observability
failure cases
reproducibility
documentation
users

The project stops being just code.

It becomes a system someone else has to trust.

What's next

I am continuing to improve Security Lens and experimenting with the same workflow on other small products.

The Security Lens source code remains private, but I created a public technical case study here:

👉 Security Lens — Technical Case Study

And the lightweight Spring Boot release workflow is available here:

👉 Spring Boot Release Checklist

For me, the biggest lesson so far is simple:

Coding makes the product possible. Shipping makes it real.

Still learning.
Still shipping.

My Spring Boot App Worked on Localhost. Deployment Showed Me What I Had Assumed.

nocklock — Mon, 21 Sep 2026 03:28:02 +0000

My application worked.

The API responded.
The frontend could call it.
The main flow did what I expected.

On my machine, at least.

Then I tried to move it outside localhost.

That was when I started finding things I hadn't really designed.

I had only assumed them.

Localhost is a very forgiving place

When I was building the MVP, a lot of things were simply there.

My Java environment was already configured.

The right processes were running.

I knew which port the application was using.

When something failed, I could open IntelliJ, restart a process, change a property, and try again.

None of that felt unusual.

It was just my development environment.

The problem was that some of those conditions had quietly become part of the application.

I just hadn't written them down.

For example, during development I had already run into things like:

Spring Boot trying to use a port that was already occupied
Ollama already running on localhost:11434 while I tried to start it again
Docker becoming necessary once I wanted the application to run somewhere other than my own setup
WSL turning what looked like a massive Git change into a CRLF/LF problem
configuration that made perfect sense locally but needed another look before deployment

None of these were particularly dramatic problems.

But together, they showed me something useful.

A working development environment can hide a lot of assumptions.

The question changed

While I was building the MVP, my main question was:

Does this feature work?

After I started preparing it for deployment, the question became:

What needs to be true for this feature to work?

That second question turned out to be much more interesting.

A feature might work because:

a process is already running on my machine
a particular port happens to be available
a local path exists
a dependency is reachable through localhost
an environment variable is already configured
my machine has something installed that the server does not

The code can be correct while the application still isn't ready to leave the machine it was written on.

That distinction seems obvious once you see it.

I don't think I really understood it until I tried to ship something myself.

One small example: localhost

localhost is convenient because it feels almost invisible during development.

If my Spring Boot application needs another service running locally, calling something like this feels completely reasonable:

http://localhost:11434

On my computer, it is.

But the meaning of localhost changes the moment the application moves to another environment.

It no longer means:

my computer, where I already installed everything

It means:

this machine or container

And the service I expected may not exist there at all.

That forced me to stop treating addresses and ports as incidental details.

They were part of the deployment design.

Docker wasn't the goal

I didn't start the project because I wanted to learn Docker.

Docker appeared because I wanted somebody other than me to be able to run the application.

That difference mattered to me.

Learning a tool in isolation often feels abstract.

But once I had a real application in front of me, the questions became concrete:

What exactly needs to be inside this environment?
What should stay outside it?
Which port should the application expose?
What configuration should come from the environment?
What does the application expect to already exist?
Can I reproduce the same startup somewhere else?

Suddenly Docker wasn't a topic.

It was an answer to a problem I actually had.

What I check now before saying “it works”

I still build the feature first.

But before I consider it finished, I now try to ask a few more questions.

What does this application assume is already running?

A database?

A local AI server?

Another API?

Something I started manually an hour ago and forgot about?

This question alone catches more than I expected.

Is anything tied to localhost?

Sometimes it should be.

Sometimes it is just there because development started locally.

I want to know which one it is.

Are ports part of the configuration or just part of my memory?

I had a Spring Boot application hit an 8080 port conflict and ended up running it on 8081.

It was a small issue.

But it reminded me that configuration I keep in my head is still configuration.

Could I start this from a clean environment?

This is one of the questions Docker made much harder to avoid.

If the application only works because my machine has accumulated the right tools, files, processes, and settings over time, I want to know.

If it fails, will I know why?

Logs, startup errors, health checks, and clear configuration are not exciting when the application is working.

They become very exciting when it isn't.

Deployment started acting like a test

I used to think of deployment mostly as the final step.

Build the application.

Finish the features.

Then put it on a server.

I'm starting to see it differently.

Deployment is also a test of how well I understand what I built.

It asks questions that localhost often doesn't.

What is required?

What is accidental?

What is configuration?

What did I assume would always be there?

What only works because this is my computer?

That's why some of the most useful things I learned from this MVP didn't come from adding another feature.

They came from trying to move the same feature somewhere else.

I'm keeping track of the small failures too

I've been documenting this project while rebuilding my development habits.

Not just the architecture or the successful parts.

The smaller problems too:

port conflicts
Git line-ending issues
Docker setup
deployment configuration
local AI dependencies
the gap between an MVP that runs and one that can actually be used

Most of these problems aren't impressive on their own.

But they are exactly the things I end up searching for when I'm building something.

So I'm writing them down.

Mostly because I know I'll need them again.

And maybe another developer will find one of them before spending an hour wondering why something that worked perfectly on localhost suddenly doesn't.

I Built the MVP First. Then I Wrote the README.

nocklock — Sun, 20 Sep 2026 12:51:48 +0000

I did this in the wrong order.

At least, that was my first thought.

I was building a small project that checks images and documents for privacy risks. The backend came first, then the API, then a frontend that finally made it feel like an actual service.

Somewhere along the way, I realized something.

I had built quite a lot before properly organizing the requirements and documentation.

Normally, I would expect the order to look more like this:

requirements → design → implementation → testing → documentation

Mine looked closer to this:

build → break something → fix it → build more → test it → finally organize everything

Not exactly textbook development.

But writing the documentation afterwards turned out to be more useful than I expected.

The README became a way to inspect the project

At first, I thought I was just writing down what I had already built.

Instead, I kept finding things that were unclear.

What does this API actually guarantee?

What configuration is required before running the project?

What happens when an external dependency is unavailable?

Which parts have actually been tested?

Would someone other than me know how to start this project?

These are simple questions.

They become much harder to ignore when you have to explain the project in plain English.

And that was probably the most useful part.

Documentation stopped being something I needed to finish after development.

It became another form of testing.

AI made building faster, but that created a different problem

I also used AI quite heavily while building.

ChatGPT, Claude, and coding tools made it much easier to move from an idea to working code.

That part was great.

But faster implementation also meant I could move past decisions without really stopping to organize them.

A configuration works, so I move on.

An endpoint returns the right response, so I move on.

Docker starts successfully, so I move on.

Then deployment comes.

Suddenly all the small things I skipped become visible again.

Environment variables.

Ports.

Database configuration.

Build commands.

Health checks.

Logs.

Security settings.

Things that looked like small details on localhost started feeling much more important once I tried to get the application outside my own machine.

That was the point where I started thinking less about:

“Does this code work?”

and more about:

“Is this actually ready to leave localhost?”

There is a bigger difference between those two questions than I expected.

A working MVP is not the same as a shippable MVP

I used to think of an MVP mainly in terms of features.

If the core function works, the MVP works.

I still think that is partly true.

But there is another stage after that.

The application has to survive being run somewhere other than your laptop.

Someone needs to know how to configure it.

You need to know when it has failed.

Secrets should not be sitting in the repository.

The build should be reproducible.

The production environment should not depend on something you happened to configure manually three days ago and already forgot about.

None of these things are particularly exciting.

They are also exactly the things I kept running into.

So I started writing them down.

Not as another tutorial.

Just as a checklist I wanted for myself the next time I reached this stage.

That checklist became its own project

Eventually those notes turned into Ship Your Spring Boot MVP.

Eventually those notes turned into a small release workflow.

I made a lightweight version public on GitHub:

👉 Spring Boot Release Checklist

It is a practical pre-release checklist for Spring Boot MVPs moving from localhost to production.

The idea is simple:

before calling an MVP ready, go through the things that are easy to miss when most of your attention has been on making the feature work.

I also ended up expanding those notes into a more detailed Full Edition with more checks, verification steps, deployment notes, and the things I wish I had organized earlier.

I later expanded the same idea into a more structured 58-page deployment runbook, but the GitHub checklist remains the lightweight public version.

I did not originally plan to make a product out of it.

It came from repeatedly asking myself the same question while building:

“What am I forgetting before I ship this?”

I still don't think building first is the correct order

I would not turn this into advice like:

“Forget requirements. Just start coding.”

That would be the wrong lesson.

If anything, doing it backwards showed me why the earlier steps exist.

But there was something valuable about documenting a project after I had actually struggled with it.

The checklist was no longer theoretical.

Every item reminded me of something I had needed, forgotten, broken, or had to go back and check.

Maybe next time my process will be a little cleaner.

Probably not perfectly clean.

And that's fine.

I'm still learning by making things.

I keep more notes about development, AI tools, deployment, and the things that break along the way on the Nocklock blog.

You can also see the projects I'm building on GitHub.

DEV Community: nocklock

Git on a New Windows PC: init vs clone, origin, -M, -u, and Your First Push

1. First, make sure Git is actually installed

2. Configure your Git identity

3. git init vs git clone

You already have a project on your computer

The repository already exists remotely

4. Add your files and create the first commit

5. What does origin actually mean?

6. What does git branch -M main mean?

7. What does -u mean in git push -u origin main?

8. The full flow from a local project to GitHub

What changed for me after setting Git up again

One thing I would not do

After the first push

Shipping the project after Git is ready

Ship Your Spring Boot MVP — Free Edition

Ship Your Spring Boot MVP — Full Edition

IntelliJ Java Version Mismatch: Project SDK, Gradle JVM, and JAVA_HOME Explained

IntelliJ Java Version Mismatch: Project SDK, Gradle JVM, and JAVA_HOME Explained

1. Start with the Java version your terminal is using

Command Prompt

PowerShell

Command Prompt

PowerShell

2. Check IntelliJ Project SDK

3. Do not forget the Gradle JVM

4. Check what Gradle is actually running with

Command Prompt

PowerShell

5. Your project may define its own Java requirement

Why Java version problems become confusing

When I see a Java version error, this is what I check first

The setup order I use on a new machine

Shipping the project after the environment works

Ship Your Spring Boot MVP — Free Edition

Ship Your Spring Boot MVP — Full Edition

AI Wasn't the Beginning. We Had Already Started Outsourcing Parts of Ourselves to Smartphones

I used to memorize phone numbers

I stopped memorizing routes too

Discovery changed too

Then AI arrived

I'm not arguing that we should stop using it

Convenience has always had a trade

I Set Up a New Windows Laptop for Java and Spring Boot. Here’s What I Checked First.

I started with Windows, not IntelliJ

Then Java

Git came next

Then IntelliJ

The real test was Spring Boot

A fresh laptop exposes hidden state

This is also where shipping starts to feel different from coding

Ship Your Spring Boot MVP

About the LG gram Pro 17

What I'm testing next

AI Made Me Faster. It Also Exposed What I Didn't Understand

1. server.port=${PORT:8080}

2. 8081:8080 was not just two random ports

3. Ollama wasn't broken. Port 11434 was already being used.

4. Environment variables were not just a deployment trick

AI made this pattern easier to notice

Writing about the problem exposed the gap

This happened while I was building Security Lens

I Used to Think Getting Better at Coding Meant Writing More Code

I used to care mostly about whether the code worked

Deployment made this painfully obvious

I also started reading errors differently

Even README files started looking different

The strange part is that I'm writing less code sometimes

My questions are different now

15 Things I Check Before Shipping a Spring Boot MVP

I Built the MVP. Then I Realized Shipping Was a Different Skill.

I Built the MVP. Then I Realized Shipping Was a Different Skill.

The MVP was working

"It works" was only the beginning

Deployment exposed assumptions

AI made this even more interesting

That became a checklist

Then I noticed something else

Shipping forced me to learn things coding alone did not

3. `git init` vs `git clone`

5. What does `origin` actually mean?

6. What does `git branch -M main` mean?

7. What does `-u` mean in `git push -u origin main`?

1. `server.port=${PORT:8080}`

2. `8081:8080` was not just two random ports