Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie

Do you ever get really stuck on a problem or exception?

Options
  • 07-05-2013 10:20am
    #1
    Registered Users Posts: 40


    Yesterday, I was trying to figure out the <resources> tag in Spring MVC. I couldn't figure out the location and mapping attributes of this tag, and I was putting the .css file that I wanted to use in the wrong folder. I fixed the problem, but it took me quite a few hours to figure out what I was doing wrong! The solution was quite simple, and I can't believe I didn't see it!

    I'm just curious if any developers have experienced similar situations, where you got stuck on something and it took a while to figure it out.


Comments

  • Registered Users Posts: 18,272 ✭✭✭✭Atomic Pineapple


    It does indeed happen to me sometimes, especially in the early days, less so now as my knowledge base increases, sometimes I found I got stuck, asked a question on Stack Overflow and then a few minutes later realised my mistake before needing any help! :D

    I think its all part of the learning process.


  • Registered Users Posts: 26,558 ✭✭✭✭Creamy Goodness


    I find this happens to me, less and less as I become more experienced (8 years now writing software).

    as draffodx said, I'll usually realise my mistake if I start typing up a stackoverflow question or explain it to someone in the office.

    get yourself a rubber duck for your desk, and explain line by line to the duck. It works most of the time :)


  • Registered Users Posts: 2,021 ✭✭✭ChRoMe


    razor2013 wrote: »
    Yesterday, I was trying to figure out the <resources> tag in Spring MVC. I couldn't figure out the location and mapping attributes of this tag, and I was putting the .css file that I wanted to use in the wrong folder. I fixed the problem, but it took me quite a few hours to figure out what I was doing wrong! The solution was quite simple, and I can't believe I didn't see it!

    I'm just curious if any developers have experienced similar situations, where you got stuck on something and it took a while to figure it out.

    Stackoverflow.com is your friend :)


  • Registered Users Posts: 2,019 ✭✭✭Colonel Panic


    A rubber duck or cardboard programmer helps. Sometimes I'll by 1/2 way through typing a question on StackOverflow and work it out.

    Failing that. Taking a break and distracting yourself is helpful. Often, the solution will sneak up on you.


  • Moderators, Sports Moderators, Regional Abroad Moderators Posts: 2,639 Mod ✭✭✭✭TrueDub


    as draffodx said, I'll usually realise my mistake if I start typing up a stackoverflow question or explain it to someone in the office.

    get yourself a rubber duck for your desk, and explain line by line to the duck. It works most of the time :)

    Amazingly true - the discipline of trying to explain your issue either in an email or to another person/entity makes you think about the exact issue, and frequently causes you to approach it from another direction.

    Alternatively, a little time away from the problem might reset your thought processes.


  • Advertisement
  • Registered Users Posts: 6,464 ✭✭✭MOH


    I find this happens to me, less and less as I become more experienced (8 years now writing software).

    as draffodx said, I'll usually realise my mistake if I start typing up a stackoverflow question or explain it to someone in the office.

    get yourself a rubber duck for your desk, and explain line by line to the duck. It works most of the time :)

    This. I've probably got more abandoned than actual posts on StackOverflow, due to realising the solution as soon as I try to coherently write it down.

    It's funnier in reverse - the number of times someone's come up to my desk to ask for help on something, explained their problem, realised the issue, and gone away immediately, thanking me for helping them fix it while I'm still trying to work out what they're on about. :)


  • Registered Users Posts: 16,402 ✭✭✭✭Trojan


    Every developer gets it sometimes.

    One time I worked only with another developer, just the two of us on the team. She was several years my senior, and supposedly tasked with training me up as I was a grad. Unfortunately she used to get very irritated with me asking questions, so after just a couple weeks on the job I stopped asking questions. Working through problems on my own with books & the limited online resources took a long time, and I know that my output was a fraction of what it should have been because sometimes I was stuck weeks on a problem.

    Consequently I try and ensure that every developer I work with, particularly junior folks, knows that it's ok to come by with questions - unless the door is closed and the phone on mute.

    It's a good idea to set a time limit on working through a problem so that after, say, an hour stuck, you go looking for help. It keeps productivity up and managers happy, and co-workers shouldn't mind if it's not the same thing over and over.


  • Registered Users Posts: 26,558 ✭✭✭✭Creamy Goodness


    Trojan wrote: »
    It's a good idea to set a time limit on working through a problem so that after, say, an hour stuck, you go looking for help. It keeps productivity up and managers happy, and co-workers shouldn't mind if it's not the same thing over and over.

    This is probably the best advice you could give a newbie coming into the world of professional programming.

    1. try and solve it yourself.
    2. if not ask questions.
    3. try not to repeat asking same question too much.

    Fresh eyes will always spot the solution/problem before tired eyes be those eyes your own (after a break) or a co-workers.


  • Registered Users Posts: 30 Lector


    This happens to everybody from time to time, especially if you're getting into something new.
    As one or two other posters mentioned, the frequency goes down as you get into your comfort zone
    (but it can strike even there, as we all know to our cost )
    The only advice I can give has been given before:
    - Try it (really try it!) yourself - RTFM as a last resort :-)
    - Talk it over with a colleague - someone more experienced, for preference
    I wouldn't talk it over with the rubber duck unless you're alone in the office :-)
    - Post to a relevant website - lots of experienced people out there


  • Registered Users Posts: 16,402 ✭✭✭✭Trojan


    Knowledge of tools (IDEs) and debugging methods is crucial. A couple days spent learning how to debug early in your career will pay itself back in less than a quarter.


  • Advertisement
  • Registered Users Posts: 1,082 ✭✭✭Feathers


    No, never ;)

    Seriously, as everyone mentioned above you'll find it a lot starting out but the simple ones should hopefully diminish.

    Two things I'd suggest - get yourself a good IDE that'll catch the small stuff. Sure we should all know the silly mistakes, but its the equivalent to spellcheck for a writer, second pair of eyes.

    Secondly, if you're starting something new (e.g. using an API you haven't used before) TDD can be a great approach. Sometimes these bugs happen because you expect someone else's code to behave one way, but under certain circumstances it does something different.

    TDD can help you document your assumptions as you go & drive out edge cases at a unit level rather than when you've everything knitted together.


  • Registered Users Posts: 6,464 ✭✭✭MOH


    Feathers wrote: »
    No, never ;)

    Seriously, as everyone mentioned above you'll find it a lot starting out but the simple ones should hopefully diminish.

    Two things I'd suggest - get yourself a good IDE that'll catch the small stuff. Sure we should all know the silly mistakes, but its the equivalent to spellcheck for a writer, second pair of eyes.

    Secondly, if you're starting something new (e.g. using an API you haven't used before) TDD can be a great approach. Sometimes these bugs happen because you expect someone else's code to behave one way, but under certain circumstances it does something different.

    TDD can help you document your assumptions as you go & drive out edge cases at a unit level rather than when you've everything knitted together.

    Table driven design? :D


  • Moderators, Society & Culture Moderators Posts: 9,689 Mod ✭✭✭✭stevenmu


    Like others have said, I get stuck on issues less and less as my career has gone on. I've been a developer for about 10 years now and I'd rarely find myself getting stuck on technical issues. I've developed a sixth sense for tracking down bugs, as soon as I hit one, I usually know what the cause is before I even look at the code or try to debug. And when I'm working with new tools/APIs/platforms I can find my way around them with ease.

    Mostly this is because of all of the stupid mistakes I used to make, and all the long hours I put in to figure out how to do something that is now easy.

    I still do get stuck sometimes, and often on stupid stuff. Earlier this week I got stuck for most of a day with a bit of code that was generating emails from templates. I forgot that the templates had a plain text section and a HTML section, so my code was inserting the content into the plain text section only, but when I would view the email in Outlook I was looking at the HTML section only, so it looked like my code did nothing. Que hours of stepping through the code line by line wondering why it looked like it was working but the end result was all wrong.

    Stupid, but luckily that kind of thing happens less and less.


  • Closed Accounts Posts: 1,235 ✭✭✭returnNull


    I've learnt loads from stupid mistakes that i have made.They stand to you when something similar happens you'll track the bug down quicker.

    Some times when the output isnt right,I've spent hours looking at the code,the logic seems fine :D, i leave it for a few hours and then come back.I've also had eureka moments when its occurs to me whats wrong so I leg it to the pc,power it up and fix the bug:pac:

    also I regularly did this
    if(isTheCoderADumbass = true){ }
    
    instead of
    if(isTheCoderADumbass == true){ }
    
    :o:o


  • Registered Users Posts: 26,558 ✭✭✭✭Creamy Goodness


    I used to do that too, until i realised...
    if (isTheCoderADumbass == true) == if (isTheCoderADumbass)
    

    and that
    if (isTheCoderADumbass)
    
    - and -
    
    if (!isTheCoderADumbass)
    

    read better.


  • Registered Users Posts: 3,078 ✭✭✭onemorechance


    I think that the time of day makes a big difference too.

    Unless there is a deadline, I find it's better to leave a problem until the next day rather than stay there all evening looking at it.

    So often a problem or bug being looked at from 4pm to 6pm would still not be solved if I remained until 8pm, but with a fresh and rested mind, is solved in two minutes in the morning!


  • Registered Users Posts: 4,758 ✭✭✭cython


    returnNull wrote: »
    I've learnt loads from stupid mistakes that i have made.They stand to you when something similar happens you'll track the bug down quicker.

    Some times when the output isnt right,I've spent hours looking at the code,the logic seems fine :D, i leave it for a few hours and then come back.I've also had eureka moments when its occurs to me whats wrong so I leg it to the pc,power it up and fix the bug:pac:

    also I regularly did this
    if(isTheCoderADumbass = true){ }
    
    instead of
    if(isTheCoderADumbass == true){ }
    
    :o:o

    Very simple way to safeguard against this is to reverse the order of the comparison, and put the immutable value on the left so that you should get an error, i.e.
    if(true == isTheCoderADumbass){ }
    
    Obviously this more intended for non-boolean comparisons, whereby Creamy Goodness' suggestion won't work, but just rearranging the example given for illustrative purposes.


Advertisement