While I'm at work I do not have this problem, but for some reason while I'm at home I just keep geoengineering things a lot.. let me put that in a perspective,

I worked as a game programmer for 1 year, during that time I worked on the UI and gameplay. The UI was done in an Embedded Flash and C++, the gameplay was i"mplemented" in Excel Spreadsheets and C++. I did exactly what I was asked for, I'm confident that i've deviled and everyone was on the team was satisfied with my work including me.

Later for some reason i've decided to change my job (i had 1 year of professional experience in total at that moment). My new job is to write plugins and tools (usually for 3ds Max and Maya) for 3D rendering(file IO, talking to other plugins, UI, scene conversion tool like that, almost nothing around the actual rendering).

At home I'm developing that mini-game engine that I lie to myself that is for educational purposes only, but deep inside me I really hope to quit my job one day and develop a game on my own(probably with that engine that i currently write). The problem is that It has been 3 years of writing after work and during the weekend (while mixing real life).

The development goes extremely slow. For those 3 years I wrote:
- D3D11/OpenGL3+ - wrapper that misses some features

- A shading language (Vertex and Pixel shaders only) that translates to HLSL/GLSL @ feature level of ~ShaderModel 2.

- A flexible 3D models file format with import export. (and a small CPU skinning for that)
- a bunch of other small things (base64, DDS texture IO, Linux support maintaining).

And that's it for 3 years of work. It's just too slow and currently I blame over engineering:

Let me give you and example: for the last ~2 months I'm trying to design and program:
- a general purpose "entity system" (just a small set of features that i think are need my most of the games).
- a basic editor around that "entity system". an example would be a world editor, value tweakers.

- a Undo/Redo system for that editor.

That thing above itself is complex enough for me, but additionally I'm carrying the burden of over engendering. I'm going to give my most renascent example:

IF TL;DR start here:

For my level editor nodes I've implemented a very small structure:

struct Node
{
   string name;
   std::map<string, int> int_attributes;
   std::map<string, float> float_attributes.
};

I imagine that everything on the level is going to be represented by that stricture in the editor(the game would have a different implementation). So far so good, but I remembered that for the 3D Models file format I've implemented a class that holds an "animated value" :

struct Parameter
{
   int data_type; // int float, vec3f ect...
   void* default_data;
   std::vector<animated> data; // basically a set of [animation name, {key-values}]
};

So literally after 5 seconds I've decided that I must use that stricture for the level editor as I may want in the future to have animated parameters for my game objects! But as I think about it how often do you have animated values for your game objects.. Using that "Parameter"

