The characteristics of weak programmers

Sevenall Bin
7 min readJun 12, 2022

--

Programmers at work

First of all, it is stated that

  1. The following characteristics are real encountered, colleagues have committed, and even I myself have committed.
  2. For the sake of plot needs, some examples of exaggerated modification and other deductive creations, such as no similarity, please do not be angry.
  3. If you have had one of the following symptoms, does not mean that you are weak, but if you have been appearing, and even when it comes to this everyone can associate you, then you have to be careful.
  4. If you are a set of these few of the great multipliers, congratulations, you have found a good reason to leave the industry.

There, done!

“Is that bug solved?”

“Well, it’s done!”

“That fast?”

Just when you’re very pleased, there’s the bad news: what was compiling successfully a moment ago has failed. (Well, our integration compilation hasn’t been successfully configured yet, and theoretically this kind of thing should be returned.) Or maybe it compiles successfully, but then a dropdown box that was clearly working suddenly goes nuts and doesn’t work. There is nothing more insidious than when everything works, but when you see the code, you faint. For example, we once found a bug that simply means that every time the user clicks on something, the following C# code is executed:

controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

This bug will obviously lead to increasing slowdown, because the same update operation will be updated N times, and this N will get bigger and bigger. In fact, this bug was weak enough, but then it was actually modified to:

controlPropertyPanel.PropertyChanged -= this.UpdatePropertyOnChanged;
controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

This code compiles and executes, but it’s just weak. Because not only does it not fundamentally remove the logic that is causing the problem, it creates more confusion: why subtract before adding?

For this kind of feature, please take a look at the interesting “Various Popular Programming Styles”, my example is kind of a hit and miss. I think this kind of problems are caused by trying to solve something superficial for the purpose of solving it, without caring about any other problems underneath.

That’s probably his bug.

“Why hasn’t this problem been solved?”

“I think it should be a bug on his side there, I can’t adjust it.”

“Oh ……”

The “he” can be a colleague, or a former colleague, or Microsoft, or some other company, or the author of some open source code. I’ve encountered all of these, for example, another colleague who is currently working on it. When you tell this colleague that the bug seems to be with him, and ask when it will be fixed, he may be very guilty of debugging it immediately, but the end result is still the same as the problem with the code written by the owner of the opening conversation.

Then let’s say it’s Microsoft, then the conversation might include: “Ah, SilverLight really sucks, always memory leaks, crashes, etc. ……” “Yeah, yeah, yeah! It sucks! I should have known to use Flash.” Or maybe they will say, “Microsoft just sucks, Java is good.” In fact, I don’t want to compare SilverLight or Flash, .NET or Java, because before discussing these issues, it’s better to think, is it really someone else’s fault? It’s easy to believe that it’s someone else’s fault, because then you can just do nothing and it’s not my fault anyway.

If you really found out that it was someone else’s bug and proved it, that would be nice. But this feature is a pure suspicion, and not the slightest proof. After carefully looking for all the mistakes you could have made, if you suspect that it is someone else’s problem, then ask for proof.

No pictures, no truth!

“Owner, no picture no truth ah!”

“Owner, no code no truth ah!”

“Owner, give a translation!”

It is said that Linus answered “Read the fxxxing source code” when someone asked what is the problem of Linux memory management, and many times I have a similar impulse. I find that in the age of advanced information, many people’s reading and hands-on skills have seriously deteriorated. These people are best if you personally help him to solve the problem, he does not want to understand what happened inside. This problem is reflected in the blog, is to hope that you write a picture and text, the picture is the best fancy at the same time simple and meaningful, the text is the best big paragraph of code. In fact, the diagram is not important, just to look good, the focus is on the code, so that he a Copy can directly solve their problems.

For example, Silverlight does not have a variety of image formats inside the encoder, so when you want to save Jpg how to do it? I downloaded it and ran it, and alas, it worked. After that, I just signed in and didn’t take a look to see if there were any problems or unreasonable design. (Actually, it’s really slow, because there are a lot of unnecessary array copies.)

