www.yegor256.com Open in urlscan Pro
185.199.109.153  Public Scan

Form analysis
1 forms found in the DOM

GET https://www.google.com/search

<form method="get" action="https://www.google.com/search" itemprop="potentialAction" itemscope="" itemtype="http://schema.org/SearchAction">
  <meta itemprop="target" content="https://www.google.com/search?q={q}"> <input name="sitesearch" value="yegor256.com" type="hidden"> <input itemprop="query-input" type="text" id="search-query" class="field field-text" required="required"
    onfocus="$('.google').css('visibility', 'visible');" name="q" placeholder="Search..." autocomplete="off"> <input type="image" src="/images/google-search-icon.svg" class="google" title="Search via Google" alt="Search via Google">
</form>

Text Content

☰
Subscribe
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 
 * 

 * Home
 * 12 Best
 * All 396
 * Teaching
 * Talks
 * Books
 * Research
 * Pets
 * Testimonials
 * Shift-M
 * Art
 * Политика





RESEARCH FLOW

 * 6 February 2024
 * 616 words
 * 3 minutes to read
 * 2 comments
 * 

Say, you are a student, and I’m your teacher. Your task is to conduct an
experiment or a study and then write a research paper about it. You can do it on
your own and then present me with the results in the end. Sometimes it may work,
but most probably it won’t. I will have many comments, suggestions, and plain
simple disagreements with your research questions, results, or conclusions. Just
like in software engineering, the Waterfall approach is not an effective one.
Instead, an incremental and iterative workflow may yield way better results: you
take a small step forward, we discuss it, you rewrite, we agree, and you take
the next step. The ultimate objective is to write a paper that will be published
in a good journal or presented at a decent conference. Well, yes, a passing
grade is also an objective.

Continue...


DEFEND ME AGAINST CHATGPT

 * 26 December 2023
 * 640 words
 * 3 minutes to read
 * 16 comments
 * 

I do enjoy ChatGPT a lot. The blog post you’re reading now was written by me and
then given to ChatGPT to fix its grammar and polish the writing style. Until
recently, since 2014, when I wrote my first blog post, I used the service of a
few proofreaders, who charged me $20-40 per hour to rewrite all of my 350+
texts. Now, I pay a few dollars a month to OpenAI. However, while the value of
this generative AI is obvious, I also experience serious harm from ChatGPT,
especially when reading papers written by my students with its help.

Continue...


REVIEW A RESEARCH PAPER: CONSTRUCTIVE CRITIQUE IN FIVE STEPS

 * 17 December 2023
 * 797 words
 * 4 minutes to read
 * post a comment
 * 

I’m helping organize the ICCQ conference this year for the fourth time, with the
in-cooperation support of the IEEE Computer Society. Based on this short-term
experience, I can assert that reviewing research papers is a skill that even
some reputable and experienced academicians either don’t possess or are too lazy
to apply. We often encounter sketchy, subjective, and disputable reviews that
don’t assist authors but only frustrate and discourage them. In this short blog
post, as an absolute amateur in the subject matter, I will try to summarize how
to review an academic research paper (thus mostly helping other newbies).

Continue...


RESULTS AND DISCUSSION: FACTS AND INTERPRETATION

 * 11 December 2023
 * 802 words
 * 4 minutes to read
 * post a comment
 * 

Almost every empirical research paper contains two essential sections: Results
and Discussion. The former presents the facts collected through the research
method, while the latter interprets them to answer the research questions. When
interpreting the data, you must address the most obvious concerns that readers
may have. For example, in the Results section, you might state: “85% of
respondents refused to participate in our survey” (this is a fact). Then, in the
Discussion section, you might say: “We believe that programmers are innately
lazy and irresponsible” (this is an interpretation). You might also add,
“Perhaps not all of them were lazy, but just busy.” While the Results section
leaves no room for doubt, summarizing findings “as is,” the Discussion section
engages in an open debate with an imaginative reader.

Continue...


BE INDIRECT IN YOUR RESEARCH QUESTIONNAIRE TO GAIN MORE HONESTY

 * 28 November 2023
 * 722 words
 * 4 minutes to read
 * post a comment
 * 

Let’s say you are conducting research to discover programmers’ opinions about
their work environments: whether they appreciate their office spaces or not.
Preparing a survey with a few questions is essential. Their responses will
reveal their thoughts and feelings. After working with several student groups,
I’ve noticed a common mistake in questionnaire design—they are too obvious with
their questions, simply asking, “How do you feel about this?” There’s a more
effective approach.

Continue...


AVOID SOFT LINE BREAKS INSIDE A PARAGRAPH

 * 22 November 2023
 * 380 words
 * 2 minutes to read
 * post a comment
 * 

An email, a document, a research paper, a presentation, and even a JavaDoc code
block consist of paragraphs, which are “self-contained units of discourse in
writing dealing with a particular point or idea.” Visually, paragraphs are
supposed to be separated by a vertical space that is a bit larger than a
vertical spacing between lines. To achieve this, for example, in HTML, we wrap
paragraphs in the <p> tag, while in LaTeX, we use \par or just an empty line
between them. However, some people insert what are called “soft line breaks”
inside paragraphs—this is a bad practice that I suggest you stay away from.

Continue...


THE METHOD SECTION: A RECIPE FOR RESEARCH

 * 11 October 2023
 * 717 words
 * 3 minutes to read
 * post a comment
 * 

