Title before edit: I hate programming, why did i choose this field
TL;DR: Stupid mistake, made by hours waste.
Basically, I was extracting date from the SQL db, and it was not displaying. I tried everything, heck I even went to chatgpt, and copilot. Two and half hours of trying every single thing under the sun, you know what was the issue?
SELECT task, status, id FROM mainWorkSpace WHERE user_id = @user_id
I FUCKING FORGOT TO ADD ‘date’ TO THE DAMN QUERY. TWO AND HALF HOURS. I was like, “Ain’t no way.” as I scrolled up to the query and there it was, a slap in the face, and you know what was the fix?
SELECT task, status, date, id FROM mainWorkSpace WHERE user_id = @user_id
Moral of the story, don’t become a programmer, become a professional cat herder instead.
The best advice I can give to new developers is “question your assumptions”.
“But I set that variable” - did you?
“It should default to 0” - is it?
Remember - if things were working as you think they are then your code would be working.
Thanks will keep in mind next time it happens
Basically how I do rubber duckie debugging
See? It should work because I initialize it as this and iterate doing this and this which gives me a data structure like this and … wait … oh hell that clearly doesn’t produce the data structure I want. 🤦
We tend to see what we want to see, not what actually is.
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.
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. One of the first steps would be to run
SELECT * FROM mainWorkSpace WHERE user_id = @user_idand see if that returns anything.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 :-)
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_idand 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.
You should read up on what’s called “rubber ducky” debugging
Here’s a link to a comic that summarizes the idea succinctly: https://www.smbc-comics.com/comic/the-rubber-duck-method Wikipedia article here: https://en.wikipedia.org/wiki/Rubber_duck_debugging
You tried “everything” for over 2 hours but never tried the “*” selector?
User: I’ve tried everything
Support: Have you tried <first step in documentation>?
This kind of stuff happens all the time IMO, we’re human and not perfect 🤷♂️
I don’t know how much of a help ChatGPT would be in this situation without access to your schema, at least with Copilot you can write a comment in the code explaining what you’re trying to do and get some usable pointers in the generated suggestion (which takes your codebase into account).
I usually try to get a second pair of eyes on my code if something that seems relatively simple isn’t working as expected… As you gain more experience these mistakes will become less common, and easier to spot
My second pair of eyes was in an another country for business stuff so I had to solve it all by myself and because of the frustration, i wrote this post. Sorry about that
That’s when rubber duck debugging comes in handy.
You want to hate programming? Try using JS. It’s anarchy.
“Why is this the way to do things?”
“Because it just is.”
Oh, and there’s at last 2 other ways to do it too.
Sure, but they use ersatz methods that are so incredibly obscure and removed from the standard library that expecting one to know them is beyond foolhardy.
No clue what that means. I was thinking more along the lines of how there’s 3+ techniques for async functions. Or that there’s a handful of syntax implementations, versions, and supersets of the language. Or that there are many interpreters all with different standard libraries and quirks.
It’s an annoyingly flexible language.
It just feels like anarchy to me. Why is anything the way it is in JS? Maybe I’m learning it wrong, but starting from zero, I now feel like I understand less than nothing.
Mostly its this way because the language has evolved over time and relies heavily on several similar but competing interpretations of how things should be done. Similar thing happened to PHP, back in the web1 days.
That makes sense. Every time I try to learn it, or am asked to do something in it only to reply “I can’t”, I feel so fucking stupid. How am I supposed to move up to senior SWE if I can’t do JS?
At least its 2.5 hours and not 2 years because of writing h instead of H
I suspect there’s a long tragedy about this, the likes that would give The Odyssey pause.
Real moral of the story: STATIC TYPING!
Seriously so many people think it’s a waste of time, and then stuff like this happens.
If only there were a good statically typed database, as opposed to thin wrappers over SQL.
And better error messages than “bro, you got a syntax error on this line”
How would static typing help here?
Thinking about C# and Dapper here 'cause they’re what I’m used to, but, for example…
result = await connection.QueryAsync<ResultType>(QUERY);(whereResultTypeis a statically typed record, class, or struct shaped like the data you want returned.)Given a query that doesn’t return something that matches any of
ResultType’s constructors, the code’ll throw an exception at runtime complaining it needs a constructor that matches whatever it’s returning, whereupon you’ll notice it isn’t asking for it to have adateparameter, so the query must not be returning it.
We’ve all done stupid stuff like this. The trick is to pad time into estimates to account for it :D
The trick is to get project managers to automatically pad you time.
Yeah in my 25 years of experience, none of them have ever done that.
Get yourself a debug rubber ducky mate, talk to it when you are troubleshooting might fire off a coupe more pathways to identify the problem sooner.
I would like mine blue with an army’s helmet.
You can dress it up however you like.
Holiday duck
Professor Duck
Tech support duck
Tech support duck looks like he’s checking out some delicious bread crumb photography on that palmtop.
Long before the duck gained popularity – and I still can’t talk to a toy – I walk around and explain things to a phantom off in the corner of my mind, and I use bold hand gestures.
So this is the second mention of a rubber duck. I’m trying to fiercely convince myself that talking to a toy on your desk was absolutely not a real thing for adults and that this is some satire I’m missing.
If it’s true, that’s beyond shameful for an adult. I would quit if I were next to that person’s office/cubicle so that they didn’t infect me.
In fact, if this was a real thing, don’t even tell me. I don’t want to live with that kinda shame for my species.
I feel as though you are missing a key part. Some people are verbal debuggers, we speak what we wrote to understand it better. Now in an office environment what is more acceptable, talking to yourself or talking to a toy on the desk?
https://en.m.wikipedia.org/wiki/Rubber_duck_debugging
I have done this where you read the problem in your internal monologue but nothing new sparks, yet when you speak what is going on it activates different parts of your brain for the debugging process.
I do this, too. The only remedies I know are a walk or a colleague’s fresh perspective.
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.
When you walk, the risk is you’re still confirming and not asking those questions. The duck is awesome.
https://m.youtube.com/watch?v=CFRhGnuXG-4
Watch this. I have found that this makes it way easier to debug shit, is more readable, and cuts down on mistakes.
Watching this YouTube clip, I couldn’t help but remember the other YouTube clip that shows a red panda leaping against a door and trying to reach the doorknob.
I worry you’re artificially limiting yourself, and I hope you have the comfort to overcome this phobia one day.
🤣 no need. I certainly am not Linus levels of stickler on it and don’t sit there and worry about it. I just found the concepts he is trying to teach very helpful. Fail fast and breaking things up into smaller methods that do “a thing”.
I don’t consider myself a never nester, but looking at my code now, I extract all the time and rarely go 4 tabs in. It just makes it more easily maintainable. I also like the idea of putting the failure conditions first. I haven’t looked at this yet but I’m sure there are some times I can use it.
Sure, sometimes you might not have a choice, but I do think there is a lot of value to what they are saying. I think it kind of goes in line with standard “functions should do one thing” paradigm.
See, when I was in school, they didn’t teach fail fast and if anything they told you not to. Nowadays, we have moved past that nonsense. I gave it a shot about a year ago, and it has made me a better programmer. I am not going to sit there and count braces, but things are a lot easier when you get the error cases over with and out of the way.
There are always going to be exceptions, but I have personally found a lot of value in using ‘fail fast’, and making more smaller methods that say what they do. I am not always great at that second part, but it is a process. As someone with severe ADHD, it has made it a lot easier to work through problems. Sure, you can end up with more lines of code, but who cares. Compiler should be optimizing most of that shit out anyway.
I’m pretty sure chatgpt caught mistakes like these for me recently and in the past. Just always slap in all your code into the prompt and tell it what you want the code to do step by step. Like with rubber ducky debugging.
Sucks bro. You’re in good company tho
One of the hardest issues to troubleshoot is a bad assumption. Be glad you only spent 2 hours on this.
The reason the date is not in the output is because you didn’t include a date column in your SELECT statement.
If you want to include the date in the output, you’ll need to add a column that contains the date to your SELECT statement. For example, if you have a column named “created_at” or “date” in your mainWorkSpace table, you can add it to your SELECT statement like this:
SELECT task, status, id, created_at FROM mainWorkSpace WHERE user_id = @user_idThis will include the created_at column in the output of your query.
🤷 Gpt, first try. I don’t know what you asked.
I pasted my code multiple times and didn’t give me that answer. Maybe it’s because you only copied the query and not the code that i wrote.
I also posed the question why I don’t get a date in the output of course.
I was talking about this date which was used to display the date assigned by the user, but the column was not displaying with the date because I wasn’t asking sql for the date (if you’ve looked at the query), so yeah, a stupid mistake caused for a stupid angry post.
