Limit degrees of freedom in development

By William Narmontas,

This page can be edited on GitHub.

Original article at Hacker Noon.

Potential degrees of freedom in what you are working on:

Recently a colleague of mine was rewriting code from one language to another, and trying to make it add a new feature and trying to fix a bug in the domain logic. He was doing too much and making no progress.

Earlier in time, when I was learning Scala I was trying to implement a gaming statistics system with distributed facilities and all sorts of nice sweet ideas. But I got nowhere, so I kept for a while reducing and reducing my scope — to the point that only the immediate thing I am working on was the only degree of freedom to move in.

Easier to build a system that moves in one direction than in six.

There’s a dual to this: if you are trying to meet too many constraints, then you’ll never get to a solution.

Math helps

What a domain is: it’s the business problem you’re trying to solve. An algorithm. A user interface. The user’s needs. Finance or eCommerce or media publishing or…

New domain and new tools? Can be quite confusing. So fix every variable but one.

If you want to learn a new tool, use the domains you already know.
If you want to solve in a new domain, use the tools you already know.

This is how I came up with the ‘Essential SBT for Scala’ guide to allow a newbie to get started with SBT and Scala with minimal Brownian motion.