How do you get better at backend without burning out when life is busy?

Midnight Otter · 50 likes

The safe answer is to keep the API boring: clear names explicit errors and one behavior per function. I learned that one the expensive way

Tiny Runner · 40 likes

the safe answer is to keep the API boring: clear names explicit errors and one behavior per function. I used to overcomplicate this constantly

Aarav Sharma · 6 likes

that is fair, but I still worry about maintenance

Hugo Sánchez · 1 likes

That is the part people skip

Faisal Al Saud · 34 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

Ayesha Khan · 31 likes

Start by reducing it to the smallest reproducible piece, then change one variable at a time. Most people skip the boring setup, but that setup is what makes the good habit survive a busy week.

- Write down the exact error and the input that caused it.
- Make a tiny example, then add pieces back slowly.
- Keep the final fix boring and well-named.

Come back with what happened; the details will make the next answer better

Nusrat Akter · 400 likes

I laughed, but you are not wrong

Ayesha Khan · 12 likes

That sounds great until you add children/pets/deadlines

Camila Rocha · 10 likes

I am curious what changed your mind

Nusrat Akter · 7 likes

That is a good boundary

Isha Menon · 2 likes

I would love a follow-up example

Bianca Santos · 1 likes

@camilanotes I laughed, but you are not wrong

Lina Al Harbi · 3 likes

anecdote beats theory here

Omar Hassan · 1 likes

Thanks that actually helped

Camila Rocha · 2 likes

@ayesha-29 I would pin this if I could

Solar Sparrow · 28 likes

Try making a tiny reproduction with no framework code. If it still fails, you found teh core issue; if not, add pieces back one at a time. I noticed teh same thing in Lagos

Imogen Clarke · 27 likes

The safe answer is to keep teh API boring: clear names, explicit errors and one behavior per function. For me it came down to teh playlist

Jonas Schneider · 35 likes

adding this to my notes

Gentle Noodle · 4 likes

Now I want a spreadsheet

Maksym Bondar · 1 likes

my wallet felt that

Camila Rocha · 1 likes

Appreciate the nuance

Minh Nguyen · 27 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. For me it came down to the setup

Chloe Davis · 24 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. The Warsaw example makes it feel concrete

Aina Rahman · 20 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 used to overcomplicate this constantly

Ayesha Khan · 1 likes

This comment has main-character footnote energy

Huy Le · 19 likes

start by reducing it to the smallest reproducible piece, then change one variable at a time. If two options look equal, choose the one that is easier to reverse.

- Write down the exact error and the input that caused it.
- Make a tiny example, then add pieces back slowly.
- Keep the final fix boring and well-named.

That should give you a solid first pass

Sleepy Comet · 18 likes

@vn_otter9 Helpful correction

Huy Le · 79 likes

Thanks that actually helped

Jasmine Cruz · 14 likes

my wallet felt that

Lena Müller · 0 likes

Thanks for making it less intimidating

Jasmine Cruz · 11 likes

Beautifully concise

Theo Bennett · 1 likes

I needed the reminder to start smaller

Huy Le · 1 likes

That sounds great until you add children/pets/deadlines

Ethan Brooks · 10 likes

The Tuesday test is undefeated

Olena Shevchenko · 2 likes

adding this to my notes

Lotte Jansen · 6 likes

adding this to my notes

Mateo Cruz · 1 likes

that is fair, but I still worry about maintenance

Arif Hasan · 18 likes

yep, the boring details matter

Huy Le · 0 likes

You just saved me a bad purchase

Silver Fern · 5 likes

That is a good boundary

Luca Bianchi · 5 likes

anecdote beats theory here

Noah Miller · 4 likes

I would pin this if I could

Mariam Said · 1 likes

Thanks for making it less intimidating

Camila Rocha · 1 likes

The Tuesday test is undefeated

Tomás Gómez · 18 likes

Good reminder that boring can be good. This is where I would ask one more question before choosing

Urban Baker · 18 likes

the safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. Honestly, the simplest version wins for me

Yasmine El Amrani · 4 likes

I needed the reminder to start smaller

