Programming · by Hugo Martin · 2026-09-02

What are the red flags beginners miss in Programming on a budget?

Context: I am not an expert, just someone trying to make Programming feel less intimidating. I wrote down what worked, what felt awkward, and what I would do differently next time.

> Tiny progress is still progress.

That line sounds cheesy, but it got me through teh part where tools stopped feeling new.

I started this because my weekend felt a little stuck, and java seemed like a manageable place to experiment. The funny part is that teh smallest change was teh one I kept

76 sparks · 16 comments

Comments

Kabir Khan · 8 likes

The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. I would write it down before changing anything else

João Pereira · 5 likes

helpful correction

Midnight Otter · 1 likes

That is a much better way to say it

Ananya Rao · 7 likes

Try making a tiny reproduction with no framework code. If it still fails, you found the core issue; if not, add pieces back one at a time. I learned that one the expensive way

Sebastián Rojas · 6 likes

I was going to disagree, but your second sentence got me

Lucas Silva · 4 likes

There is probly a middle ground here. I am curious whether java still feels good next month

Silver Fern · 50 likes

adding this to my notes

Élodie Favre · 1 likes

could be regional too

Felix Weber · 4 likes

Try making a tiny reproduction with no framework code. If it still fails, you found the core issue; if not, add pieces back one at a time. This pairs weirdly well with idli

Aisha Rahman · 2 likes

I am saving this for the next time I overthink flags. My only addition is to make the first step visible. A small test case would make this easier to trust

Valentina Ruiz · 37 likes

noted, and thank you

Maya Williams · 4 likes

Appreciate the nuance

Ren Suzuki · 2 likes

I think the bad version of this advice causes a lot of frustration. It reminds me of a very specific conversation near the library

Jonas Schneider · 1 likes

The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. I care less about the perfect answer and more about repeatability

Sleepy Mango · 1 likes

I would log the input, the expected output and the actual output first. Once those three are visible, the bug usually stops feeling mysterious. This is more useful on a tired late summer then on a perfect day

Ren Suzuki · 1 likes

The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. The low-effort version is probably the keeper