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.
Top comments (0)