Setup: minimal but cozy enough to prevent you leaving, with a cord
Getting into a flow in coding is really mesmerizing process. Sometimes when not in there, it leaves me wondering what actually constitutes the physical environment required for a flow experience.
I think I discovered a few things. Here:
- nevermind your belt, belly or wear – be happy with what you have right now. This is all you need. Once you’ve settled, try to keep still for a while, and go forward in this entrenching process.
- forget any negative news – but do make a actionable notes of things with deadlines, if needed (use the same method always, don’t innovate in methods)
- use mood music, if it helps you concentrate
- set up your dev work center so, that it has a bit of impediments preventing your immediate leaving in and out – you won’t hop in and out just with a whim of thought. Enjoy your mental firewall
- substitute a cup of coffee or tea, or water as your a building block of your mental firewall – if you feel like just hopping off flow, extend your arm and sip a bit of drink.
- tip: cord-attached (3.5mm jack) headphones might be better than cordless ones: this also makes you a bit more “sticky” since the cord prevents you mentally from leaving the place your are typing keyboard. Naturally, a preference question. Some people crave the freedom and like to think while walking.
- know when to crave for perfection, and when you are in let’s do this quick mode
The invisible part of product
Try and concentrate on the internals of the task – “jump into the world” of your task. This requires the use of imagination. I think personally imagination plays a large part in creative arts, and software is one such field.
With development and computer work, it’s easy to forget the part of the solution which is not readily visible or tangible in front of you. Doing development is partly about imagining things! Especially what is hidden is the end result of your work – almost by definition. We are working on it.
How far you take the time horizon for projection, is another question, but essentially we need a sense for that which doesn’t yet exist. Actually scrum (Agile) deals with this part- it’s all about scoping and making small enough iterations so you won’t have to worry too much about the scale and scope of your project. Agile reveals backlog enough to keep us busy and energetic, and little enough to keep us focused. The product’s Roadmap is a reminder of the whole. It guides tacitly in choosing the details and missing some of the unsaid things in the ongoing sprint (stretch of work).
Visit the goal square briefly
Jump briefly into your goal. Look behind – where did you come in? Visualize the results. See the form and shape of your solution, the awesomeness of what it would do. Tourism. Ahh. This is the way trips were supposed to be!
We used to do this all the time as kids. We envisioned worlds, played with toys that didn’t exist. There were cars and doors, steering wheels made simply of thin air- no substance, remember!
One large stone in a particular place was “my place” or “my house”. We used to navigate in a world of contracts about the meaning of things. The same happens in projects.
As kids we used words and yes, even sometimes had arguments about the logic of ‘code’ in the playfield; we had to justify why (apparently, of course) in our view of the play-simulation someone crashed (or evaded) into another invisible car in the intersection of the playground city.
Projects and code are a bit the same. We aim for visualization and transparency of software in planning, but some part is always hidden – that’s the part that doesn’t exist yet. It’s often this way for practical and financial, resource-use reasons.
Waterfall style development in the old days concentrated so much on minute details of every nook of the design that it took immense efforts. The problem of this autocratic designer was often accelerated further by the fact that these design methodologies weren’t very automated. You had MS Visio and Starsoft’s UML designer software and likes, but very often the work itself was hugely manual. You couldn’t propagate change automatically, like what you can do in a CAD: if you move a wall of CAD designed building, the software takes care of a huge number of things – not just the visual wall moves, but also routing of electric cables, the Bill of Materials gets updated, project plans are adjusted for the new building phase requirements; the simulation of insulation materials changes and pretty much “everything” is recalculated in a powerful architectural CAD software.
Nowadays in 2021 we actually are approaching project management and design software technology which enables us to think much farther, in a much more automated way.
Bening cycle of acceleration
Technology accelerates the development of technology.
This is the same effect that has happened since ancient history of information technology: first compilers were hand-built using assembly language. The assembly code was hand-build using pen and paper. Once the change propagated from bottom up to the level of a compiler, the next iteration in the cycle was more efficient.
A tiny change in one view of a Design document had to be propagated like a wave into many, many other documents. It was tedious, and took way too much time to make any sense in the revenue bottom line.
This is the sort of imagination you can also use with developing software. Create the internal world of your solution, in your head, and navigate in there. Later on the code and graphics are the tiles and cement which builds your place in a certain shape.
Leave a Reply