Why is it that I have to humiliate myself to make my code work?

Why is it that I have to humiliate myself to make my code work?
0

#1

This is the scenario I’m talking about: I try to make a code so that my page looks and works a certain way, and it is not working. As far as I know, the code I"m using should be working. I try every combination of classes in different elements to make it work. It still doesn’t work. I research all my reference pages and keep trying different things and it still won’t work.

So I give up and ask people why my very simple coding goal is not working. The answer I get is something that I know I have tried already, but it didn’t work when I tried it before. It only works after I have to humiliate myself by asking people why I can’t make such a simple thing work right. Only after I embarrass myself does the same code that I must have tried before magically start working. It seems like the universe is messing with the internet to try just to make me look stupid, when I"m not actually that stupid because I tried that solution before but it didn’t work before because the universe hates me and wants me to look stupid by forcing me to ask why such a simple thing is not working for me until after I ask people how to make the simplest thing work.

Has anyone else experienced this?


#2

The coding Gods are cruel and fickle in their appreciation of our worship.

But seriously, don’t beat yourself up over needing to ask for help - absolutely every single programmer experiences bugs and frustrations, and a second (or third, or fiftieth) set of eyes is always valuable.

As for ‘I tried that’, that may be true…sometimes browsers might be a little hinky in the way they cache previous visits and not honour our updated code as we expect. But this is rare. Usually it’s an invisible semicolon. The trouble with any programming language is that our brains are so used to reading and understanding English (or prose in any native language) that sometimes we can miss errant commas, semicolons and curly braces because we have highly developed abilities in filtering out noise when trying to parse text - unfortunately for coding, the noise isn’t noise at all, so it’s easy to miss something important.

The other day someone posted two identical code blocks and asked why one worked and the other didn’t. It took me 30 minutes of looking at them to realise that actually one had a stray equals sign.

30 minutes lost on an equals sign…

Edit
My mistake, it was a >!


#3

^ Agreed.
Can’t possibly put it more perfectly. Also if you are working with any kind of coding, the logic is very important, may be you exit the loop one bracket too early or too late. Everybody’s going through the same struggle so don’t worry.
BTW, yesterday I spent the whole evening wondering why my program didn’t work and it turned out that the API stopped working.


#4

You need to re-think your way of asking for help, there is nothing humiliating by asking for help! I believe we live in a world where “everyone else” is a perfectly fine resource to use. And a resource to “be a part of” as well :slight_smile:

I’ve also got some real issues with CSS, I can’t seem to figure out the abstract way of thinking how changing element X’s display to display:inline-block will affect my footer so much. But I guess I’ll learn!

Keep trying and remember you’re a part of the resource over the internet, there are people just like you, that are ripping their head at the same problem you just had, and this is where you shine and give back to the community! :slight_smile:


#7

Couldnt have said it better myself. The Gods seem to favor only on occasion. :joy:


#8

See also: “I swear that those shoes were not in this closet 60 seconds ago.” and “My computer isn’t working! Look. I click this button and… never mind.”

What you’re probably experiencing though is that your logic is sound but you have small errors. Perhaps with syntax or ordering of commands. Before you throw a solution away, try to debug it and find out why the logic isn’t working. Step through it bit by bit until you can find where the state of things is now what you expected them to be.


#9

I just wanted to say thanks for all the responses and advice - and the compassion. It has really helped me :).


#10

Ahh, you need to have a new attitude about this. Asking for help is not humiliating. Not after you tried so many solutions on your own. I always ask for help even after years of working. Knowing when to ask for help is something good! The important thing is not to ask for the same thing over and over again :wink:


#11

You don’t know humiliation until you wear your underwear like a hat in a crowded bar while singing “Shake it Off” and crying in between bites of a hot dog you found behind the pool table. And I did that for nothing more than a Klondike bar. :cold_sweat:

Asking for help is a vulnerable experience, and it’s even worse when it seems like something that, in hindsight, should have been within our grasp. But the fact is that we’re all human. We have limitations, breaking points, and faults. Remember that no one is here against their will. If you receive help, it’s because someone was willing to help. If you ask for help, it’s because you can’t do everything - just like the rest of us.


#12

I wonder if you might have missed out on some of the necessary physical training.

I’m exceptionally error-prone in life and must find ways to improve or compensate for my random blunders. When I started learning to code at Codecademy, I would delete all the provided code and type everything on my own through a combination of memorization and actually understanding the concepts. If I made a mistake, even the slightest syntactical error, I would force myself to do the exercise all over again from the beginning. A year later and I still do this whenever I’m learning another language/library/etc.

Of course the memorization part doesn’t necessarily help to grasp the concepts, but the rewards-based repetition trains the mind, eyes, and hands to coordinate properly and to stop making the little errors that halt your progress and drive you crazy. (see Motor control) I still miss the occasional curly-brace or semi-colon but it’s extremely rare (except where I do it on purpose). Something to consider at least.


#13

Because I have little, girly hands I actually remapped some of my keyboard keys because having to reach so far made me much more typo-prone. I know that normal typists might not use = and + that much, but we sure do!


#14

lol best response ever.


#15

Systematize your troubleshooting technique. Here is a good article about that by Eric Lippert to get you started.

  • Make a list of past trouble spots and the techniques for finding them, you will see the trouble spots repeatedly.
  • Use linting tools to help you identify the simple but hard to find problems, for example in javascript
  • Write the code with the idea that there will be problems, add debugging output to console.log (or wherever) so you can analyze intermediate steps. Use the language built in error catching syntax.
  • Solve the problem in your native language, ie write the documentation first. The algorithm is the solution, the code is the translation of the solution into a language that the computer can process. With a pen and paper draw a graphical diagram of how all the variables and processes relate, then write the code (with the documentation included).
  • Use the built in debugging tools in your development environment.
  • Get some rest. Work on something else for a few minutes. Weed in the garden, take out the trash, do a few minutes of exercise. Think of the problem while you are not looking at the computer screen. Sometimes the problem is not the code, but they way you are putting the pieces together, ie first in last out, last in first out, pop() vs shift(); but not both.
  • Write your question in such a way that is does not sound humiliating.
    • Here is the:
      • code
      • inputs and expected outputs
      • the unexpected output
      • the troubleshooting techniques applied
      • researched answers that are similar
      • all the ways to show that you did not give up in the first 30 seconds, that you have done your homework and that you deserve the time of your fellow programmers!
  • Use test-driven-development techniques and frameworks.

#16

I humbly second the nomination. Awesome quote.


#17

Haha, Jackson is 100% correct. The coding gods are cruel, and I’ve had that happen many time too. I agree that you’ve got to reframe the way you’re thinking about it… no one is born knowing how to code and you’ve got the guts to make mistakes, ask for help, and keep trying. Those are three wonderful qualities to have, and will get you far. :slight_smile:


#18

It took me 3 hours to figure out the first lesson in the Bootstrap syllabus, but once I took a break, reread my code from top to bottom, reread the challenge, I figured it out. Sometimes its not as difficult as we make it.


#19

Sometimes short breaks work like MAGIC.


#20

I’ve been coding professionally for many years. I STILL occasionally benefit from “a second set of eyes” on my code especially when I’m learning new things. That constant change in technology is what keeps it challenging/interesting/fun. There are only two mistakes: not doing your due diligence in researching yourself and not asking for help when you can’t figure it out.