Existential problem

You know what’s difficult? Some buildings, especially official residences, are so confusing that finding the right office is a real challenge. And even if you eventually get used to finding your office almost automatically, you often don’t understand what exactly is nearby or what the workflow is like in the neighboring offices. Sometimes such buildings, I believe, were designed by specially trained people, and that’s really the intention. Sometimes they’ve simply been redesigned several times to suit different needs, and they’ve been refined along the way. Basically, in the beginning it’s hard to figure out how to get around, so you walk around, asking everyone you meet.

Let’s say a topic in the broad sense of the word, a language, or a programming subfield has emerged that interests me or seems in demand, and the list of repositories and libraries I need to understand this specific project, seemingly only one of which, grows. I’m tempted to brush them off— go ahead, go ahead, there’s no time. It’s time to code, not read manuals.

True, there’s a vague feeling, like, “Why are we running? Stop, go into this room, the repo, I mean, and look around.” But the problem is, as soon as you get stuck, you want to look at the code, but the explanation isn’t clearly written—there’s no end in sight. Besides, what do you mean, “read the code?” First, learn the syntax, the library dependencies, and only then. That’ll take a fair amount of time.

There are people, I believe, who read the summary and the comment — they understand what it’s all about, which, frankly, rarely happens to me. What means this variable in the config? At once I want to write a test, to create sandbox solution to check purpose. Ah, now it’s more or less clear.

A virtual conversation with manual developers.

“Why didn’t you tell me right away?”

“We did.”

“Where?”

“Well, on page 5, in the footnote.” And anyway, this is an advanced level. If you want to participate and commit to our project, then it is ok, but otherwise, you don’t really need it.

You’re so great, thank you, sorry for bothering me. And you’re thinking, it would have been better if you’d explained it right away on the first page. Or you’re simply saying, “Don’t read our manual at all, check out unittests.” You know, not every test will help. A test without knowledge of the codebase can be incomprehensible. Functional tests are generally like that. Although some are exactly what you need, they demonstrate the concept you’re trying to understand.

They actually think the comment is clear and sufficient. I think so myself when I write. Time passes, and everything ends with complaints about oneself Why didn’t I write more in detail?

Because they’re in the context, they understand why this library, class, or module is needed. Many things seem obvious to them. But not to me.

You’ll glance at it for five minutes, and end up stuck for who knows how long. It says “cutting-edge helper” or “core” for something obscure. What “core” is, who knows, but there’s all sorts of interesting and useful stuff there.

Without looking into it, without understanding it at the beginning, you’ll keep stumbling across this word or concept as you read manuals or program. You know roughly what it is, but what it actually is isn’t clear. And the method’s calls and specifics remain “behind the scenes.” This can go on for years.

If you don’t look into it, you’ll remain dependent on other people’s opinions, and if you stop and look into it, it’ll waste a ton of time. You don’t know yet whether you’ll get results, whether you’ll understand how it all works—that’s not a given. And it takes a long time, you see.

In my opinion, it’s worth doing. But I don’t have any firm arguments against it. And from the very beginning. Before, instead of reading code, I programmed everything. Often, no one asked; I could have done without it; I wanted to be helpful. And I wasted a ton of time, really. And when you finally decide to dig under the hood, it turns out it’s time to learn other libraries. Maybe I should have done it right away; it would have been more useful.