|
UNIX - The beginnings
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
|
Lassie returns
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
|
Superdog
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
101 Dalmatians! Now that's an awful lot of crap
|
|
|
|
|
Finding Nemo!
Regards,
Palash
|
|
|
|
|
Some tennis advice to the English football team (3,5,6).
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
|
Isn't that should be in the Soapbox? 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Good man i thought I'd inject some lightheartedness into a troubled UK - you are up tomorrow.
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
I've got a clue lined up that I quite like, but I'm not 100% sure it fits the standard CCC rules. Would anyone care to take a look at it for me via PM to check? Obviously this would rule you out of tomorrows CCC  .
Andy B
|
|
|
|
|
Yes no problem - todays one probably doesn't conform either 
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
So I've recently surpassed the "basics" of learning programming (been using C#) and I've now been taking my knowledge and getting creative by making all kinds of cool little apps - from web browsers to gag joke apps, to apps that monitor system performance information... I've really gotten "hands on" with coding now and mostly the challenges I face come up when I write my programs trying to figure out logic and debug and also trying to discover new functions/methods and APIs...
Speaking of APIs and libraries (namespaces, etc...), I've noticed they are an entire different learning curve. Not only must one know the actual language, but he or she must also have a working knowledge of APIs and libraries or else the language knowledge won't mean anything.
Anyway, so I want your input on learning and growing as a coder... I have more patience for coding than I do anything else in my life. I will literally sit for like 12 hours if I have to just to get something worked out. I can't say that about anything else. However, there are certain logic issues that I run into that take me like 2-4 HOURS to solve at times, and sometimes the problem is painfully simple, I just couldn't see it to begin with.
Is this pretty typical for a new coder or coders in general? I don't have a ton of experience being around other new coders so sometimes I wonder if that's normal or if I'm just a wreck.
It's pretty easy for me to follow along in coding books and watch tutorials on Udemy and YouTube and understand everything, even when it comes to so-called "advanced" concepts. However, it's when I put all that stuff away and it's between me and Visual Studio that sometimes I get stuck... And sometimes I don't want to quit and I will stay up all night trying to figure out what ends up being a simple problem that can be fixed in a line or two of code.
I figure this is how the job probably really is, except with much more advanced problems. However, I do still enjoy coding. It's fun to work out the bugs. Your advice/insight is appreciated. Thanks.
P.S. Is there any standardized way to improve at debugging? I'm still trying to learn my way around the VS debugger.
|
|
|
|
|
I think you are going the right direction. Just keep learning from the mistakes. 
<sig notetoself="think of a better signature">
<first>Jim</first> <last>Meadors</last>
</sig>
|
|
|
|
|
TheOnlyRealTodd wrote: Is there any standardized way to improve at debugging?
Knowing your tools and getting your hands dirty.
|
|
|
|
|
TheOnlyRealTodd wrote: that take me like 2-4 HOURS to solve at times
This can be normal and in professional environments it can be quite longer. However I would also like to add an anecdote from my past experience:
I was coding on an application containing a matrix of results and somehow the results where one of in this case, correct in the other and again wrong in a third case. After 13 hours of straight programming the letters on my screen started to turn green and started to move around. My queue to stop working (it was 21:30 and I still had to go home). The next day I came in and started working again. It took me literally less than 5 minutes to solve the problem.
Moral of the story: Dare to put a problem on the side, focus on something else and come back again later.
Keep up the enthusiasm
|
|
|
|
|
Go out-side step away from the code for a few minutes, explain the problem to someone, that someone can be a photo of Bill gates or your favorite bear or a real person who could actually help.
|
|
|
|
|
So many times have I started to explain a problem to someone and almost instantly figured it out as I was explaining the problem. I've known people who have completely scoffed off "rubber duck decoding" but it tends to work so well for me.
|
|
|
|
|
Never underestimate the power of the subconscious.
While you are walking the dog, enjoying a brewskie or lying in your bath the brain is still working away. When you come back to the problem it seems a lot simpler.
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
This is so true.
It's easy to get stubborn and not want the problem to defeat you, so you stick at it for hours, only to wake up the next day and the solution literally just pops into your head.
Also, the other points people have made about talking the problem over OUT LOUD, with either a person or by yourself. That works wonders too. Something about being forced to express the problem clearly - such that someone else can understand where you're at - frequently unblocks the issue in your mind and the solution presents itself.
"And when I have understanding of computers, I shall be the Supreme Being!"
|
|
|
|
|
What you will ideally need is a tutor.
That is someone who is a skilled developer and wouldn't mind occasionally have a look at your problem...
I think there is a tutoring program on CodeProject (with volunteers..) give it a go sometimes, who knows?
(I never did, so I don't...  )
|
|
|
|
|
|
Ha yes, that's the word!
|
|
|
|
|
You're doing the right things, so you should improve over time as the skills of design and debugging become more practiced.
It's often difficult to work out where to start on a complex problem, so sitting there for 2-4 hours isn't unusual: I've spent most of a week working out what to do before I've even fired up the editor (or Visual Studio). Sometimes that "thinking time" is the most important part of the project!
A couple of suggestions:
1) As has been mentioned, take breaks. I try to stop what I'm doing at least once an hour and do something totally different, as it "recharges my creative batteries" and stops me getting stale.
2) Never be afraid to say "this isn't working" and throw away an idea just because you have put effort into it. It's one of the hardest things to do, but sometimes we have to say to ourselves "this isn't going to work", or "that was a bad idea", even if we've coded most of it... 
3) Practice. Practice, practice, practice, practice, practice, practice, practice. And then practice some more! Development and debugging are both skills, and like all skills they only ever get better when you use them. Learn the basics of the VS debugger, and use them - ignore the complicated stuff for now - it's a "mind set" you need to develop, not an intimate knowledge of arcane debugging commands. Basic breakpointing, stepping into, stepping over, looking at variable contents is 99.99% of all I do with the debugger. It's also worth logging info (either to a log file, or the console) as that can give you a better "feel" for how code is running.
Keep at it - you seem to be doing pretty well so far! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