Valentina Ruiz · 1 likes

Respectfully, I see it the other way

Mango Coder · 1 likes

That is the part people skip

Grace Parker · 1 likes

This is the kind of disagreement I like

Cedar Mango · 0 likes

that is fair, but I still worry about maintenance

Aoi Ito · 17 likes

The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. I noticed the same thing in Madrid

Nour Ali · 17 likes

the safe answer is to keep the API boring: clear names explicit errors and one behavior per function. The delightful constraint is probably the real story

Amelia Hughes · 16 likes

Amazing how much difference one small change can make. The surprising part is easy to underestimate

Camila Rocha · 12 likes

I am stealing that phrase

Rohan Mehta · 0 likes

noted, and thank you

Linh Tran · 14 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. The social part surprised me too

Priya Nair · 12 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 busy month then on a perfect day

Gentle Baker · 42 likes

@in_panda The Tuesday test is undefeated

Priya Nair · 2 likes

yep, the boring details matter

Noor Janssens · 1 likes

helpful correction

Nour Ali · 2 likes

I am curious what changed your mind

Budi Santoso · 4 likes

helpful correction

Maya Putri · 12 likes

the safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. A little friction removed goes a long way

Maya Williams · 11 likes

I am saving this for the next time I overthink busy. That is the kind of detail beginners miss

Laura Gómez · 1 likes

Exactly; the hidden cost is energy

Isha Menon · 11 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. I noticed the same thing in São Paulo

Mango Otter · 10 likes

honestly, great taste. I noticed the same thing in Istanbul

Jack Taylor · 9 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. The useful part is easy to underestimate

Camila Rocha · 7 likes

That is the part people skip

Jack Taylor · 4 likes

That is a good boundary

Elsa Andersson · 7 likes

That sounds great until you add children/pets/deadlines

Sophie Gagnon · 3 likes

I am curious what changed your mind

Urban Baker · 2 likes

Now I want a spreadsheet

Mariam Said · 1 likes

This is the kind of disagreement I like

Jack Taylor · 2 likes

anecdote beats theory here

Grace Parker · 8 likes

Agree completely. The simple version is underrated. I am curious whether performance still feels good next month

Kabir Khan · 23 likes

Exactly; the hidden cost is energy

Léa Bernard · 13 likes

noted, and thank you

Grace Parker · 7 likes

This comment has main-character footnote energy

Beatriz Sousa · 12 likes

adding this to my notes

Camila Rocha · 9 likes

adding this to my notes

Kabir Khan · 31 likes

yep, the boring details matter

Kabir Khan · 8 likes

The conclusion is too broad, but the example is interesting. I care less about the perfect answer and more about repeatability

Aarav Sharma · 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. The low-effort version is probably the keeper

Luciana Vargas · 7 likes

Helpful and not preachy, wich is rare. The practical constraint is probably the real story

Camila Rocha · 1 likes

I like this more then the top-level advice

Beatriz Sousa · 6 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

Hugo Sánchez · 0 likes

This. Exactly this

Beatriz Sousa · 15 likes

I like this more then the top-level advice

Piotr Zieliński · 6 likes

Anecdotally, this tracks with what I have seen. The low-effort version is probably the keeper

Cedar Baker · 5 likes

I wonder how much of this depends on timing. The weekend version is even more interesting

Ethan Brooks · 5 likes

I wish more posts had this much context. The gentle constraint is probly the real story. The boring solution is probably the reliable one here

Diego García · 2 likes

fair pushback

Mariana Costa · 5 likes

The safe answer is to keep the API boring: clear names, explicit errors and one behavior per function. It sounds small, but the prototype matters

Ethan Brooks · 5 likes

I appreciate the honest middle stage, not just the polished ending. I care less about the perfect answer and more about repeatability. Naming things remains undefeated as the hardest problem

Chinedu Adeyemi · 4 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. It sounds small, but the setup matters

Noah Miller · 4 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. The rainy evening version is even more interesting

Maya Putri · 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. Honestly, the simplest version wins for me

Minh Nguyen · 3 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 where I would ask one more question before choosing