Last week I stumbled upon Slides of Keith O'Conor's talk about performance optimizations and it reminded me of a topic I wanted to write a blog post about for several months.

So this is the post.

Information sponges

I have a huge list of RSS subscriptions and usually scroll through ~500 articles a day adding 10-30 of them to Pocket to read later. Which I rarely do. Most likely that you do the same. Because there's just too much information on the internet even if you read only blogs about software development.

I call people as myself "information sponges" because we try to absorb as much information as possible on a daily basis. Maybe some day this data will be useful...

And there's nothing bad about it... Nothing bad as long as you reflect on this information and don't catch yourself into a trap of partial filtering.

And this is what junior developers never do. Let me explain...

Partial filtering

All good talks and articles on the internet which give you insights on new technologies, methods, patterns and algorithms always specifically point out WHEN these algorithms should be used and what problems these new technologies are trying to solve.

The thing is that being overwhelmed by awesomeness of these new methods it's easy to filter out the information about when they should be used.

For example you might watch a video from a conference where a well-known speaker tells you how awesome MVC is. Of course explicitly or implicitly he will mention the problem which MVC solves. Because it's not just abstractly good, MVC is a solution to the specific problem (try to test yourself and say out load what this problem is).

Partial filtering is when you remember only that "MVC is awesome" instead of "MVC is a great solution to this specific problem".

Another good example is optimization. There are tons of great articles and talks about how to optimize stuff.

All of them usually mention that these are solutions to specific performance problems. If you don't have these problems don't try to optimize your code. You will just waste a lot of time and make it unreadable. Unfortunately this part is usually ignored.

The paper I started from has a slide on this topic.

This slide should have been in the beginning. With bold red text and images of dead programmers who didn't profile before optimizing.

Someone on the internet said to do so

And here's where it gets interesting.

Imagine a junior developer who is an information sponge (nothing bad so far), who unwittingly applies a partial filter to all information he absorbs (not so bad either), who thinks that because he absorbed all this information he is an uber developer now (not that fatal) and who doubts every single word from you contradicting to this filtered information especially when the information was presented by some authoritative person from Microsoft, Adobe, Oracle, you name it. Not just questions your opinion but he is totally sure that if that person on the internet said something you must be a total fool if you say something opposite.

Most of the time it goes like this:

— Damn, why did you code this monstrosity? Why didn't you use this easy built-in mechanism this framework gives you?
— The guys from Adobe say it's more performant.
— It might be faster on shitty mobile devices, we are running the app on Intel i7.
— But the guys from Adobe say...
— They say it for mobile devices.
— Whatever... (meaning "you don't know shit and you are no authority for me")

Once I even had this conversation which completely pissed me off:

— The library was not made to be used like you are using it. But now we have to do this because you ignored this easy mechanism provided by the framework and we don't have time to rebuild the whole thing.
— Who said that this library shouldn't be used this way? (meaning "give me a link to a video where someone from Microsoft says not to use the library this way")
— Me, the freaking author of the freaking library said that for fuck's sake.

Reflecting on yourself

Long time ago I was building a simple messaging system and was taken away by that object pooling strategy I learned from some blog. Of course I implemented it straight away just to be asked by my coworker:

— Why the hell did you do this?
— For performance, it caches message objects.
— Right... how many messages are you going to receive per second?
— Like... 1...
— Do you understand now?

Of course there was no point implementing message pooling system here. And I wasted half a day on this simple task trying to optimize the problem we didn't have.

This is a part of your learning curve — making mistakes and reflecting on them later.

I obviously had a mental filter which dropped the information on what problem this technique is solving. From that day I'm aware that while consuming information I might unwittingly activate such filter, so after reading a blog post or watching a talk I try to reflect on the information i received and how I understood it.

Dealing with such people

Personally I don't know how to deal with juniors for whom you aren't authoritative enough. It might be a coincidence but lately I'm meeting such people more often. Is it the new generation which can't handle information overload? I don't know.

I think that a junior developer must first accept that he is junior (though there's no definition here and a programmer with 5 years of experience may be as junior as a college graduate after all) and then learn hard from practical tasks and experienced colleagues.

The person described is unable to do both.

Another thing is that unfortunately I don't know anything about you as a reader of this blog. And this person might as well be you. Even if it's true you won't be able to accept it.

Think about it, reflect on yourself and don't ever blindly beleive what someone from Microsoft, Adobe, Oracle, you name it, said on the internet... or YOU think you remember what they said.