In virtually any creative endeavor in life, constraints are important. Constraints foster creativity. For instance, I’ve just recently set a constraint for myself where I would write a short article to be published each day of the week, every week. This constraint has re-sparked my interest and my ability to write more frequently on the blog, as I now “know” that I’ll get to write whatever I left out – on the next day. Constraints can be composed of smaller constraints too, this one for example – to write a short article every week day – sets an expectation to be able to publish every day, forcing me to stay consistent and write at least a little bit every day, something I’ve been meaning to address ever since I started the blog over two years ago, and it also sets the expectation that those articles (or as I’ve been calling them, “thoughts”) should be brief.
Brevity, in turn, makes it much easier for me to be consistent. It would be unreasonable to expect myself to be able to write long-form articles that would be published every week day, and still be able to do consulting and open-source work. Writing brief articles keeps me focused and able to go on about my day job, I allotted time boxes of one hour a day – maybe two – to write these “thoughts”. See “What I Learned [from] Writing a Haiku Every Day for 100 Days” as another example of someone who commited themselves to writing a bit every day. Or, consider the (now defunct) DailyJS website as yet another example.
Constraints define our work, our lives. They are everywhere.
A few months back, Amanda pointed out the power of constraints, and it felt obvious. Yet, it has to be pointed out. Then, it becomes obvious. If you look at great works of art or design, constraints are, for the most part, what drove these artists. In terms of painting – or systems design – It’s not about what more you can add to your work, or what else you can take out.
It’s mostly about what you let yourself leave out, in the first place.
Consider performance and the interesting concept of performance budgets, where you define a hard lower boundary for how responsive your app or service should be. Here we are defining constraints such as “the total page weight must be under 1MB for initial page load” or “requests against the landing page must attain a SpeedIndex score under 1000”. Consider design and constraints such as “we must not use images for layout”, “we must pick, at most, two custom fonts”, or “all icons must be 32px by 32px in size”. These are not exactly orthogonal concepts, quite the opposite actually. Design must be tackled with performance in mind if are to take performance seriously. We need to work together with our design teams so that we don’t end up slaves to multiple font downloads (or even worse, scripts).
It’s not so much about the web being slow as it is us that are making it slow by not enforcing enough constraints.
Constraining yourself on purpose is not even only useful when you’re writing (prose), designing, or defining performance expectations! It’s also great when writing code – a very different form of writing.
Constraints in code may crop up as “using only ‘the good parts’ in JavaScript”, following style guides, developing code in small modules and writing tests for it. Similar kinds of constraints can be seen everywhere in the world of software development, and the universe at large.
What kind of constraints do you set upon yourself? Which ones do you think work really well for you?
Have any questions or thoughts you’d like me to write about? Send an email to thoughts@ponyfoo.com. Remember to subscribe if you got this far!
Comments