Possessed but non-applied knowledge

Hey all.

Well as a C# hobbyist and aspiring "Programmer" I have decided it is necessary to prepare myself for university, although I program on a more hobbyist level, and really enjoy it. Just a bit of background information, I am an Australian year 11 student doing his HSC.

I have been trying to stay on top of my studies at school to supply more time for C# personal studies, and during this free time I study source code and attempt to learn new methods through any means necessary. This is what this post is about.

It seems that I understand the majority of concepts involving C# up to a fairly intermediate level including a level of generics, inheritance, polymorphism as well as some handy problem solving skills and a solid understanding of Advanced and Extension Mathematics. However, my problem comes when trying to apply said knowledge. I CAN apply it, but the majority of the time I see no need to and therefore revert to my old methods, an example of which are properties and delegates.

I will often just stick to fairly generic functions and my own made classes with inheritance and polymorphism and not apply my "better" knowledge.

So I guess as my own personal view of the matter, as some sort of perfectionist in my own work (which sucks), I always want to do things the best way, and will spend hours researching different methods, just to fall back on my old methods, and so the cycle repeats.

Write Code ----> Be unhappy with it, condemn it as useless compared to other people's ----> Research ----> Repeat.

Can anyone give any advice of how to break out of this rut? Tomorrow I am going to my local bookshop to buy 4 or 5 books on programming in C# to try refine my skills.

Should I spend less time writing and more time reading and learning? Or the other way around?

Thanks everyone
Myhi

EDIT : Also, are there any suggestions of any specific courses I should take at University? As right now I am looking at UTS : http://www.handbook.uts.edu.au/courses/c10229.html

 

Your attitude will change as you start to do more complex things, when you start trying to re-use code between projects, and as you start working in teams. Until then, it seems perfectly fine to do things the simple way*, but when you start doing really complex things and need others to understand them and they have to be extensible, then the complicated stuff starts to make sense.

At this point, I recommend you use those techniques just to practice them, but not in any projects you'll have to maintain. Part of being an expert is knowing when to use different techniques.

* In fact, I'd say it is perfectly fine to do them the simple way, unless you've got a compelling reason not to.

 

You don't understand if you cannot apply it. Try some real world design problem, post solutions and get feedback. Stackoverflow is good. IRC programming is good. You are also perhaps looking at the wrong books, try something on design such as Code Complete, or Clean Code: A Handbook of Agile Software Craftsmanship Good reads just don't believe all of it.

 

Emphasis added.

There is no single "best practice." You can't say that OOP is better than flat procedural code, or that Agile beats out traditional waterfall process, in all situations. Sometimes it makes sense to construct an elegant object model and class library to support endless refactoring/refinement over the course of years. Sometimes it makes sense to bang out the minimum to show the idea and land the contract. Sometimes you should start with clear requirements specifications from five different departments, and sometimes you can turn a prototype into a delivered project in a couple weeks.

 

Here's some advice, take it or leave it:

1. Save your money, don't buy books - learn to research (google) for the bits you need.
2. Programming in industry is becoming more and more about integrations - focus on this (web services, cloud, etc).
3. Don't get married to a particular approach to solving problems (TDD, AoP, etc), FORCE yourself to learn from each and treat these approaches as part of a warchest and not THE warchest.

What I'm reading in this is a very similar problem to what I had as a younger develop (omg, I can seriously say that now? ugh). Anyhow, back in the day I 'condemned' myself for not understanding VESA and instead using Mode 13h and the Turbo Pascal SWAG library as a crutch. Thing is, you're going to find there are things you'll be excel at and others you will not. So learn to deep dive on what you're good at, sell yourself using these aspects during an interview/contract negotiation. The weaker aspects, try to get a general feel and find a means of filling that gap but only as it becomes important. You want a lot of breadth of knowledge and only a few depth (dbms, webservices, etc).

