I’ve only been doing unity on and off for about 10 months, coming from a background of no coding experience.
I cant help but feel sometimes like i’m just not getting it. I’ve wrote a script today for my basic inventory in my game and I can’t help but feel its just a bad way of going about it.
Anyone else ever feel like that? I think because I don’t fully understand everything I just feel like I’m making a meal out of nothing. I understand variables, access modifiers, loops, etc, but admittely struggle with things like delegates.
How long did it take you to feel like you were writing code that you could actually show to people and feel confident about it?
Edit: Just one point, I DO feel a buzz when I get something working, however basic it does give me a bit of a natural high, despite it probably being ridiculously bad code haha.
I learned to code online and here’s how it went for me.
I didn’t have a clue what I was doing at first, kind of like you, feeling like I didn’t know if what I was doing was right or wrong. For the first year and a half-ish, it was about getting things to work.
The more I coded, the more I had to look up stuff online, the stronger my grasp of programming concepts in general became.
For a long time, I wished I had formal education, someone that would confirm if what I learned was right, or wrong. Now I feel good about my abilities. I’m no wizard, but I feel like I can tackle some decent challenges and I feel comfortable when there’s programming talk.
So, in my opinion, I sincerely don’t think that formal education is mandatory (certainly not saying it doesn’t help). Experience will take you where you want to get. I recommend creating a good balance between having fun and learning. That will keep you going and as the time passes, you’ll become better. Also, try to stay out of your comfort zone.
When I look back at the code I made a year or two ago, I see all sorts of inefficiencies and errors. Regular practice and research has taught me all sorts of new techniques and approaches. I’ve been exposed to different ways of thinking about the structure of my code. The code I make today is much cleaner. I imagine the code I make a few years from now will be better still.
The one problem with this is I am constantly tempted to go back and update my previous projects. With my improved coding, I always want to return to my past projects and re-construct them with my new skills. But you can’t spend all your time refactoring. So I have to pick and choose my battles.
I didn’t really ever feel this way because I started programming as a kid, and progressively switched to different computers. So it was always about having “let’s take a clock apart see how it works and put it back together!” kind of fun, and not wondering “am I good?”. If I don’t know something, I can usually look it up. Some thing may take time to understand, some things may take a LOT of time to understand, but the general impression is that if I sink enough time into anything, I’ll inevitably start to understand it.
I think this kind of attitude is not correct.
Any program will ALWAYS have bugs and ugly portions in it.
The main question is “does it work”? If it does, you can show it. If it doesn’t you can also show it. In either case you’ll get some recommendations regarding ways to make it better.
@ADNCG That’s great to know that it took you a while to until you felt really comfortable with it. I remember when I learnt the what a class actually was and it wasn’t until about a week into it that I actually grasped the concept, despite me knowing what it actually was and being able to make instances of a class. Its almost as if something literally clicked one day that I actually understood what I was typing.
@RichardKain I might actually do that you know. Revisit past projects and try to re code them, that sounds like a really good exercise. Like you said there’s only so much time in the world to DL these things bit might really make a difference
Thanks man, This is definitely the best way to think about it. I guess I just feel not very confident with my skills at the moment. Hopefully this changes with time XD
This is a separate question from good code. I’ve shown people code from day one. If its bad code, people will offer improvement suggestions. If its good code, people will borrow ideas from it. Remember, your code is not you. People criticizing, slagging or praising your code says nothing about you as a person.
Does it get the job done? If so, save it and move on. You’ll learn more this way then by agonizing over every last detail.
Not really. I’ve always been mildly arrogant about my abilities.
I’d encourage you to keep going. I’ve seen many people who are new to the programming try to learn how to code (mostly Java, which is a very similar language to C#). And it seems that they usually take more than a few years to become somewhat proficient in the paradigm.
I’d also suggest that try to do a lot of small projects for practice and read variety of materials available on the internet. Things like object oriented modelling cannot be learned without actually spending quite a lot of time practicing it. And you might need to be aware of certain types of tutorials, because they put too much emphasis on how to make something done and do little in explaining why it does.
I observed that many of those beginners in programming who struggle have grown a bad habit of skipping the ‘why’ part and being impatient to search for such tutorials and sample codes that show them ‘how’ to do some fancy things.
So, if you find some concept like delegate, as you mentioned, a bit hard to grasp, I’d suggest just taking sufficient time to fully understand it before moving on. There are quite a lot of articles, documentations, tutorials dedicated to make people understand what delegates do, for example, so if you are patient and know how to find them on the internet you can probably teach yourself to become a competent programmer without any formal education these days.
I am in a similar boat as you. Before the summer of 2016, I have never coded in any programming language nor used any game engine. I started following and doing the Unity Learn Tutorials on the website. At first, I was very overwhelmed about scripting. However, the most important thing now for me is to take my time to learn scripting. Taking my time to understand the concept and then doing on hands-on practice for has been very helpful. In addition, because I learn best by doing, I focus on actually practicing coding by doing completing small tasks that I want to accomplish.
Many times, I have felt frustrated that I haven’t mastered scripting or quickly understand several programming concepts. Often, I have felt the desire to quit or give up. That is when I remind myself to be more gentle on myself and to be patient with the learning process. It’s awesome that you are coding in the first place, I have used Unity for 1 year, and I am a beginner with coding. However, with time, practice, and plenty of failure, I am learning and getting more and more comfortable with scripting.
I would say to be patient with yourself and continue to learn about it. Something as complex and comprehensive as a programming language takes a ton of patience, persistence, practice, and time to really master the fundamental concepts.
One of the big things for me in my journey to becoming a good programmer was realising that I don’t have to write perfect code. In my early days I tried to do things “right” and as a result didn’t end up doing very much. As soon as I noticed a flaw I’d try to fix it, which resulted in slow work at best, and didn’t necessarily improve quality because I’d be changing designs on the fly and didn’t actually have a honed sense of what a “flaw” really was.
At some point I gave myself permission to write dodgy code as long as it “got the job done”. This came with the caveat that I had to learn from the resulting flaws and apply what I learned to future code. I ended up getting stuff “done” faster, I felt better about it because I was no longer aiming for perfection, and the learning cycle ended up being much more effective.
So if anything, that’s my advice. Don’t worry about writing “bad” code as long as it’s working code. (And I mean properly working, not a cludgy house of cards that dies at the merest change.) If code works properly then don’t try to go back and “improve” it unless there’s a practical benefit to be gained from it. But make sure that whenever possible*, each piece of code you write is better than the last and doesn’t repeat old mistakes.
I say “whenever possible” because the reality as a professional/commercial programmer is that sometimes you need to prioritiese short term goals over long term ones, often resulting in pretty rubbish code! The thing is, rubbish code that meets the deadline is practically more beneficial than good code that does not.
Also, 10 months isn’t long. From my perspective, I wouldn’t at all be worried about “not getting it” after having put in “only” 10 months across all of a new set of tools, game dev in general and programming in general. I’m not saying that 10 months is a small effort - far from it! It’s that there’s a heck of a lot to learn there, and 10 months spread between them is really only getting started in the grand scheme of things.
I suggest exposing yourself as much as possible to other people’s code. I’ve learned a lot - not just programming as such but also nifty things that you can do with Unity’s API and editor tools - from looking at other people’s projects as well as stuff from the asset store.
Even a couple of years into programming, things like delegates, coroutines - I knew what they were but never really used them until I saw some people’s projects and thought “OK, that’s definitely a useful thing to use in that situation”. And I would make a point of using it in one of my own projects in a similar situation - and sometimes binned it straight after as it caused me more problems than my original approach.
The problem with other people’s code is that it can be very ordinary or even substandard, but still appear much more attractive - it’s like if someone makes you a sandwich from whatever has gone stale in your fridge, it tastes 10x better than anything you could make yourself from the same ingredients. Which means that really, you just have to develop a critical view of everything and test it against logic and its success in achieving its intended purpose. Ideally, code should simply work, not cause performance issues to the project as a whole, and be fairly easy to understand. If it ticks these boxes, everything else is irrelevant.
One more thing I would say is - you say you ‘feel like it’s a bad way of going about it’ - listen to that and try to figure out why you feel that way. Some things in programming are simply unintuitive by nature and you have to accept that, but design-wise it’s a red flag and a good opportunity to say “OK what would the ideal architecture/code look like” and then poke around on the internet or in a book for something that you haven’t learned about yet, that does it the way you expect that it could be done.
Only slightly when looking at older code, but even then I understand why I wrote it the way I did. My oldest surviving program dates back to the late 90s and has some amusing mistakes, but it was my best and it did the job it needed.
At least until I ran out of memory for the actual game portion. QuickBASIC had very tight memory limits.
Meh I’m sure my coding sucks, but it seems to work and it doesn’t hog performance… So in the grand scheme of things, couldn’t really care. It only becomes an issue if you’re applying for a job…
There is an anecdote about pottery students. I have no idea if its true or not, but it certainly fits for programming.
In the story two pottery classes were given different assignments. The first was told to spend the entire semester working on a single masterpiece. They were to do everything they could to make one perfect piece. The second class was told to make as many pieces of pottery as possible during the semester.
At the end of the class the one piece pottery group had a single piece of work. It was fairly mediocre, but a passable piece. The many pieces class had made a lot of rubbish at the start, but by the end of the class they were producing master pieces.
The general take away is that when learning a craft its more efficient to practice many times then it it to get things right once.
Something that irks me about a few of the opinions already stated is yea, you can be a pretty skilled self-taught programmer…
…but it usually leads to utterly horrendous habits and mindsets that can be hard to break out of. Everyone else is doing it, so you pick it up. cough StackOverflow. Unfortunately I suffered from the same habits as I was self taught through highschool, until I took a CS course and they beat it out of me.
Partly I think it’s just due to being a relatively new field from a global standpoint (computers as we know them were only really made last century), so there’s still massive conflict about paradigms, standardisation, convention, the whole OOP vs Procedural thing… Other fields like accounting or biology go back centuries. The roots of agriculture and structural engineering go back millennia.
