Focus.
You might have stumbled upon the brilliant Short clip, Youtube Shorts video or entire interview of Jony Ive.
What is Focus?
I think there are two sides to it. Will recap this, please read on! Have trust.
Let’s make an experiment.
Watch first the video below:
Imagine someone said to you: you are not focused; “You are underachieving.“
I was thinking about Focus tips, but then — so far I have not yet tested these tips:
Focus is actually the act of non-jumping (don’t “jump” to another interesting challenge, before you have solved the first).
Stillness.
Keeping focus. Against all odds. Against sweat dripping down your neck, that one tiny hair that is swiveling on your forehead and feeling itchy; you decide that your fingers stay on the keyboard, nevertheless. Focus is the millions of social media messages being blasted in countless streams — ignored. You decide not to engage in them, despite the apparent or possible FOMO.
Focus On My Own. FOMO. The new FOMO.
Focus is attesting the joy of executing the most mundane.
Coding a feature — something that does not yet feel so ffricking exciting, but you got it, it’s your idea — YOU added this to the backlog. This needs focus. Your baby project’s bones, structure, being assembled together.
Being still, fights the whole ethos of modern world. Stillness, focusing in a developer role — thinking through the hard problem.
Then again, we may have just believed this ethos based on.. social media blasting those messages. Yes. I think it is actually pretty much that. We sample the whole world, at once — as if everyone (every member) of the world would be as busy as the whole world. It’s a cognitive bias, I think. At least proposing that one right now!
Skill, craft, science?
Developing code is both a science, and craft. It truly is both. It’s also a skill, you learn by doing. I for example have mostly learned coding by doing.
I did literally hundreds of small programs, learning to write BASIC — and more than that, learning to think through problems, into a code, that solves the problem. Ok, there were no pressing problems, rather a young boys mind was filled with just ideas and wanted to know could those be done somehow using a programming language.
If you do something, you need to see the results. That is possible when experimenting with software development. It is one of the superior features actually of this craft: you can run experiments, fast. A few lines of code, and voila! You see what happens.
One of the known unfortunate miseries of large enterprise software, sometimes, is that this feature experimentation mode may have become very tangled: as the lines of code grow to millions, and interactions between parts of the program become quite complex indeed, experimenting with change is prone to be socially avoided, and simply “costlier”. Fear not! There are methods and tools to also overcome the complexity. Modeling the software and splitting functionality carefully, and making sure there is a design philosophy even on the coding practises level; there are ways to mitigate bloat.
How do we learn to focus?
That is a personal thing, I think.
First you need to truly grasp the need for Focus. It’s an inner feeling, an observation perhaps.
Get a reward from yourself. Get one even perhaps from outside, out of having spent the time in Focus mode. So the focus was worth it.
I don’t really know.
Are there good books for gaining more focus?
I think the whole phonomenon still is one that requires an experience. Presence in the focus. Perhaps adjusting time, scheduling, time blocking can really work well. It depends also on what you expect to be the worthy thing of focus.
Focus can mean another kind of mode, than thinking-related focus.
So it’s about solving, but also focus can be about “guiding”. In very physical terms, we are thinking about focused mode of action, performing a careful operation — perhaps steering a vehicle through traffic, or navigating a ship to its port.
Curiosity. Challenge. Motivation to seek an answer, spending time in Focus. That’s learning.
Methods that work for learning
“Aping” — looking at sample code. Looking at Someone else doing the thing.
Reading articles from computer magazines.
Deep-diving into an area with a whole book. It’s actually pretty fast, if you have a desire and motivation for it. Reading is an absolute feast, it is one of the best ways to refresh your thoughts, and gain new ideas and energy. Yes, runs counter to the intuition, but in reality reading lets us reflect thoughts inside the best personal echo chamber we got: our brain.
Always take one semester worth of Algorithms and Data Structures, if you can. This is one of those things I recommend for anyone doing code. It’s a brain refresher, teaser, challenge — and worth it!
Focus on Fermat
Mathematician Andrew Wiles, who solved the Fermat’s last problem — by giving a proof — worked on it for over 20 years.
Get Jukka Paulin’s stories in your inbox
Join Medium for free to get updates from this writer.
Why?
That may be beyond our story here. I frankly don’t know, and haven’t searched for the answers by Wiles himself. But I can somehow relate. To that seeking of an answer to a mundane, fascinating puzzle, seemingly so simple — there. Presented in front of your eyes, yet elusive.
As a developer, I’ve found that the biggest challenge often isn’t the complexity of the code itself — but maintaining focus through the unpredictable, nonlinear nature of development.
I’ve gathered and refined these tips over time not as rigid rules, but as small practices that help me reduce mental clutter, stay on code traction, and push through those moments when progress feels just out of reach.
What makes these tips effective is their practicality. They’re designed to work with the natural rhythms of programming — where bugs appear unexpectedly, goals drift, and distractions (internal and external) constantly nudge us off-course. These methods help me not jump around too much, clarify my intent, and actively name and frame what I’m doing.
How many times actually a jump happens?
It’s alluring. You see, the psychology of Jumping. A jump is relieving.
It’s a perfect weapon of self-distraction. It may be even self-deception. When you choose to steer your focus, it takes first a bit of a threshold:
In computer brains, the CPU, there is also a Jumping. It’s the context switch. In operating systems, the CPUs (cores) used to be just 1 — before multicores. Let’s keep this train of thought. We have a 1 processor, someone, who takes orders and executes them. They do all the steps diligently, store the results into a notebook, and then continue doing the next order.
Context Switch is when a CPU needs to “abandon” a whole task, temporarily do something else, and then come back to where it left off. Context switches slow down operating systems. These switches used to be (and still are) demanded by realities of the world:
- mouse movement
- other devices being ‘ready’ to deliver their results to the CPU
- other signals that may be useful for the CPU
Jumping to another thing before you’ve finished t/h/i/s — makes perfect sense; you see, doing something else, right now? Well well, would you not just just feel so much — speedier!! Bicycling! You would feel the wind against your face, that kind of force feedback friction that makes you smile, since you are going somewhere. Instead of sitting and mulling over a problem, thinking.
Thinking is hard.
Don’t be afraid of that.
In actuality, most things in software development are not that hard. But getting to speed, and the mental mode of coding is sometimes the actual challenge.
TIPS FOR DEVELOPERS
- Write every high level “Goal” now for today’s next 2–6 hours that you intend to do work.
- Name your iterations: give the git commit name — before you do any code. This helps already understand and think through the tasks, it is part of your planning, and at the same time it takes out the sometimes most annoying part of practical code crafting, which is about naming your code commits.
- document your troubles — whenever those are encountered. ChatGPT and age of AI, age of human companionship i n code weaving requires you to be able to tell what the problem is. Tell. Write, document. Relay in text. Jump to 7
- use Polls when asking for advice on social media- this lowers the threshold for participation. Make 2 choices + a free text field for answers
- add only 3–5 lines of code at any given time. Run the app. Worked?
- if your app does not work, you have a Trouble Encountered. Look at 3, continue there ^
- split your trouble to sub-problems:
what exactly does not work? Write it down.
Also, write: How did you Expect the outcome to be?
Write this explicitly.
Mock the result, return a fixed / static value. Run your code. Mark the mock, and try and resolve it. - If you resolved the Mock, and could make a real function instead of a static return value, then continue. If not, jump to (4)
- Test the tips you got. If you have 0 tips, and you feel that the subproblem does not yet subside, go to 9
- go to 3
Two sides of focus
Promised to clarify. It is here:
Focus is about 2 sides:
- Jumps
- Concentration
Jumping, jumps; that is the voluntary act of yielding focus out, to another task. It has to be done, yes, but it breaks your effort. You can have strategies to counter this and it is a subtle act of balancing and learning how-to.
Concentration is the active mode of really holding on to whatever you are doing right now. Against those sweat drops, against the old FOMO. Towards the new FOMO.
