Some time ago (or one year ago to be more accurate) I decided to take up a challange of DSP contest. It wasn’t much of a success (to put it mildly). I’ve been very reluctant to try it again, but finally, few hours before the registration closed, I have signed up. I’m going to give some details here what was my thought process.

DSP in short

DSP, or Daj Się poznać, is a coding competition, but very different from what one may expect from something called a “coding competition.” There is no solving of algorithmic challenges, or doing that in most optimal an elegant way (but it may be part of your work!). Instead, the goal is to actually deliver. Write two posts/week, push code to your repo. The quality of the code doesn’t matter (for real!). DSP promotes two things:

  • participants. yes, competition title says “Get noticed!”
  • GET THINGS DONE - stop producing flashes in the pan, but actually deliver!

Things haven’t been done

Again, to put it mildly. If you look at my blog history and check the dajsiepoznac2016 tag, you will immediately spot the problem. Three posts out of required 20. Don’t even try looking at the GitHub repo - you won’t find anything useful there. Why?

Good question. I did a quick retrospection, and came up with following conclusions:

  • I’m a busy man. My family, my beautiful wife and daughter, take a lot of my time. My work projects naturally take up most of my weekdays. I also play basketball as many times as I can. All of this leaves me barely any time to work on my side projects. I was not able to dedicate enough time I planned, and the moment I realized I’m not able to keep up with my planned DSP work, my motivation went out the window.
  • I tried to do too much. My project ( an online game) was way too big for this type of competition. DSP is about delivering, and the smaller project, the greater chance is that you will deliver. Some people submitted already undergoing projects to the contest, and they often barely made it (or didn’t) to the end.
  • I cared too much. It sounds completely counterintuitive, so let me explain. When planning my work and visualizing it in my head, I’ve included all the items a production-ready project must include, like tests, scalability, clean code, proper design, etc., etc. It sounds ridiculous, doesn’t it? It does to me know, but back then I cared too much. I wanted to create a perfect project, and again, DSP is NOT about that.

So what can I do about it to improve the situation in my second attempt?

Deliver, deliver, deliver!

I’m pretty sure this mantra was a part of many talks/presentations/coaching books. But this is also my plan. With following details:

  • Reduced scope - I decided to learn myself some rust, which I wanted to do for very long time. My project will be a simple file sync tool, think poor man’s dropbox. But very poor man, penniless I daresay. With no clothes. And he owes $2M for God knows what. No UI, no graphics, no advanced features.
  • Minimize the burden - No tests, clean code as much as I do by default. Design? It will come up naturally or will be a result of refactoring (the project is small!). One of the things that I will have to decide on is how to resolve conflicts when syncing files. Or will I? I can just ignore it and, for example, take the latest file version, which is the simplest (and probably incorrect) way to solve it. Whatever it takes to deliver.
  • Don’t try to predict everything upfront - yes, my biggest problem. Works perfectly well in my daily job (I can save us months of work by spending a week on analyzing stuff). But this is not the place, and I need to give up this attitude.

Ok, I feel motivated. Let’s do it!