Context switching in your mind

Imagine yourself doing 3 tasks paralelly, each taking only small portions of time with long pauses between them! Like talking to 3 persons on the phone - each of them is mostly silent, only once in every 2 minutes they ask you a question, continuing the thread of the conversation!

Obviously, you won't have a problem with collision. They patiently wait for each other so you never have to talk to two of them simultaneously. The big problem you will face, however, is context. You'll have to remember each conversation to be able to continue. Jane is talking about her private life, Peter is organizing poker for the weekend, Vanessa is asking you about the weather. You have to remember who said what to keep up with them. Not just the last line but rather a full history of the conversation because they will continue referring to their own stuff being said earlier.

When web servers do it

What you need is called context switching. The ability to pack up all the things of one conversation, store it temporarily, then load another and unpack it in your mind, recalling what you were talking about. After you added one line to this conversation, you pack the whole thing again and load another, etc. Context switching takes a lot of web servers' time today; they're running several threads, hundreds or even thousands, and before they serve a certain request, they must be able to quickly get back into context, get an understanding of what this thread is doing. Multi-process web servers typically do this; multi-thread ones sometimes don't but they have a similar mechanism, only faster.

When human minds do it

There are small problems that fit in your mind altogether, without the need of slicing them up to smaller pieces. That's fine. But as soon as you think about something more complex, you suddenly can't live without dividing it into sub-problems, solve them first, then take the conclusions with you and deal with the main issue, now equipped with many partial results. This is how your mind copes with questions too big to fit in at once. This is how you do programming - almost every time.

Now the key to be able to do this is - guess what! - context switching.

If you're good at this, you can easily work on one part, then pause and work on another, then go back to the previous one, and, sooner or later, you'll get the whole job done. The frustration of losing one bunch of details while working on something else is well known to all of us: it happens when we're not good enough in keeping several contexts in mind. So just feel free to use any tool, from notepad to hotkey-triggered sound recorders, to extend your mind and make it able to remember virtually everything; if you know where you've been in a subprocess, you'll be able to efficiently continue it as soon as you return. It's crucial when you're working with big concepts.

But, more people...?

Some textbook methods suggest that you need a team for these jobs. I don't think so. I think you can just use your "external memory" to remember everything, but it's simply not worth it to introduce other minds into your work only to be able to hold their own contexts and save you from having to switch a lot. Don't worry, whenever you hire people to help you with different parts of your project, you'll eventually find yourself switching between them, trying to control every thread to make them run paralelly and maintain the ability of merging them together at the end. It's a lot more time and effort. Three or four programmers, working on the same project, are always slower than just one.

Don't believe me; that's only my opinion. But check the "Tools" section and remember that the most cutting and professional tools are created (and maintained for a long time) by only one mastermind. Teamwork is complex; don't overuse it when the problem is only that you're not comfortable with switching.

Improve yourself and work alone until it's absolutely inevitable to involve others.
That's the best I can say.

Evolution, reinvented

Amazing how a very simple site takes more time to create in 2016 than any complex solutions did in 2001. One possible explanation is that I'm getting older and my performance is decreasing - but no, can't be that. I still know all the oldschool techniques and I can work with them; it's still no problem to hack together a simple HTML based page in a plaintext editor. It's still no problem do to things fast & dirty; the modern way is just different. We need to be more readable, more maintainable. More interchangeable. Do we achieve these goals? Never. I mean never. Everyone keeps telling me they're doing this, and everyone is pretty sure that they've documented the source well enough for anyone else to understand; to just grab the concept and go on working from where the original author left off. This is freakin impossible.

Half in the head

It's a complex truth, can't be easily explained, you have to be in the middle for quite a time to fully understand why it doesn't make any sense to "continue someone else's work"... But it's just weird. Half of your work happens in your head, and the other half is the source code itself. That is, if you document very thoroughly and you make beautiful, super-readable code anyway. But most of the time you don't. Most of the time you fight with the devil inside to meet your deadlines and pray every night to make the whole thing work at least on the single day you demonstrate. Most of the time you spend 50% of your energy on looking like a professional and 50% on trying to catch up with your image. So no, your code won't be beautiful. Your code will be a decent average product with minor inconsistencies and a lot of undocumented lines. Now even if you did everything right, there's still no chance that when you've left the project, someone else will just pick up all the pieces and put them together the exact same way they were. He'll suffer, he'll look for answers and find most of them, but never all of them - and the rest will be filled with his (or her) own personal style.

Understanding someone else's source

Imagine a book, cut in half along the vertical axis, in a way that every single page, every single piece of paper gets split into a left and a right half. And then, someone burns the right half - it's gone forever.

Now try to read the book.

Obviously if you read a lot, and you know something about the story anyway, there will be things you understand right away. Later, many other pieces will find their right place and the details of the story start to connect to each other, the whole thing starts to take shape, but it's still a bit fuzzy. You make assumptions, educated guesses about the other half of certain lines - you may be right, you may be wrong. You understand now what the book is trying to tell you, and you can even complete some lines, restoring the other half from your imagination and from pure logic; the result will be another book, very similar to the original one in a certain way, but also very different.

Now what if the book wasn't even complete? And you have a contract that says "you have to finish this book by December". You have to make up the rest of the story, using the characters you figured out, to a certain extent, using the storyline you've decoded with more or less success... I guess you figured out my point. What readers get is a fresh, interesting style on one hand, and a noticable quality loss on one other.

Why software is never complete

Also, this is not a book. This will never "end" in a classic way; a source code is not printed on paper, therefore it can (and will) always be altered, to cater any future needs of the customer and/or fix obvious bugs. A book is exactly what it is: a static collection of words that can never change after printed once. But softwares keep evolving, new versions appear, they have tons of new features, etc. So there is no point in spacetime where you can just kick back and relax about your product. Either you abandon it and don't care about it anymore, or you'll constantly work on it. It's a living creature.

For these two reasons (people changing, project changing) a new way of programming is awakening right as we speak. It's coming out of the deep waters right now, we only see its back rising but we already suspect that it must be something huge and furious. It surely has teeth and claws. And it knows all about us.

The Change

It will happen gradually. First, we invent techniques that don't work. I think we're a little past this point. Then we start to improve them, being constantly chased by the industry's killing pace. Tehn we realize we're going nowhere and take alternative routes. And, after a while, we realize that we're still carrying some heavy old chains that we can now live without - this will be the moment of clarity for modern programming. I can't tell what we're gonna drop; plain text sources? DocBlocks, structured programming, multilevel inheritance? Maybe a new language will emerge from the darkness? Maybe we find something better than OOP? Who knows.

But I can tell you, a time must come when we know enough to really work faster than 15 years before. Because that's something we can't do right now.

And it's horribly frustrating.