
Ask HN: How do you stay focused while it's compiling? - aspyct
Nowadays, every time I need to compile and run my code, it takes about 3 minutes to complete, before it finally starts running.<p>These three minutes are usually enough for me to open hackernews, reddit or some other news website, and... voilà, just lost 20 more minutes.<p>So...<p>What do you do during long compiles? Can you stay focused?
======
weberc2
This isn't a direct solution to your problem, but when I worked on a large C++
code base, I found it tremendously helpful to lean more on unit tests as a
source of fast feedback for a particular code unit rather than compiling and
booting the whole app for a manual test. Manual tests will still be necessary,
but they should be less frequent so your long compiles will be less frequent
as well.

Even less helpful for you, I recently been able to use Go more frequently, so
I have no more long compile times. :p

~~~
abc_lisper
This is true. I have seen some very effective programmers do this. They do
this even when playing with a new library.

------
baccheion
I'd go completely insane if it took more than a few seconds to compile
something, especially as I like compiling frequently.

I remember having to work in Java codebases, and it was an absolute nightmare.
Slow was the name of the game at all levels: slow to design anything, slow to
write the code required, slow to navigate, slow to compile, slow to start,
etc.

What are the nature of the changes you're making? Is it something you can
write and debug in another (faster) language, then translate to the main
language? If you were able to do it this way, then you wouldn't need as many
compilations.

~~~
Cyph0n
What language are you using now that has faster compile times with a codebase
similar in size to what you worked on in Java?

~~~
baccheion
It seems to be more than compile times. Something about Java, the IDE, and all
the other tools/plugins/whatever make it painful to use.

The first thing that usually happens when there's a switch from Java to most
other languages is a shrinking of the codebase. That is, it's not uncommon to
go from 200,000 lines of code to 20-30,000.

If you still need the runtime speed Java offers, then that's one thing,
otherwise, you can use some dynamically typed language like Python or Ruby. I
suppose there's also Go, as many can't go without static types.

At the end of the day (especially if all compile times end up being similar),
I'd prefer almost any other language over Java. Swift, Kotlin, Nim, Rust,
Elixir, Crystal, Julia, D, C#, anything.

~~~
Cyph0n
> Something about Java, the IDE, and all the other tools/plugins/whatever make
> it painful to use.

That's an issue with your toolchain.

> The first thing that usually happens when there's a switch from Java to most
> other languages is a shrinking of the codebase.

This is debatable and depends heavily on the langauge you're moving to.
Further, even if true, it will definitely result in either a performance hit
or a code complexity hit (heavy use of FP), or even both.

> I suppose there's also Go.

I haven't seen the numbers comparing compile times for equivalent Go and Java
codebases, so I cannot comment on that. I'm assuming that Google's main goal
with Go is to improve compile times relative to C++ and Java, which they
extensively.

~~~
baccheion
Not my toolchain, whatever was the case where I worked. That aside, my main
point is that it was generally a slow, painful experience using Java, and it's
more that I'm not entirely sure if compile times were the reason (or only
reason).

For example, I continually noticed long and painful compile times, but when I
mention these things elsewhere, the responses say Java actually compiles very
quickly.

There can be a runtime performance hit, but that's mainly if one switches to a
language like Python or Ruby. That is, many compiled languages have runtime
speeds similar to Java's.

As for equivalent codebase sizes, do you mean literal lines of code, or having
them provide the same functionality? I look mainly at equivalent
functionality, as 1000 lines in Python can easily be doing much much more than
1000 lines in Java.

You can probably search for comparisons (of Go and Java). In the beginning, Go
was indisputably faster, but apparently they've introduced certain changes in
the last year or so that's resulted in slower compile times.

Even with slower compile times, it's likely Go still compiles much faster than
Java, while also resulting in a smaller, more manageable codebase.

~~~
Cyph0n
> There can be a runtime performance hit, but that's mainly if one switches to
> a language like Python or Ruby. That is, many compiled languages have
> runtime speeds similar to Java's.

Yes, but you won't get a 10x reduction in LOC as you claim. The point is that
LOC reduction is usually not "for free".

