- Realize whether this will be just a toy project where you’re trying things out and learn new stuff or whether you want to get something done. The following are learnings from the latter goal. However you’ll still be able to learn new things. It’s just not the focus and unless it comes with the project no extra time should be invested.
- Involve your family and tell them what you plans are. It is easier to build on understanding and maybe support than being confronted with incomprehension and intolerace.
- Dedicate and reserve timeslots for one and only one thing and stick to it. For example: It it is completely unproductive to run back and forth between playing with your children and trying to fix a bug in your software. It’s much more efficient to dedicate one continuous block of the time spending with your children and another one fixing the bug. Make clear to everyone when you need to concentrate.
- Take yourself time at the beginning and learn and understand the technology you are working with first. Since you only have a few hours to spend on the project each week you might be tempted to dive right into the work without fully understanding the technical environment in terms of patterns and practices. It will pay off to professionalize yourself first and prepare a proper toolset. Including well-known best practices like a version control system, CI or a common network share.
- Run your project together with at least one other person who is also fully committed and determined as you are. It’s hard if not impossible to work on, focus on and finish something over such a long time when you are alone. Partners will motivate and help each other: When your graphics guy invested time in new 3D models s/he will certainly insist on that you spend time on providing the necessary game logic and vice versa.
- It’s your spare time and a hobby but try to come up with at least a rough plan and timeline. The Buggs started of with a small idea and we refined and redefined that idea basically every month after playing with the latest build. While it is okay to have this feedback loop and after all it’s still a hobby but this approach can be very time consuming. It’s better to sit down and plan on what you want to achieve in the next 6-8 weeks and on a coarser level in the next 6-12 months – at least roughly. This also helps everyone to stay motivated, especially when some milestones are achieved. After all, you know, when you’ve got endless time you tend to take one’s time.
- Prioritize and look on the return of invest for everything you do. Again, since you have only a few hours each week, it’s harder to move forward than it is in a fulltime job. Don’t get worked up on details, don’t do things with low value or worse reinvent the wheel. Rather, get an early alpha/beta version out to your friends and ask for feedback. (Don’t worry. It’s very unlikely that some of them will “steal” your idea and place a copy on the market before you’ve published the original. That did not even happen to Minecraft.)
- Be prepared to invest serious time into marketing once your project is done. It’s hard to build a product, it’s even harder to build an interesting product and it’s very hard to attract attention.
Recently, while following the coursera course on reactive programming and especially Erik Meijer’s introduction to Scala I’ve got interested in some monad types Scala has to offer. What monads are, has already extensively been described on the web. For example Wes Dyer or Eric Lippert offer excellent explanations.
In the following posts I want to have a closer look at Scala’s Option and how it could be ported to C#. The amplification (a term coined in Wes Dyer’s blog post) behind Option is nothing new to C# developers: For a certain type it either holds some or none value of that type. A functionality which is already available with the class Nullable