Help me...

I decided I wanted to try something new with Unity (I know I said I wasn't working on anything) just for the heck of it literally last night.

It wasn't long before a feeling kind of came to be. Its an old and really irritating one. I get bored, frustrated, and really really sick of the task at hand.

When I do my coding I do it one keystroke at a time. I know this is possibly the most inefficient and wasteful thing you can do as a programmer. What might take someone who carefully planned out their code twenty minutes to half an hour might take me one whole hour.

I really dislike debugging. I once told an instructor this and his response was "maybe you're in the wrong field".

I disagree. The problem with debugging (I know its a crucial part of coding) is I'm much too impulsive to piece everything together to find out whats going wrong. A key part of that equation is the damn wireless mouse I use. I can't help myself from clicking constantly (and pointlessly). It takes serious mental concentration just to figure out how my Linked List is fitting together (or not). I understand the concept of a LL well enough, but I don't plan things out as much as I could and combine that with impulsive behavior and you have a difficult time debugging.

I guess I'm saying that I'm burnt out with coding. I still love it, like I do gaming. Though the feeling I used to get with both has faded. Its been replaced by this "burnt out" feeling. I feel I've achieved mastery over the general activity of programming. I can write and read code like a second language. I think that's the source of my frustration. I'm not learning anything new.

I spent what could have taken me 20 minutes, like an hour last night implementing a FreeCam script. All because I was too impatient, impulsive, and I just typed the code out one keystroke at a time (no planning). There came a point where I realized this had happened. I thought "A free cam is easy enough I can knock out perfect code in a few minutes without any planning" which is precisely what did not happen. The code came out really good imo, but it didn't happen quickly or without frustration.

Does anyone else have this problem? Any advice?

I wanted to add; I've always thought that I enjoy the act of typing the code out. At least, until this problem sets in. I think a good solution would be to think that I enjoy the act of solving the problem instead of typing it up.

 

Why are you trying to implement linked list? It is only useful to do when you want a training exercise. If you want to get something done, you use standard containers UNLESS you run into serious and unsolvable problem with them...

Anyway.

I do not have the problem and never had.

If you think it is a burnout, then spending a month or a few in nature, preferably with all the electronics turned off. You can also visit a professional to get diagnosed for depression.

In my experience the general activity of programming is designing systems, not writing things out. Initial prototyping rush - where you just type, type, type, type doesn't last long, and then you'll be stuck in situation where you have concepts/abstractions implemented, systems and subsystems that use each other and talk to each other, and you need to keep redesigning the whole thing withotu breaking it. This is the core of programming.

If you haven't worked like this,this is something you should probably learn. You move to the system level somewhere around the moment when your program size surpasses around 200..300 kilobytes, because at this moment you'll be no longer able to keep everything in your head.

Even if love for the programming wears out, you should still remain ambivalent about it and should be able to program when money is involved.

If you can't do that - then there's still "month in the woods" option.

 

You don't have a comfortable work desk and work room is the 1st improvement you can make. To get interested in the task at hand you may find you need cut off television, music, and other disruptive activities.

Once you are comfortable and bored, I find that even counting flowers on the wall can be entertaining so doing activities to create a game in Unity will seem very interesting indeed. When you are not comfortable and bored...well you know how that goes already don't you?

If you find yourself surfing the net you are letting yourself be distracted. I know the temptation to do that is great because I've tried to use Unity's offline webbrowser manual too and while it is good, the navigation in it and waiting for the chosen manual page to load is absolutely poor in the extreme. I'm surprised big businesses that pay mega bucks for support contracts aren't all over Unity about that. No way should it be taking 1 - 5 minutes for an offline HTML manual page to load like it does which Unity's manual pages.

 

If Unity's documentation takes that long to load for you then that's a problem on your end. It loads near instantly for me even on my Mac Mini. On my PC it's even faster.

 

I'm reminded of a certain Southpark episode (the full thing is well worth the watch, here is only an excerpt):

It describes pretty well how I start to feel about many things in life, as I grow older.

 

Ever stop for a moment and think he's right? Programming is not for everyone. And it certianly sounds like you have all the symptoms of someone who doesn't have the mind set for it.

I'd strongly suggest detoxing. Step away from programming for a while. Learn something new. You may find a much better vocation is out there waiting for you.

 

I mean check out ughhhhh unreal its got visual programming blueprints

 

I love debugging, except when the debugging becomes wrong. Errors that aren't supposed to be there but they are mysteriously, just to find out I had to just restart Unity/Mono after spending hours of debugging non-sense that wasn't even real on my end lol.

 

Drawing is a cool skill to try.

 

Unfortunately for myself, I had to take my computer in for repairs recently. It forced me to take 4ish weeks off (repairs company had issues with suppliers, long delays. It was horrible).

Since I have restarted work, I have been on fire and am seeing my project in a different light.

I suggest taking a break from programming, not to quit, but let other things occupy your time for a short period.

 

Besides what everyone else said, just make damn sure you're going somewhere with what you're doing. There's nothing like wasting weeks/months aimlessly doing random stuff, with no progress to show for it at the end, to sap your motivation and give you all sorts of mental barriers you have to then figure out how to remove. Everything you do should be toward a goal, and if that goal is too far and hazy pick a nearer one.

Game dev, especially solo, needs some serious discipline - it is seriously lacking in fun for a large part of the time. I've already heard many stories of devs' mental issues/depression and it's something to really watch out for and avoid. It's a long, lonely grind and clear success comes rarely. You really have to be raring to go in my book if you're going to have any chance of getting past all of that, and it doesn't sound like you are.

And just remember, although we might not like to think about it sometimes - there's a huge world out there full of opportunities for anything you could want in life, and games are ... well, just games. If you're doing this as a substitute for a meaningful life, get out as fast as possible and count yourself lucky to have done so - you don't want to waste the precious time you've got on this planet pretending you're having fun.

 

I'd argue just the opposite. I love this S***. Its just parts of it which aren't fun for me due to the problems with impulsiveness and not being able to piece it all together. If unity actually had a decent debugger I may be better at it... trying to debug using print statements works, but its not the best if you'd like to learn how to use a debugger.

Also I'm a pretty good programmer. Its just that I have trouble with the impulses.

 

Unity HAS decent debugger. Put breakpoints, walk through subroutines, examine variables, and create watch list, even when debuggin android game from pc. Just attach to process from MonoDevelop/VisualStudio, you can also configure it to break on exception.

It is pretty much standard set of functionality i'd expect a debugger to have, and there isn't much to add to it.

 

Seen this?

https://unity3d.com/learn/tutorials/topics/scripting/debugging-unity-games-visual-studio

 

???

I would perhaps suggest a professional clinical diagnosis.

 

I have. I've actually used it but many times it just doesn't work. Haven't tried it recently and perhaps it will but IDK.
It won't attach to Unity or anything sometimes. I dislike trying to troubleshoot things like that. Its pain in the ass.

 

In this case the best idea would be to get the debugger properly working. While it is entirely possible to debug software by reading its output logs, you usually need a good reason to do that instead of using the debugger.

I think monodevelop used to have some problems attaching to editor (as in, you needed to try attaching several times to get it to work) in past versions of unity (5.2 or 5.1), but that doesn't seem to be happening with 5.3 release. Update to 5.3 and try again.

 

Maybe your instructor was right then if nothing seems to be working and/or everything is a pain in the ass to work with. For most of the people the debuggers work fine and are very productive way to solve problems.

 

This is very true. Although I am one who has sworn by Print (in it's various forms including writing out log, Debug.Log in Unity, Message.ShowBox, etc) for decades as a very efficient way to debug... even I have always taken advantage of Breakpoints and Watches since the VB6 days.

It's a very powerful feature that I think any programmer should make use of. Up until now I hadn't used it Unity because previously it never worked when I tried to manually attach to the Unity process. However, in the VS Community 2015 version they have added more direct support for attaching to Unity and it actually works! That is a beautiful thing which should further accelerate my game development.

 

I love debugging, it helps teach you how to think.
At least it does me. I get an error, don't know why, I learn why the error is happening and makes me smarter for next time.

 

Or to put it another way... it teaches you why your first attempts were doomed to failure.

 

Absolutely agree. You (at least me) end up programming sort of defensively. Since you've run into bugs in the past and know what not to do and better yet what to do.

 

Haha yeah....

I don't know about any of you.
But at times I find my self making noobie mistakes. like if I make an if statement I'll at times treat an int as a bool.
if(int a = int b){ } I sometimes forget the extra = lol.


@GarBenjamin : Yup I do get defensive. I actually lost a job once because I was defensive and knew what I was talking about LOL. Can't stand butthurt people, I knew 100% for a fact I was right... Don't remember what it was about, but I remember the occasion lol.

 

Just think of debugging as solving a puzzle. You're trying to follow the clues and be led to the target. Each clue should bring you closer, but you have to be able to figure out its meaning. It's like a fun puzzle to solve. It's like one of those games where something is hidden somewhere, and you have clues scattered around that ultimately lead to it. You find one and it leads you to the next, and on and on until you find the destination.

That's how I do it.

 

"Lost a job due to being right in a defensive argument, still can't remeber what the job was about".
Nice one.

I think Gar was talking about Defensive Programming, though.

 

So why don't you start approaching it this way? You've described a bunch of aspects of programming that you don't like, and you've described your approaches, and the latter leads directly to the former. You're also asking about how to make things better, so you're (hopefully) willing to make changes - because if you don't then nothing will be different.

So... how about starting by planning your code instead of doing things "one keystroke at a time"? Figure out what a script is meant to do. Figure out an algorithm that achieves it. Work out how to represent that algorithm in C# / Unity. Then that leaves you with the bit you said you like - writing out the code - and hopefully minimises the stuff you don't like - debugging - by forcing you to think through the whole problem before writing code.

Note that it won't eliminate debugging. That said, these days I do fairly little explicit debugging while writing games. I find that if I planned things properly then I can see immediately what part of the plan isn't quite right when I test things and see incorrect results.

Note that I'm not necessarily looking for bugs in the code, so much as I am looking for flaws in my solution. That usually makes it pretty easy to spot that either "oh, my algorithm doesn't actually cover this properly" or "hey, I didn't write the code for this bit properly". And once you know one of those things the required code changes often either "fall out" of the updated solution or jump right out in your face because you knew roughly where to look (and, with experience, also what to look for).

Personally, when I'm writing something new I fill it with log messages that let me know what input was received at each decision point and the resulting decision. This means that when I do my test runs I see not only the output, but also how it got there, which I can compare against my expectations. For code that you can run and test early an often you should, because this will cut out huge amounts of debugging later - the earlier you catch something the less code there is for it to come from, and thus the faster it will be to find. It'll also make flaws in your solution evident earlier, meaning that you are aware of and can fix flaws before you follow them too far.

With all of that, for me I usually only end up going for the debugger for really subtle stuff, or for things I managed to overlook in a part of the code I'm no longer (or never was) familiar with.

(Be disciplined about removing or commenting out the log messages once you're done, though. Nobody needs that spam when they're working on other parts of the project!)

 

I'll say that I've been here. I grew up as an artist, but it took an undergraduate computer engineering degree, many trials, and many declarations of quitting altogether to fully grasp how to effectively "understand" and how to "appreciate" programming. I've always had to remind myself that, programmers think that typing up all these systems automate processes, because they're actually lazy. It doesn't make sense at first, it's counter intuitive, because there's so much pain into typing out so much for so little reward. But the more you keep going, the results and small successes compound on each other, because it's a success you keep forever, and reuse for every future experience.

As for debugging, well, I've dealt with debuggers in a handful of IDEs, and Visual Studio's debugger is one of the most powerful, visual debuggers that you can have at your disposal. If you are not enjoying the act of debugging, then you have to get over that hump somehow, or your instructor is actually probably right about this not being for you. The act of debugging is the act of problem solving at a smaller level. I know you think of it as a "step back", an "inconvience", and "why doesn't this work, because I have bigger fish to fry", but I've seen really talented, experienced and passionate programmers see this as "an opportunity to solve a more complex, challenging problem", "a small mountain to conquer", like cracking open an electrical conduit, figuring out what's wrong with the wiring, fixing it, and restoring order, or power to the rest of the system.

And without having the traditional education of learning software engineering, it becomes especially more difficult. In Software Engineering courses, they teach you about gathering requirements, assessing risk, writing test suites, debugging and QA (which is not just "using the software", but systematically testing out all code paths for proper operation), and generally, how to use the scientific method to your advantage. But if you've gone through this particular education, I'd recommend reviewing it all and understanding why it's so important to the software development process.

So, I'll reiterate the key takeaway here. The programming/engineering mindset is, if you run into a problem, see it as an opportunity to fix it to get it in working order, like a doctor helping triage patients. It doesn't help to think of it as an inconvenience and a step back towards your plans.