I’ve always had a dream: to create stuff that is useful or fun. Computers help me doing that. Thus, since 2013 I work 4 days per week (or less). How did it happen?

I never wanted to be a specialist as a programmer. I always strived for the “generalist programmer” title. Know it all and do it alone. No human dependencies. All questions answered internally. The all-seeing eye in the world of tech. And guess what, I think I didn’t fail too much on it. But hear me out.

Ideal programming language? What if we started from beginning having knowledge of current past? Throwing away “backwards-compability” to the furthest extends?

Forget about Object-Oriented Programming. Look at this flat world built of small data chunks and separated logic. A world easy to refactor. Meet Entity Component Systems.

Some time ago, for about a year I’ve been teaching myself and newcomer company programmers about proper and efficient usage of git. Since git is a distribued VCS, which is well done for time pressure work, the “distributed” part isn’t really the easiest one in such heavy context. Inbetween those teaching times I have noticed that there is much more to teach rather than only how to use some new source code management tool.

I’m not gonna explain the tool itself and tricks around it. I’d like to focus on problems around it. The following may be your checklist for practical knowledge of git. Ready for exam? Then read on.

When I’ve seen Grunt (a build system) I have imagined that it would be awesome to have such setup making my code easy to maintain and optimized production version at the same time. When I tried to create my n-th Gruntfile.js, after some more play with Grunt, I realized that this system didn’t work as well as supposed to. That was the moment I gave a chance to gulp - “the streaming build system”. I’m gonna talk about why and why so much “yes”!

One fellow asked me to counter his thesis: does it make any sense to work on a one-person project using git. Isn’t it better to just use SVN? I disagree. And I will tell you why you have to agree with me.

Today many games need tutorial. Tutorial is a hot topic for discussion in indie games community. Anyhow, for programmer-non-designer tutorial implementation is just a job which comes with unwanted problems. Most of them appear because it tends to be made in the end of project. And worst situation is when tutorial is being done incrementally.

I will not discuss topic of tutorial design. Instead I’d like to present some notes about coding a tutorial in online game which are derived from my experience and observations. In the end I’ll give my advices for coding tutorials.

Documenting a project vision is justified in probably all of development methods and methodologies, like Agile/SCRUM, Waterfall, PRINCE2 or even Kanban. The idea of documenting is simple - we need to know what to develop. When vision of a new concept becomes to be a project, it’s always a good idea to document it. That’s what we are taught on universities, in companies or on trainings. But what are some objective reasons for doing that? Why not just start the project straight from a concept in the head?