class will sure make thing a bit more flexible, but the code is going to be a bit more complicated and slower(well 3ds Max and Maya aren't that slow and their implementation of ParamBlocks and Attributes is a lot more complicated than mine). And basically I cannot decide. My lack of experience is playing thick on me.

Now imagine doing this ON EVERYTHING YOU WRITE! I literally do it....

In addition to that i needed ~3 weeks to come up with an idea how to implement those features together (I have 0 lines of code on the topic so far), this itself made me super lazy, because the task seems really hard and for some reason I stayed away form Visual Studio and instead I wasted my time playing WoW.

Now I finally somehow recovered form that laziness, but I'm hitting that over engeneering wall...

So my questions are:

- How do you handle complex task and avoid laziness and lack of motivation?
- How do you deal with over engineering?

- Do you think that an average programmer would do more for those 3 years?

- Any thing you wanna add? personal experience and suggestions.


Sorry for the long post and my bad grimmer and spelling, here is a <potato>.

1- How do you handle complex task and avoid laziness and lack of motivation?

Keep it simple.


Most critically, remember the scale of work is radically different:

At work you are part of a team. Hopefully each team member is working on areas they are confident and experienced with. If you are used to working on a team of 20, they may produce in one week what would take you 30 or 40 weeks full time at home.

Second, remember you are not working on it full time. What might take you one week full time will probably take two or three weeks at home.

Combine the two, and realize that it may take you three or four years as an individual to do what your professional group does in a single week.

Your development speed at home is radically different from your development speed at work. I keep things simple be tracking my own speed at home and remembering it is completely unrelated to my speed at work.

2 - How do you deal with over engineering?

As above, I remember that I do not have time to get everything working polished and to my work standards. I can accomplish something minimal that gets the job done, and that is all the time I have for a hobby project. Always think small, then think smaller again.

3 - Do you think that an average programmer would do more for those 3 years?

Everyone's pace is unique. Doing something you are comfortable with should be much faster than doing something that requires learning.

I think in the grand scheme of things, people's skill at programming is a similar normal curve to any other skill. Most people who do the job day to day form a giant bell curve. There will be some who are faster, some who are slower. There are some who will be terrible and struggle to work professionally. And there will be the outliers at the top, the Michael Jordans, Magic Johnsons, Larry Birds, and Kobe Bryants out there who produce more than two or five normal people combined.

I've always thought it was funny how much emphasis many headhunters place on trying to land those rare superstars. They exist, but the effort (and high salaries) of trying to put together a team of actual superstars is off the charts. It is great to aim as far to the right of the bell curve as you can, the best people you can reasonably find, but expecting everyone to be in the top 1% is unrealistic. Most people are near the center of the bell curve. Some tasks they may perform better, some worse, but it all averages out in the end.

What you worked on is what you worked on. Don't compare yourself to superstars, don't compare yourself to domain experts working in their expert domains.

4 - Any thing you wanna add? personal experience and suggestions.

Scope smaller. Always think smaller. As an individual your time is exceedingly rare. Think about not doing the thing entirely, and if you decide to do it, figure out the minimum that meets the standards.


If you're still not sure what you can do in a month, work on a challenge of doing exactly one month of development. Build something in exactly one month, then put it away. Build something else the next month, then put it away.

The first few months you will produce things that are incomplete and maybe unusable. That's okay. After a few months you'll get better at figuring out how to scope your own personal projects into something that can be done in a reasonable time.

I stmbled on opposite problem, I always overengineered mine stuff, when started to working due to impossible deadlines I started writing spaghetti code,

This bitten me later but not so much, in exchange I started too see the few places where a non-spaghetti code was better, few MVC there, a state machine over there and a decorator in one place and voilà, ship awesome features in no time. Now I'm gradually strarting writing non spaghetti code at almost same spped (if not faster).

The problem is that as your own manager you know where you maybe want a change and you start overthinking, at work the requisites are not your decision so you stop overthinking, the solution is to not longer decide the requisites for your stuff, instead let a friend (or girlfriend) to decide features (you should give a visible result or cut it.)

In the current game I'm developing requisites come from another society and are changing several times a week, so even well coded scripts had to be dropped sometimes, if the game designer/ project manager started ith definitive requisites the game probably had to be already complete, instead the time I did'nt loss in overengineering was better used to apply on the fly the changes wanted by the designers/managers.

The most important stuff was to decouple visual from logic, since usually only 1 changed and rarely both.

I solve the problem by writing what need to be done. If later requirements come along that mean I need to refactor then refactor. There is no need to think about future usage etc, as long as your code is structured well it will be easy to pull apart and put back together to take the new requirement into account

I don't think about overengineering. Worrying about overengineering is the first step to overengineering.

- How do you handle complex task and avoid laziness and lack of motivation?

Focus.

There is only one problem, namely the next smallest possible step. I often find the smallest next step is actually too big, and I need something else first. In that case, the thing to do first becomes the only problem that I have in the world.

Those steps are always things I actually need. I do a little look-ahead of tomorrows needs, but only for concrete needs that exist today. That is an under-approximation of course, but I'll refactor the code to new needs when that need becomes concrete.

I can't really work on the same stuff for too long (at work I can, but it's very boring and annoying), so I usually have several spots in the same project where work needs to be done where I switch between. What also may help is aiming for something you can show to your future users, eg in a blog. "Foo is working now!"

