Comfortable Development

Unknown — Tue, 10 Feb 2026 00:00:00 +0000

There’s no shortage of material about what software engineers do. For open source, you can inspect the entire history: commits, pull requests, issues, design discussions. In academia, you can read papers and blog posts explaining ideas in detail. In commercial work, you can usually see the final product.

What’s harder to observe is the workflow behind the output: the tiny defaults and habits that shape daily work. How people navigate code, how they make changes safely, how they avoid repeating the same mechanical tasks, how they keep focus. Without direct communication, most of those details stay invisible.

I like experimenting with small changes that feel immediately useful. Most experiments don’t stick. But a few habits consistently reduced friction and made development more comfortable for me over the last two years. This post is a short list of those habits—nothing revolutionary, just practical.

Vim and keyboard-first workflow</h2>
This isn’t really about Vim itself — it’s about the idea of keyboard-only interaction. Vim is just a good representative because it’s popular and many IDEs support Vim keybindings.
I genuinely like the feeling of not touching the mouse while coding.
It helps me in a few ways:

Navigation becomes much faster: you can jump, search, change, and insert with a few keystrokes.</li>
The touchpad tempts me to scroll, switch contexts, and lose focus.</li>
Sometimes Vim-like editing is the only practical option (e.g., when SSH-ing into a server to debug, edit configs, or inspect logs).</li> </ul>
Scripts</h2>
At some point you notice the pattern:
`Up</code>, Up</code>, Up</code>… search shell history… type the same command again…`
`That’s usually the moment to stop doing Sisyphean tasks and automate.`
`However I don’t have much more to say yet - I still haven’t found the right tool or language for my own automation setup. One rule to mention: don’t preemptively automate everything — it’s easy to spend 10 hours automating a 10-minute task.`
`For further reading: this article by matklad</a>`
Editing pipeline</h2> While reading Martin Fowler’s Refactoring</a>, I found a simple workflow for changing working code: change -> build -> test -> commit. The idea is to keep changes small and iterative: rename a variable, add a parameter, split a function, and so on. Once you’ve accumulated a set of small, safe steps (or finished a refactor), you can squash them into a single well-named commit (or keep them separate) and push. It’s not rocket science, but I didn’t think about using Git that way before. Now it’s hard for me to work any other way. Auto-format on save</h2> Auto-format on save is one of those features that feels small until you get used to it. Once it’s enabled, you stop thinking about indentation, wrapping, and small whitespace decisions. Your code becomes consistently formatted, diffs get cleaner, and reviews focus more on substance than style. I try to treat formatting as a background process: write code, save, let the formatter do its job.

Beyond the Syllabus

Unknown — Thu, 22 Jan 2026 00:00:00 +0000

Pareto</h1>
Many people have heard of the Pareto principle: 80% of results come from 20% of the effort. While that idea is hard to dispute, I believe the remaining 20% is what truly distinguishes a professional from everyone else.
Most skills can be “acquired” by completing a university course that lasts about half a year (roughly 90–180 academic hours). That may sound like a long time to learn a single skill, but it is nowhere near enough to reach genuine expertise. True masters spend years refining abilities that others consider “learned” after just one semester.
A few examples, to make this less abstract:

Many students can pass an exam in a subject, but far fewer pursue professional training that focuses on that subject in depth.</li>
All mathematics students are required to study calculus, but only a small fraction read beyond exam-oriented notes.</li>
Most computer science students learn one or more programming languages, but far fewer become strong software developers.</li> </ul>
Knowledge as a graph</h1>
In my view, people have very different mental models of what knowledge is. For me, the most useful way to think about it is as a graph.

