I don’t know if that is just me, but for some reason, Wikipedia articles are only good when you already know the subject. If a few years ago I would open the Wikipedia article about the mutex to learn about it, I’d likely have about the same level of understanding plus the feeling that it’s all very complex and maybe I should be doing something else.
A formal definition is not a good way to learn a new concept. It’s much better to have an illustration even though it would inevitably be somehow inaccurate. But not every illustration is good.
Let’s consider a classic algorithmic problem — string rotation. Given a string and offset, we should return the rotated string. That is for “Matrix” and offset equal to two the result would be “ixMatr”:
— Hey Alice, I was wondering if you could help me with one programming question. Namely, the second hard problem in computer science.
— Sure, what are you trying to name?
— I made a class which holds
database and provides a set of methods related to database things.
— Why not name it
Repository? — Well, the R
epository is actually a client of this class. The component I’m working on right now provides reliable access to C
offee. One part of it is C
offeeRepository with usual search-find-get-whatever methods. This C
atabase and a bunch of things related to it, such…
There are quite a lot of resources that teach how to solve algorithmic problems, and in general, how to ace technical interviews. A lot of people and companies teach how to get hired. But it seems there are considerably fewer people and companies that focus on what happens after you get hired.
Doing work and delivering software that solves problems is the best way to grow, but oftentimes this growth has a limit. Not every project has to handle several thousand requests per second, process terabytes of data, or provide the best performance possible. …
There is a phenomenon called “Illusion of understanding” — a sense of confidence that “I know the topic” while, in fact, that’s not true. Every time I see an article with a title like “X things to be more productive,” “Y things to do in the morning,” or “Habits of successful people,” I feel that these should be taken with a pinch of salt. More often than not, they create an “Illusion of understanding” regarding the topic of productivity.
I’m not trying to say these are somehow bad articles, not at all.
Some items in those articles tell about smart…
April 28, 2098, San Franciso Chronicle
If someone would ask you “what is the most influential technology company of the XXI century,” the answer would be obvious: Udrive. This ride-sharing company that started off as a smart taxi service that let ordinary people earn money by driving people to their destinations has shaped the modern world like no other company did, even though most of it wasn’t planned.
That’s the wonderful and terrible thing about technology. It changes everything.
— I’ve been thinking about money recently. Specifically, how do I earn it?
— That’s an interesting topic. What do you have in mind?
— You see, I like my current job. There are challenges to take on, I care about people in my team, and it pays ok. There is one thing though which I sort of like and dislike at the same time. Whatever happened, I would get a fixed amount of money twice a month.
I like it because it gives a sense of safety — if I get cold, I could spend a few days not…
When I was preparing for technical interviews I was lucky to get some help from friends who has experience with programming contests. One of the valuable lessons I learned was about solving the problem before coding it up: I thought I was doing it, but it turned out I was doing it wrong.
There are a lot of good resources about technical interview preparation and some of them suggest to perform the interview in 5 steps:
There is a concept in software engineering called “technical debt.” It’s when you do something you know is not right, but you are still doing it. As some meme was saying, “we do something not because it’s easy, but because it seemed easy.” So something seemed easy, it took (hopefully) less time to implement it, but now it causes troubles. This is technical debt.
Some project tracking tools consider the output of static analysis tools (such as pmd, findbugs) as “technical debt.” The method is too long, a duplicate string literal, don’t overcomplicate comparison, etc.… Such findings could be useful…
A few weeks ago, I got an email from Amazon with a book recommendation, and I was about to follow the usual “take a quick look — archive” routine, but this time the recommendation was good. The book was called “Streaming Systems,” and it had the same red O’Reilly design as “Designing Data-Intensive Applications.” With the hope that the former would be similar to the latter, I’ve placed an order.
It feels great to order and receive books, but it’s an entirely different story to read them. It is exciting to open the package and take a look at the…
Software engineer @ Google