> As for equivalent codebase sizes, do you mean literal lines of code, or
> having them provide the same functionality? I look mainly at equivalent
> functionality, as 1000 lines in Python can easily be doing much much more
> than 1000 lines in Java.

Functionality. Of course it can, but you sacrifice performance.

> Even with slower compile times, it's likely Go still compiles much faster
> than Java, while also resulting in a smaller, more manageable codebase.

From what I've seen of Go, you typically need more LOC to achieve the same
task compared to Java.

~~~
baccheion
A 10x reduction isn't uncommon, unless the code wasn't doing much (or wasn't
very large) to begin with. Either way, the reduction is quite significant.

Where have you seen Go codebases being larger than Java's (with both providing
the same amount of functionality)?

~~~
Cyph0n
Primarily common snippets or tasks I felt were a bit verbose in Go compared to
Java, or at least as verbose as Java.

> A 10x reduction isn't uncommon, unless the code wasn't doing much (or wasn't
> very large) to begin with. Either way, the reduction is quite significant.

I'll shoot your question back at you: do you have any specific examples to
back your claim?

I don't like Java either to be frank, but I'm defending it because I'm not
convinced by your original claim, i.e., Java has long compile times and is 10x
more verbose.

------
AnimalMuppet
Go look out the window. It makes you get up and walk for a bit, which isn't
bad. It also is something that you're probably not going to do for 20 minutes,
so you'll come back sooner.

(I say that, but I usually look at HN...)

------
smt88
Add a loud noise to the end of compilation, like a fog horn or something.
Assuming you're not writing web software and compiling locally, you could also
add a command to kill your Chrome processes. If you lost a tab you really
liked, you could always pull it back from your history.

~~~
randomanybody
one thing that worked for me was iterm and growl integration to show me a
system notification on compilation completion.

~~~
dllthomas
I do this with PROMPT_COMMAND and notify-send.

------
merb
I always wonder about people that __need __a extreme fast feedback cycle. I
mean most of the time I do things, I actually think about new code, watch a
side project, discuss in gitter.

Our code's full test suite takes longer than 10 minutes and I still feel
pretty productive when working at it. Actually we lint/transpile our
JavaScript with Google Closure which is faster than webpack, but it still
takes over 5 seconds which is more than our scala app takes in continous
compile? Also I always see these cool JavaScript people, but I've never seen
any real world app that still has a amazingly fast micro seconds cycle.

------
swordsmith
Do 30 pushups during every compile cycle. Or any other body weight exercise.

------
jboggan
Came here and read this while 115,508 packages complied. So, no.

------
humbleMouse
Consider yourself lucky. Where I work it takes 20 minutes to compile the app,
and another 6 minutes to start the server. I'm not kidding.

~~~
abc_lisper
Run dude. More seriously, people who don't value your time don't value you.

------
source99
A few years back I was compiling hardware inside an FPGA. Typical "compile"
times were 2-3 hours.

I used to read a book while waiting for compiles when I was in High School.

I have test suites that take 5-20 minutes to run and I do just about
everything I can to cache data to bring that time down.

I feel your pain.

------
gcp
Or build system pops up a desktop notification when the build finishes. Fairly
easy to do on Linux with dbus.

------
thoughtpalette
My staging build takes around 8 minutes due to some bad optipng task or
something, and my API only works on staging so I usually just browse HN or
reddit during that time. I typically enjoy the break unless I have something
urgent to deploy.

------
afarrell
I use [https://freedom.to/](https://freedom.to/) to block HN and Reddit. If
I'm doing something that is very stop-and-go, I listen to a podcast or
audiobook.

------
75j
3 minutes is just enough time to stand up, walk around a bit, rest your eyes,
stretch, and get a drink of water. That's probably what I would do.

------
mherrmann
Probably easier said than done, but why not invest these 3 minutes into trying
to speed up the build, or equivalently, trying to split it into smaller parts?

------
amcrouch
Read only short articles that you have found during your surfing. Most
articles these days only take a few mins to read and you learn while you
compile!

~~~
gcp
But they have links! Interesting links!

------
bronlund
I always have one of those learning sites open in a tab and try to go there
when I have to wait.

At the moment it's pluralsight.com.

~~~
bbcbasic
Seems like a lot of context switching.

------
w_t_payne
tup

