Oh boy, all of these are great questions. First, yay! 🎉 Welcome to Chromium! 🎉

This ended up being an enormous reply, so I broke it in sections. 🐳

Hardware

Most Chrome developers that work for Google have incredibly beefy machines under their desks, that build Chromium really, really fast. I had a Z620 with a buuunch of cores, and it was magical. Even then, a complete rebuild would be about 20-25 minutes. I've also successfully built Chromium on my laptop, which is a 2.3 GHz retina MBP with 16GB of RAM and a 256 GB SSD.

The official build instructions say that the minimum recommended setup is 4-8 cores and 16-32 GB of RAM are best. An SSD helps a ton. I think you should give your setup a try, and see what happens; worst case scenario, it will just take 10 hours. You'll also notice that just downloading the code will take a very long time -- there's like 10+ gigs of Chromium code, syncing all of it ain't a walk in the park 😅

Faster builds

A lot of "being productive" comes from tricks that make you rebuild less code:

• enabling the component build (explained here) is a must -- this won't really make your initial build faster, but it will make incremental builds significantly faster.
• not syncing and rebuilding master every day. I once ran some stats and found out that Chromium gets on average 160-ish commits a day -- that's a bunch of new code, which probably will touch a lot of headers, and will have to rebuild and link a ton of stuff. What I used to do for my patches is sync master once, at the beginning of me working on a branch, and working on that branch until you're done with your patch, without syncing master. Once the patch is almost ready to be uploaded, rebase master then (and probably resolve a bunch of merge conflicts). That way, while you're working, the only code that should change on your branch will be code that you write -- which again, should make incremental builds faster. This approach makes parallel branches a bit harder, but it will at least let you explore working on Chromium for a bit.

Edit: @nico just pointed out he has more tricks to make incremental builds super fast. His full answer is here, but the TL; DR is:

• if you set disable_nacl=1, gyp will run 30% faster and your build will be ~15% faster
• if you set fastbuild=1, your build will be faster, but you won't have full debug information
• on OS X, Release builds are noticeably faster than Debug builds. Unsure about Windows, but I would suspect "probably yes"
• if you set component=shared_library, incremental builds will be way way faster (like 10x as fast)

Debugging

Here's the instructions on debugging on Windows. I can't remember if printfs work on Windows anymore (they used to not, because the Windows command prompt is not actually a terminal; I mostly used a Mac, and there they definitely go to the console), but if they do, they would either go to the command prompt, or the chrome_debug.log file (the link should help you with that), or both.

I also sometimes used lldb (which is the llvm equivalent to gdb). I wrote a bunch of bare minimum instructions on how to use llvm for literally just setting breakpoints, stepping through code, and inspecting variables, which is usually what I need the most.

Hope this helps, and good luck! ✨