I recently moved my development setup to a new LG gram Pro 17.
At first, I was mostly distracted by the laptop itself.
It's a 17-inch machine, but it doesn't really feel like one when you pick it up.
The screen is huge compared to what I was used to, and the weight was honestly the first thing that surprised me.
Then I opened it and tried to get back to work.
That was when the more interesting part started.
My old development environment had disappeared.
Not my code.
My environment.
On my previous machine, Java was already installed.
Git worked.
IntelliJ knew my projects.
Dependencies were already downloaded.
Environment variables existed.
Some configuration files had probably been sitting there for months without me thinking about them.
I could open a project and start coding.
It felt simple.
A new laptop made me realize that it was only simple because I had already solved all of those problems sometime in the past.
A fresh machine removes the invisible parts
I started rebuilding everything.
Windows updates.
JDK 17.
Git.
IntelliJ.
Project SDK.
Then I cloned one of my existing Spring Boot projects.
None of this was new to me.
I've installed Java before.
I've configured IntelliJ before.
I've run Spring Boot projects more times than I can count.
But doing it all again from zero made something visible that I normally don't notice.
A development machine accumulates state.
Over time, that state becomes invisible.
You stop remembering which environment variable you added.
You forget which local file exists only on your machine.
You don't think about which JDK your IDE is pointing to because it has been correct for months.
You just work.
Until you move to another machine.
At some point I had Java installed.
Git was working.
IntelliJ was open.
Technically, I had a development environment.
But I didn't really consider the setup finished.
I had one condition:
Can one of my existing Spring Boot projects actually run here?
So I opened an old project.
The IDE indexed it.
Dependencies were resolved.
The project built.
Then I ran the application.
The server started.
That was the moment the new machine felt ready.
Not when IntelliJ opened.
Not when java -version worked.
Not when Git cloned the repository.
When the application actually ran.
Because a real application depends on much more than the editor where you write the code.
"Works on my machine" has another side
We usually talk about "works on my machine" when deployment breaks.
But moving to a new laptop made me realize there is a smaller version of the same problem inside development itself.
If a project only works because my old machine has the right combination of hidden configuration, cached dependencies, local files, and environment variables...
how reproducible is my development environment really?
I'm not saying every local setup needs to be fully automated.
Mine isn't.
But I do think I should be able to answer a basic question:
What does this project actually need in order to run somewhere else?
A new laptop is surprisingly good at testing that.
This felt familiar
I ran into almost the same problem while building and deploying small Spring Boot MVPs.
The main feature worked.
The API responded.
The UI behaved correctly.
On localhost, everything looked fine.
Then deployment started exposing assumptions.
Ports.
Environment variables.
Build configuration.
External services.
Things that my local machine had quietly been handling for me.
That's when I started thinking of building and shipping as two different skills.
I eventually turned the checklist I was using into a small guide called Ship Your Spring Boot MVP.
It focuses on the things I kept checking before calling a project ready to leave localhost:
- clean builds
- configuration
- environment variables
- deployment checks
- evidence that the application actually works outside the development machine
If that's a problem you're working through too:
Ship Your Spring Boot MVP
I didn't make it because deploying Spring Boot is mysterious.
I made it because I kept realizing how easy it is to confuse "the feature works" with "the product is ready to ship."
The laptop itself still needs more testing
As for the gram Pro 17, I'm still not ready to call this a full developer review.
The machine I'm using has a Core Ultra 7 and 32GB of RAM.
So far, I really like the screen size and the weight.
But what I actually care about comes next.
I want to spend real development time with:
- IntelliJ
- Spring Boot
- Docker
- a database
- browser tabs
- documentation
- all the other things I somehow leave open at the same time
I want to see the thermals.
I want to see the battery life.
And I want to know whether carrying a 17-inch laptop every day still feels like a good idea after the novelty wears off.
So the hardware review can wait.
For now, the more interesting thing wasn't the new laptop.
It was seeing my old development environment without all of its accumulated history.
The laptop was new.
The code wasn't.
But starting from an empty machine made me see how much invisible context had been sitting between the two.