The trap where I fell into was not having an overall plan. At a birds-eye view, have an understanding of the big pieces and the core mechanics, I was focussed too much on the next thing to add. I did learn refectoring though! :)

- How do you deal with over engineering?

I realized there is no upper limit on how complicated you can make things. You can forever add additional software layers, and extend for the future in every possible direction.

Anything you add but that you don't need however, is not progress. In fact, it's the reverse. You spend time on making the extra thing, and from now until forever you have to deal with that additional layer that doesn't help you as well, which also costs time. This starts at a level of setters and getters, and gets worse as you go up in additional layers.

The Python language opened my eyes for that. It doesn't have private and protected, it doesn't do getters and setters. It's terribly scary at first, but it works by using some additional rules.

- Do you think that an average programmer would do more for those 3 years?

Sorry, I have no idea what an average programmer does. It also is totally irrelevant. This is what you can achieve today. You won't get any faster or slower knowing how others can do.

What I did learn throughout the years though is that picking the right solution is 2/3 of the problem. If you make a bad choice, life is difficult and complicated. If you make a right choice, coding is simple and fast. Thinking is therefore at least as important as writing code, although the former doesn't really feel as progress, often, especially when all the solutions you come up fail due to some flaw somewhere.

The best solutions are often simple. For performance, aim for nice scaling of the things you expect to get really big. All other stuff is irrelevant until counter-proof exists.

- Any thing you wanna add? personal experience and suggestions.

I read that you want to make a game, yet I also read you work on a game engine. These things don't add up for me. You can work for quite a few centuries on a game engine, and still not be done with it. Make a decision here would by my suggestion. Focus what you aim for.

So my questions are:

- How do you handle complex task and avoid laziness and lack of motivation?
- How do you deal with over engineering?

- Do you think that an average programmer would do more for those 3 years?

- Any thing you wanna add? personal experience and suggestions.

1. By keeping it small so you get a sense of reward for every goal you finished. It's a long project, so having some breaks from computer (and games!) for a few days or a week could help.
   
2. I think from the things you wrote the last 3 years you haven't really mentioned anything related to your game other than just satisfying the lust of coding.
   Why do you need D3D11/OpenGL 3+? What kind of features do you need from those graphics API? tessellation? instancing? You want the game to be Windows 7 only and above? Why do you need flexible 3D formats? Do you really have to program with various 3D format and 3D tools? Why Linux support? Are you making the game for Linux? Do you have a Linux fanbase? Your tools are only in Linux? Do you really need a world editor? Does it has to be drag-n-drop? Does it has to be C++? etc.
   If you take these questions to the smallest bit, you can calculate how big your project is, and so you know what you need to do.
   
   Over-engineering is like when you put ::normalize() on your Vector2D class when you don't need direction at all.
   
   As many others have said here many times I think, don't make an engine, make things you need for the game. Hint, in-house tools aren't always pretty. ;)
   
3. Depends on you and your project. Could be some parts of your project are too big to handle alone. If you are making a Final Fantasy XV from scratch, you should definitely know it takes hundreds of years to build by you alone.
   I think That Dust: An Elysian Tail game, a 2D sidescroller game, using XNA framework, by an animator, takes 3.5 years to develop alone. So you can have a hint on how long your game could take.
   
4. My opinion is your project is probably too big. If in 3 years and you ask these questions, most likely you're out of track and forgot the size of your project. If you know that the project takes 8 years then you know it will take that long. I suggest you stop coding and re-read your game design and your project goals, then redefine feasible plan from now to finish, then start developing again.
   
   Put small tasks with short deadlines keeps you at pace. Have someone to be your boss if it's hard for you (mentor? friend? parents? wife/husband? children?). If you already master how to be your own boss, that's even better.
   
   Extremely beware of ideas in the middle of your journey. Always stick with your first scope of work. if you work alone, it's reallly easy for you to fall on filling ideas every second.

I deal with over-engineering by making games, not engines. I also deal with it by not re-writing things that other people have already written unless there is clearly something they failed to implement, and which I also need.