My suggestion is this: pick a task (and I do mean TASK here) and implement it, finish it. So for instance, perhaps you write a general FSM and its really simple, maybe allow for plugging in behaviours on certain state changes. You release it, maybe for free and the worst comes to pass - nobody cares, or the few that do pan it etc etc...

Here's the thing:

1. You just completed a programming task, start to finish and it serves a function.
2. You're gaining experience in the non programming aspects of development (critical!).

and 3 ... a long time from now you'll be sitting in an interview and just might be speaking with yet another developer across the table who, like probably 80% of us, wanted to write video games at some point. You'll say, "Ya, I actually wrote an FSM framework for the Unity3D platform - it supported pluggable functionality and we used it to implement some basic combat AI ...". At that point the guy is going to think a few things, depending, but guaranteed at some level he'll be thinking "smart guy to dive into FSM .... AND the dude finished something ... AND capable of building solutions people can integrate/build over top of".

It'd impress me vs the usual barrage of "I R coderz with mongo!" we see of late.

Even if you move into business development or some partial technical role things like this build confidence in your employer/client and frankly, in yourself as well.

Good luck!

 

I served some time in the industry as a level designer.. The quality is kept at a mediocre level because the individual skill sets vary so greatly, they need the majority of the people to be able to do the work otherwise games would be completely inconsistent.. This pretty much applies to all the mediums. If your planning on working in the industry then you need to be able to do things their way... However, it's not a very productive way of doing things which means you need a lot of money and if your indie that can be difficult to come by. Utilizing simpler tactics is usually much faster and has the same end result but it WILL get you fired in the industry.

As for snapping out of simple mode and into industry mode, there's no tricks or advice- just do it and keep doing it.

 

I don't think your rut is so bad.
A lot of times people new to programming get enamored with stuff like OOP and generics and try to use them everywhere.
They end up writing massively complicated, over-engineered, difficult-to-debug nightmares.

This happened where I work.
A team of young fresh college grads designed just such a system using all the advanced features of C++.
The code worked, but was such a mess that they had to hire a whole new team to start over from scratch and do it right.
This is the project I'm on, to do things in a straightforward procedural way, using advanced languages features only when really needed.

You should understand the advanced features so that when you really need them, they will be tools for you to use.
But if your code works fine without them, and it isn't obvious how those tools would make things better, then you are doing things right.

 

Not every chef cooks a good meal.

You will learn for yourself which methods are better. There's nothing to say your method isn't the best except another 'chef'... who might just have different tastes to yours.

Unless you are doing things blatantly wrong, there's nothing wrong with doing it the way you are most comfortable with... sometimes you'll learn something which will make you change the way you write particular code, but other than that, if there are multiple ways to do the same thing, and there's no real benefit of any over the other, then you're not doing anything wrong.

 

Not only that, but sometimes there are times when you yourself may do things differently depending on the project. I do a lot of prototyping, and I approach those differently than I would a release code/project.

The more tools in your box the better, even if there are tools that use much more often than others.

 

Wow, so many replies while I slept.

Thank you for all the replies and support, I really appreciate the effort put into the responses.

I mean, I really dived in the deep end looking into voxels and that taught me a fair amount about UV's and mesh generating which was great, but I keep convincing myself there is a better way to do it, therefore I re-write the code to a neater standard, but that doesn't mean it is necessarily better.

Now my main toolset as of now includes Enums, Classes with inheritance and polymorphism, Lists, XML and a few others that do not pop to mind right now. The thing is, I keep harassing myself that Delegates ect are the be all and end all, yet I can't really find any real use for them apart for in a prototype I did for an "enemy spawning" system. And I want to implement them in my new re-write of my voxel set as a "buffer", which I guess is a step in the right direction.

Another question is, anyone who went to university for Game Development, how much did it actually help outside your OWN studies, because I have heard for a few specific people to not waste my time, and I am a bit cautious.

Thanks guys

EDIT : Is it also wrong of me to be accepting jobs at this level, another thing that constantly bugs me, even if it is in my current area of research involving Voxels?

Got a quick check-list so I can see if I'm doing something blatantly wrong haha.