Programming

Thanks will keep in mind next time it happens

I have great colleagues who still bust out this kind of cross-examination when we're trying to figure out why my code is a bag of poo. I have some friends I've known 25 years who will do this, and it's every bit as annoying and infuriating as it's invaluable help.

You’ve never made a silly mistake where you “can’t see the forest for the trees”?

It happens to the best of us

Seriously. If this broke him it gets so much worse.. but honestly op, this is how you learn what to do and what not to.

You don't know the circumstances. They might have only seen the query results after several processing steps...

it's indeed a new language for me and I haven't developed that ability to know where the bug is happening but I am going to get there.

Was going to say that.

@OP:

One of the main skill a developer must have is being able to troubleshoot properly how their code behave.

Break your code in small pieces, check all of them with unitary test (formal or not) to validate their behavior then move to the next step. Never test everything in one shot or you will be overwhelmed by side effect bugs whom will distract you from the real root cause.

Being a programmer is not just coding but also testing and deploying (even locally).

That won’t avoid you being blocked by a silly mistake for hours, everybody did that at some point in their career, but that will reduce your frustration against yourself when you discover why the bug existed.

Do a pause, go walk, change the topic and the next time you look at your code, you will spot the obvious bug :-)

If you're not familiar with the table, use a select top 10 * from table if you're on sqlserver, postgresql uses limit and oracle has fetch.

Don't recommend select * without limits or conditions unless you absolutely know the table, you can very quickly make a DBA unhappy

In those kinds of situations you need to remember to try to break the problem down into simpler sections to identify where the problem lies.

Learned that the hard way.

One of the first steps would be to run SELECT * FROM mainWorkSpace WHERE user_id = @user_id and see if that returns anything.

It's one of those situations where if i write something, i forget it because it is doing its thing and about selecting everything, i should've done that and it's my mistake.

User: I've tried everything

Support: Have you tried ?

Thanks for sharing your experience, who knew a frustrating post written by me would give me lessons which i am going to take to heart.

I had that experience last week. I half blame the language though cause the way it works is you don't initialize a variable, first time you use it the language automatically makes the variable and default value is 0.

I had a variable countoot that I had a formula calculate. Then a simple if countoot > 0 do this else do that. The program kept doing that. I knew countoot should be 2. I manually did the formula ... The answer was two.

I did the same formula in 3 other programs and it worked correctly. I spent between 1.5 to 2 hours a day for like 3 days banging my head on the desk trying to figure out why it would work. Fourth day me and 2 other guys were trying to figure it out when I finally really looked closely. I realized the formula result was stored in ccountoot(notice 2 c) and the if statement was based on countoot(notice 1 c)...yeah I felt so stupid when correcting the typo fixed the problem.

Oh, and there's at last 2 other ways to do it too.

I suspect there's a long tragedy about this, the likes that would give The Odyssey pause.

I would like mine blue with an army's helmet.

For me rubber ducking a coworker solves a lot of these things instantly, but walking just gets me further entrenched in my own stupid ideas.

Better to ask a rubber duck than an LLM.

It has better results, is cheaper, and makes has a positive compounding effect on your own abilities.