Vertices represent axioms, definitions, statements, facts, and similar units of knowledge.</li>
Edges represent relationships between them: logical implications, dependencies, analogies, and other connections.</li> </ul>
Why focus on edges?</h2>
Edges matter because recognizing structure transfers well. If you notice the same pattern of relationships appearing across different topics, you can often reuse that pattern to connect new vertices. And when you try to add a new edge, you sometimes discover you are implicitly introducing a vertex you did not realize was missing.
Some vertices are unreachable from a given set of axioms in a precise formal sense. Gödel’s incompleteness theorems show that, in sufficiently expressive formal systems, there exist true statements that cannot be proved within the system. There are also many vertices that people strongly suspect should be connected, but for which a proof is still unknown. In that sense, some “obvious” connections are really failed attempts to force an edge where we do not yet have the machinery to justify it.
At first glance, this may resemble note-taking systems such as Obsidian, Notion, or even Wikipedia. There is overlap, but the concepts are not the same. A graph is simply a convenient and expressive model for describing both learning and knowledge accumulation.
Following this analogy, a classic university course gives you mostly vertices. In general—setting aside very specialized or advanced courses—programs emphasize commonly taught and heavily examined material. After completing a course, you may have many of the right vertices in place. But the number and diversity of edges you build in this type of education is often limited.
A good example is the Pythagorean theorem. Everybody knows the statement $ a^2 + b^2 = c^2 $, and many remember one or two proofs. However, there are hundreds of known proofs, and each of them is an art in its own right — something standard education rarely explores. Of course, nobody truly needs that many proofs. The point is that a single vertex can support an enormous number of edges. Each proof highlights a different relationship: geometric, algebraic, group theory based, and so on.
University curriculum</h1>
Since I have started criticizing the education system, I should mention other drawbacks. What I say here may not apply to education in general. It is mostly about my university, MIPT, which, by the way, is considered one of the strongest universities in Russia for applied mathematics and informatics.
The vast majority of courses I attended consisted of lectures and seminars, as usual. A typical lecture follows a familiar pattern: a professor presents material at speed, and students try to keep up. The problem is that the material often feels like a sequence of topics rather than an interconnected structure. There is little explicit connection between courses, and proofs often seem more technical than illuminating. Even so, they can become intuitive when viewed through a different branch of mathematics.
Homework can reinforce the same issue. Many problem sets rely heavily on standard exercises (for example, endless integral calculations). That can make the subject feel superficial and can undermine the motivation to explore it more deeply.
I also find the classical exam format discouraging. You are expected to know every statement in the program and reproduce proofs from memory. What is the value of memorizing every proof? You spend a few days drilling lecture notes until you remember each symbol. In real life—whether in work or research—you can use whatever resources you need. Sadly, but I do not have a better alternative to propose, but the current approach just feels misaligned with how understanding is built.
From scratch</h1>

“What I cannot create, I do not understand.” — Richard Feynman </blockquote>
When I read mathematics books and articles (I consider computer science a branch of mathematics), I enjoy trying to prove statements on my own before reading the author’s solution. Even when I fail, I gain experience that increases my chances of solving the next problem. It creates an opportunity to reflect on why something is built the way it is—or whether it could be varied to produce different results. This technique encourages the spirit of science and research.
The drawback is obvious. It takes much more time than conventional learning. Given that time is limited, this is a serious constraint. You cannot understand everything from scratch. Humanity, as a species, has spent an enormous amount of time reaching the current state of knowledge.
So you have to choose: prioritize some activities over others, and steadily improve. At the same time, I do not think you should place your entire life on the altar of a single skill. Find something that genuinely holds your attention right now, give it more time than the syllabus demands, use better resources than the minimum required, and enjoy the process.
All I want to say is this: do not waste your time chasing perfection just because parents, curriculum designers, or your GPA pressure you to excel at things you do not care about.

Blogs</h1>

matklad</a></li>
mahesh’s blog</a></li>
Aaron Turon</a></li>
Jamie Brandon</a></li> </ul>

vleksis

Comfortable Development

Beyond the Syllabus

Resources

vleksis

Comfortable Development

Beyond the Syllabus

Resources

Blogs</h1> matklad</a></li> mahesh’s blog</a></li> Aaron Turon</a></li> Jamie Brandon</a></li> </ul>

Blogs</h1>

matklad</a></li>
mahesh’s blog</a></li>
Aaron Turon</a></li>
Jamie Brandon</a></li> </ul>