Every empirical research paper must have a section titled “Method” (or
“Methodology,” or “Study Design”). In this section, you describe what was done
to obtain the data presented in the following “Results” section. You explain the
recipe, which may be replicated later by another researcher, leading to the same
(or very similar) results.

Continue...


RELATED WORK: A CRITICAL TAXONOMY OF PRIOR ART

 * 29 September 2023
 * 741 words
 * 4 minutes to read
 * post a comment
 * 

In almost any research paper, it is mandatory to have a section titled “Related
Work” (or “Related Works”), where you refer to the results previously obtained
by other authors or yourself. By including this section in your paper, you are
not only paying respect to those who laid the foundation for your results, but
also motivating and guiding your readers. Most of them may not be aware of
existing studies or the importance of the problem you are solving. You must put
these guys into context.

Continue...


FIVE INGREDIENTS OF TECH CAREER

 * 19 September 2023
 * 680 words
 * 3 minutes to read
 * post a comment
 * 

A friend of mine recently asked me what five things he should do in order to
grow his technical career in a big company. He is not interested in being a big
manager, or a CEO. Rather, he wants to be a software expert, an architect, an
owner of a technology, and eventually a “Fellow.” I’m not sure I was qualified
to give such advice, but I did anyway. This is what I told him. Maybe this will
also work for you.

Continue...


BIBCOP: STYLE CHECKER FOR BIBTEX

 * 5 September 2023
 * 810 words
 * 4 minutes to read
 * 2 comments
 * 

Almost every document you may write in LaTeX format will have a list of
references at the end. Most likely, you will use BibTeX or BibLaTeX to print
this list of references in a nicely formatted way. It is also highly probable
that your .bib file will contain many typographic, stylistic, and logical
mistakes. I’m fairly certain that you won’t find the time to identify and
correct them. As a result, the “References” section in your paper may appear
sloppy. I suggest using the bibcop package, which identifies mistakes in the
.bib file and auto-fixes some of them.

Continue...


ROBOTS VS. PROGRAMMERS

 * 29 August 2023
 * 1140 words
 * 6 minutes to read
 * 8 comments
 * 

The release of ChatGPT 3.5 has changed everything for us programmers. Even
though most of us (including me) don’t understand how it works, some of us use
it more frequently than Stack Overflow, Google, and IDE built-in features. I
believe this is just the beginning. Even though, only Microsoft knows what will
happen next, let me try to make a humble prediction too. Below, I list what I
believe robots (with Generative AI on board) will do in the future. The further
into the future, the lower on the list. I tried not to repeat what GitHubNext is
already saying.

Continue...


FAST TESTS HELP HUMANS, DEEP TESTS HELP SERVERS

 * 22 August 2023
 * 1255 words
 * 6 minutes to read
 * one comment
 * 

In order to reveal errors of higher complexity, automated tests are turned into
integration tests that involve external resources in test scenarios, instead of
their mocks. While this approach improves test coverage, it slows down the
entire build pipeline. This compromises the very idea of automated tests, which
are meant to be a safety net and help programmers edit code safely. Splitting
the tests into “fast” and “deep,” and then allowing humans to run the former
while servers run the latter, might be a good solution to the problem.

Continue...


THE DOUBLE-BLIND REVIEW IS WHAT MAKES DECISIONS FAIR

 * 15 August 2023
 * 788 words
 * 4 minutes to read
 * 6 comments
 * 

How does your team review ideas, project proposals, or paper drafts? Imagine I’m
on your team and I need a budget allocated to a new project. I craft a proposal,
elucidate the motivation, assess the risks, develop a plan, and then what? Do I
create a PowerPoint presentation, present to my teammates for half an hour,
answer their questions for another half hour, hear their honest feedback, after
which they vote and a decision is made? If this is how things are organized
within your team, you risk stifling creativity and motivation.

Continue...


IS TWO-STEP INITIALIZATION A SOLUTION OR A SYMPTOM?

 * 8 August 2023
 * 2818 words
 * 15 minutes to read
 * 6 comments
 * 

At times, it might appear practical to execute additional initialization steps
for an object after its constructor has completed. However, I’m of the belief
that such requirements signal underlying design flaws, such as object
mutability, base class fragility, violation of layering, and unfocused
abstraction. A constructor should be good enough for all scenarios. If it’s not,
refactor the object.

Continue...


THE HIDDEN DANGERS OF METHOD OVERLOADING

 * 1 August 2023
 * 933 words
 * 5 minutes to read
 * 24 comments
 * 

Method overloading is a common feature in many programming languages that allows
a class to have two or more methods with the same name but different parameters.
According to Microsoft, method overloading is “one of the most important
techniques for improving usability, productivity, and readability of reusable
libraries.” I disagree. In my opinion, method overloading may lead to less
readable code and more bugs, because maintaining two or more implementations
under the same name gives rise to concealed semantics, which inevitably result
in misunderstandings and functional defects.

Continue...


A DISABLED TEST IN LIEU OF A BUG REPORT

 * 25 July 2023
 * 618 words
 * 3 minutes to read
 * post a comment
 * 

When you find a bug in an open-source library that you use, what do you do? You
submit a GitHub issue (or whatever ticket tracking system they use). In the
issue, you describe the problem in the best possible way, preferably providing a
working code example that the author of the library can run locally to reproduce
the bug. If you don’t provide them with an executable snippet of code, they will
most likely ask you to do so, unless the bug is trivial. I suggest simplifying
the workflow and giving them what they want right in a pull request: send them
the bug in the form of a disabled unit test.

Continue...


page 1 of 25