1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="author" content="aki">
<meta name="tags" content="blog, programming">
<meta name="published-on" content="2024-09-01T14:56:39+02:00">
<link rel="icon" type="image/png" href="favicon.png">
<link rel="stylesheet" href="style.css">
<title>It Works, but I Don't Know Why</title>
<header>
<nav><a href="https://ignore.pl">ignore.pl</a></nav>
<time>1 September 2024</time>
<h1>It Works, but I Don't Know Why</h1>
</header>
<article>
<p>We had mostly clear sky for about four days now. Maybe a little cloud here or there. Because of it, I have severe
withdrawal symptoms from not yelling at clouds. It is time to preach pointless stuff on my blog.</p>
<img src="it_works_but_i_dont_know_why-1.png" alt="old man yells at cloud">
<p>Among programming related jokes there is a certain subset centred around chaos. They usually contain references to
bad programming or communication practices, not knowing why observed behaviour occurs, nonsensical error messages,
improvised solutions, or similar things. The general notion can be described as "nobody actually knows what they are
doing here."
<p>A good chunk of them is funny. A cat walking on a keyboard resulting in a regular expression? Yeah, throw a typical
C++ type_traits meta-programming there while we are at it. A side-effect-driven behaviour resulting in unclear states?
A regular day with bad OOP. Problems communicating with non-technical staff? All of the original jokes have a good basis
in the real world. They are a result of humour and/or frustration. It's fun.
<p>Over last couple years I met an increasing number of students, newcomers, juniors, or even seniors that take these
jokes a bit too seriously. Although, it's an increase from 0-1 to maybe 2-3 per 40 or 50 people. It's a bit worrying.
Hopefully, I just got a bad roll on the population sample.
<p><em>Excellence is cool</em>. Making things work is amazing. The key to that is understanding what you are doing and
why. Copy-pasting things and "mutating" code until it compiles might be funny in a joke, but witnessing that at work is
tragic and infuriatingly painful to deal with.
<p>It's OK to make mistakes. It's fine to take time to understand things. Code rarely needs to be near perfect and very
often assumptions, unhandled cases, lack of modularization, and/or known failure conditions are acceptable. In some
cases we get more budget and time, in other cases we get stricter audits. In yet other cases we get a ticket straight to
hell. Nonetheless, every time I want to strive to make conscious and informed design and implementation decisions. Even
if that decision is "we won't do it."
<p>Will the code be "good"? Maybe. One thing is for sure: I will be able to explain why it was written that way.
<!-- And of course the "whys" are usually best documented. These are usually among the most meaningful notes. -->
<!-- See also: architectural decision records -->
</article>
<script src="https://stats.ignore.pl/track.js"></script>
|