Or, if you encounter a bug, search for it and find out, hey, someone has really encountered it, and there is code hey! The code is stripped down to a run, and it seems to be solved, but it doesn’t matter why. And even encountered simply do not care whether to solve the problem, anyway, the code down to sign into the.

NET compiled text size, which mentioned many concepts need to read an official Microsoft document first. As a result, there are still people who reply that you mention so many Blob in that article, and don’t say what’s inside the Blob, probably very dissatisfied. But this document has everything, can’t you read it yourself? In fact, even if I do not even give this document, you should have the ability to think about it and find it yourself.

Don’t degenerate into a person who has to be chewed up by others to be able to swallow anything, and swallow it won’t be digested and absorbed. Such a person is probably given a stool, as long as there is a code without the truth, will also eat it as it is. If this is true, then how do you plan to improve it?

That’s an object!

“This ExpressionVisitor, what is it used for?”

“……”

“Well, or put it this way, what is he a thing?”

“He’s an object!”

“Huh?”

“Oh, it’s an instance of an object.”

Probably the same answer as the Microsoft engineer who said “you’re in a helicopter” — you can’t say it’s wrong anyway, but it just doesn’t make sense. There is nothing wrong with not knowing, people are not gods, how can they know everything? Not to carefully understand and study the problem is not serious, because you can change. But when you habitually find a random answer that is absolutely right but does not explain any problems, or even plausible things to deal with, you are very close to the edge of weakness.

Of course, the conversation above is perhaps more extreme. A slightly weaker version of the conversation would be.

“How is this memory leak caused?”

“Well, could it be that the image was placed in the wrong place?”

Ha, still an exaggeration, right? I can’t help it, blogging sometimes requires exaggerated words, otherwise you can’t understand what I mean is that sometimes, people tend to look for similar items from their own memory and then choose the one with a higher degree of similarity that they think is the answer, regardless of whether there is even a hint of logical connection between the two. It may be true that often we need to start with something similar, but please don’t take it as the end. The program requires rigorous logic, so you must also be very rigorous to deduce.

There are really too many questions about this, for example, I point to the bolded part of the following code.

var dictionary = new Dictionary<string, string>();
dictionary[“someKey”] = “someValue”;

“What does this sentence say?”

“It shows that dictionary is an array.”

The Collector

Finally, let me give you an example of a masterpiece, say, there is a task to add a “favorite this site” on top of the SilverLight application. Okay, how to solve it? A quick search on the web reveals a lot of code that looks like this.

function AddBookmark(Url, LabeName) {
if (document.all)
{
window.external.addFavorite(Url, LabeName);
}
else if (window.sidebar)
{
window.sidebar.addPanel(LabeName, Url, '');
}
}

Then just pick it up and put it on, somehow call this JavaScript in SilverLight, sign in, done! The result to the test side found that it does not work at all, whether in IE6/7/8/9/10, or in FireFox/Safari/Chrome above, can not be used. I asked.

“What’s the reason for this?”

“I don’t know, anyway, the browser reports no permission, maybe it’s because of the browser’s security settings, or a bug in the operating system, or maybe it’s some kind of bug in the browser?”

“That can’t be right? The code has existed for many years, to have a problem would have been able to search the Internet long ago.”

“Then maybe there is some security problem when SilverLight is called. SilverLight is so annoying!”

“Then how come it hasn’t been solved yet?”

“Okay, I’ll fix it right away!”

Soon, the Javascript became.

function AddBookmark(Url, LabeName) {
try
{
if (document.all)
{
window.external.addFavorite(Url, LabeName);
}
else if (window.sidebar)
{
window.sidebar.addPanel(LabeName, Url, '');
}
}
catch
{
alert("Your browser is unable to add favorites because of security settings, please add favorites manually!");
}
}

I was completely shocked to see such code. After debugging it myself, I found that it did report a “no permission” exception. However, I also found that the value of the Url parameter was “www.adomainname.com\test\page.html". Well, that’s bullshit! The browser thinks you want to collect a path on a local hard disk, how can it allow such a path on an Internet Zone? I then pointed to the code and asked.

“What’s this Url?”

“It’s a variable.”

“Huh?”

“Oh, no, it’s a parameter.”

Have you had a similar experience?

(end)

--

--