printfdebugging - programming

iteration is a feature, not a bug

2026-03-10T00:00:00+00:00

there are some interalized biases that new programmers like myself have towards getting it right in the first go, and thus we keep thinking about it, going in circles reaching nowhere. a better way would be to just quickly put together an unoptimised version of the solution, doesn't have to have a structure or design.</p>

then as you have something which works, it's far easier to just rewrite it a few times before you have a really good solution. this is often faster than thinking more and writing less code. note that this doesn't apply to all situations quite literally, but some form of prototyping (or prior experience with code) is required. iteration is a feature not a bug.</p>

refactors don't have to be messy

2026-03-05T00:00:00+00:00

part of being a good developer involves thinking backwards from the users' and the reviewers' perspective for the ux and the code respectively. there's a really easy thing you can do to make commits less messy.</p>

if you are refactoring a function i.e. creating a new function out of it's body, then you should place the new function "physically away" from the old function in the file. that way git diffs won't be messy. take the following diffs, both do the same thing with the difference being the physical location of the new function in the file.</p>

easy to review</h2>

  1</span>  2</span>index 39afd0963606..1e48e6e04afa 100644</span></span>   3</span>---</span>  4</span>+++</span>  5</span>@@</span> -912,52 +912,12</span>  6</span> </span></span>   7</span> IMPL_LINK_NOARG(ScCheckListMenuControl, LockCheckedHdl, weld::Toggleable&, void)</span></span>   8</span> {</span></span>   9</span>-</span>  10</span>     MarkCheckedMembers();</span></span>  11</span>+</span>  12</span> </span></span>  13</span>-</span>  14</span>-</span>  15</span>-</span>  16</span>-</span>  17</span>-</span>  18</span>-</span>  19</span>-</span>  20</span>-</span>  21</span>-</span>  22</span>-</span></span>  23</span>-</span>  24</span>-</span>  25</span>-</span>  26</span>-</span>  27</span>-</span>  28</span>-</span>  29</span>-</span>  30</span>-</span>  31</span>-</span>  32</span>-</span>  33</span>-</span>  34</span>-</span>  35</span>-</span>  36</span>-</span>  37</span>-</span>  38</span>-</span>  39</span>-</span>  40</span>-</span>  41</span>-</span>  42</span>-</span>  43</span>-</span>  44</span>-</span>  45</span>-</span></span>  46</span>-</span>  47</span>-</span>  48</span>-</span>  49</span>-</span>  50</span>-</span>  51</span>-</span>  52</span>-</span>  53</span>-</span></span>  54</span>-</span>  55</span>-</span>  56</span>+</span>  57</span>+</span>  58</span>+</span>  59</span>         for (auto& aMember : maMembers)</span></span>  60</span>             aMember.mbMarked = false;</span></span>  61</span> }</span></span>  62</span>@@</span> -1119,6 +1079,54</span> 63</span>     }</span></span>  64</span> }</span></span>  65</span> </span></span>  66</span>+</span>void  67</span>+</span>  68</span>+</span>  69</span>+</span>  70</span>+</span>  71</span>+</span>  72</span>+</span></span>  73</span>+</span>  74</span>+</span>  75</span>+</span>  76</span>+</span>  77</span>+</span>  78</span>+</span>  79</span>+</span>  80</span>+</span>  81</span>+</span>  82</span>+</span></span>  83</span>+</span>  84</span>+</span>  85</span>+</span>  86</span>+</span>  87</span>+</span>  88</span>+</span>  89</span>+</span>  90</span>+</span>  91</span>+</span>  92</span>+</span>  93</span>+</span>  94</span>+</span>  95</span>+</span>  96</span>+</span>  97</span>+</span>  98</span>+</span>  99</span>+</span> 100</span>+</span> 101</span>+</span> 102</span>+</span> 103</span>+</span></span> 104</span>+</span> 105</span>+</span> 106</span>+</span> 107</span>+</span> 108</span>+</span> 109</span>+</span> 110</span>+</span> 111</span>+</span> 112</span>+</span></span> 113</span>+</span></span> 114</span> IMPL_LINK_NOARG(ScCheckListMenuControl, EdModifyHdl, weld::Entry&, void)</span></span> 115</span> {</span></span> 116</span>     maSearchEditTimer.Start();</span></span></code></pre>harder to review</h2>   1</span>  2</span>index 39afd0963606..a38226336130 100644</span></span>   3</span>---</span>  4</span>+++</span>  5</span>@@</span> -875,49 +875,16</span>  6</span>     }</span></span>   7</span> }</span></span>   8</span> </span></span>   9</span>-</span>void  10</span>-</span>  11</span>-</span>  12</span>-</span>  13</span>-</span>  14</span>-</span>  15</span>-</span>  16</span>-</span>  17</span>-</span>  18</span>-</span>  19</span>-</span>  20</span>-</span>  21</span>-</span>  22</span>-</span>  23</span>-</span>  24</span>-</span>  25</span>-</span>  26</span>-</span>  27</span>-</span>  28</span>-</span>  29</span>-</span>  30</span>-</span>  31</span>-</span>  32</span>-</span>  33</span>-</span>  34</span>-</span>  35</span>-</span>  36</span>-</span>  37</span>-</span>  38</span>-</span></span>  39</span>-</span>  40</span>-</span>  41</span>-</span>  42</span>-</span>  43</span>-</span></span>  44</span>-</span>  45</span>+</span>void  46</span> {</span></span>  47</span>-</span>  48</span>-</span>  49</span>+</span>  50</span>+</span>  51</span>+</span>  52</span>+</span>  53</span> </span></span>  54</span>     if (mbHasDates)</span></span>  55</span>     {</span></span>  56</span>-</span>  57</span>+</span>  58</span>     }</span></span>  59</span>     else</span></span>  60</span>     {</span></span>  61</span>@@</span> -925,8 +892,6</span> 62</span>         mpChecks->clear();</span></span>  63</span>         mpChecks->thaw();</span></span>  64</span> </span></span>  65</span>-</span>  66</span>-</span>  67</span>         if (aSearchText.isEmpty())</span></span>  68</span>         {</span></span>  69</span>             /*</span></span>  70</span>@@</span> -955,9 +920,51</span> 71</span>             }, nullptr, &aFixedWidths);</span></span>  72</span>         }</span></span>  73</span>     }</span></span>  74</span>+</span>  75</span>+</span></span>  76</span>+</span>void  77</span>+</span>  78</span>+</span>  79</span>+</span>  80</span>+</span>  81</span>+</span>  82</span>+</span>  83</span>+</span>  84</span>+</span>  85</span>+</span>  86</span>+</span>  87</span>+</span>  88</span>+</span>  89</span>+</span>  90</span>+</span>  91</span>+</span>  92</span>+</span>  93</span>+</span>  94</span>+</span>  95</span>+</span>  96</span>+</span>  97</span>+</span>  98</span>+</span>  99</span>+</span> 100</span>+</span> 101</span>+</span> 102</span>+</span> 103</span>+</span> 104</span>+</span> 105</span>+</span></span> 106</span>+</span> 107</span>+</span> 108</span>+</span> 109</span>+</span> 110</span>+</span></span> 111</span>+</span> 112</span>+</span> 113</span>+</span> 114</span>+</span> 115</span> </span></span> 116</span>-</span> 117</span>-</span> 118</span>+</span> 119</span>+</span> 120</span>+</span> 121</span>         for (auto& aMember : maMembers)</span></span> 122</span>             aMember.mbMarked = false;</span></span> 123</span> }</span></span></code></pre>

  TUIs are far more flexible than GUIs
 2026-03-04T00:00:00+00:00

#ABB2BF);">diff --git a/sc/source/ui/cctrl/checklistmenu.cxx b/sc/source/ui/cctrl/checklistmenu.cxx</span></span> #282C34);"> a/sc/source/ui/cctrl/checklistmenu.cxx</span></span> #282C34);"> b/sc/source/ui/cctrl/checklistmenu.cxx</span></span> light-dark(#6F42C1, #ABB2BF);font-weight: bold;"> @@</span> void ScCheckListMenuControl::MarkCheckedMembers()</span></span> bool bLockCheckedEntries = mxChkLockChecked->get_active();</span></span> UpdateVisibleMembers(false);</span></span> if (mbHasDates)</span></span> {</span></span> // TODO: flesh this out</span></span> }</span></span> else</span></span> {</span></span> mpChecks->freeze();</span></span> mpChecks->clear();</span></span> mpChecks->thaw();</span></span> OUString aSearchText = mxEdSearch->get_text();</span></span> aSearchText = ScGlobal::getCharClass().lowercase(aSearchText);</span></span> if (aSearchText.isEmpty())</span></span> {</span></span> /*</span></span> * when we click on lock, all the checked entries are marked and</span></span> * this `true` tells `initMembers` to check only the currently</span></span> * checked entries.</span></span> *</span></span> * when lock is unchecked we want that the entries which were locked</span></span> * and checked now become unlocked and checked so that we can select</span></span> * or deselect more entries, still we want only the marked (selected)</span></span> * entries to remain selected, thus this `true` is valid even in the</span></span> * uncheck case.</span></span> */</span></span> initMembers(-1, true);</span></span> }</span></span> else</span></span> {</span></span> std::vector<int> aShownIndexes;</span></span> loadSearchedMembers(aShownIndexes, maMembers, aSearchText, true);</span></span> std::vector<int> aFixedWidths { mnCheckWidthReq };</span></span> // insert the members, remember whether checked or unchecked.</span></span> mpChecks->bulk_insert_for_each(aShownIndexes.size(), [this, &aShownIndexes, &bLockCheckedEntries](weld::TreeIter& rIter, int i) {</span></span> size_t nIndex = aShownIndexes[i];</span></span> insertMember(*mpChecks, rIter, maMembers[nIndex], maMembers[nIndex].mbMarked, bLockCheckedEntries);</span></span> }, nullptr, &aFixedWidths);</span></span> }</span></span> }</span></span> // unmarking should happen after the members are inserted</span></span> if (!bLockCheckedEntries)</span></span> // unmarking should happen after the members are inserted or updated</span></span> // (in case there's a hierarchy, in which case we don't clear everything)</span></span> if (!mxChkLockChecked->get_active())</span></span> light-dark(#6F42C1, #ABB2BF);font-weight: bold;"> @@</span> IMPL_LINK_NOARG(ScCheckListMenuControl, SearchEditTimeoutHdl, Timer*, void)</span></span> ScCheckListMenuControl::UpdateVisibleMembers(bool bSearchEditTimeout)</span></span> {</span></span> // TODO: change it later based on the `SearchEditTimeoutHdl` code</span></span> bool bLockCheckedEntries = !bSearchEditTimeout && mxChkLockChecked->get_active();</span></span> OUString aSearchText = mxEdSearch->get_text();</span></span> aSearchText = ScGlobal::getCharClass().lowercase(aSearchText);</span></span> if (mbHasDates)</span></span> {</span></span> // TODO: flesh it out later</span></span> }</span></span> else</span></span> {</span></span> mpChecks->freeze();</span></span> mpChecks->clear();</span></span> mpChecks->thaw();</span></span> if (aSearchText.isEmpty())</span></span> {</span></span> /*</span></span> * when we click on lock, all the checked entries are marked and</span></span> * this `true` tells `initMembers` to check only the currently</span></span> * checked entries.</span></span> *</span></span> * when lock is unchecked we want that the entries which were locked</span></span> * and checked now become unlocked and checked so that we can select</span></span> * or deselect more entries, still we want only the marked (selected)</span></span> * entries to remain selected, thus this `true` is valid even in the</span></span> * uncheck case.</span></span> */</span></span> initMembers(-1, true);</span></span> }</span></span> else</span></span> {</span></span> std::vector<int> aShownIndexes;</span></span> loadSearchedMembers(aShownIndexes, maMembers, aSearchText, true);</span></span> std::vector<int> aFixedWidths { mnCheckWidthReq };</span></span> // insert the members, remember whether checked or unchecked.</span></span> mpChecks->bulk_insert_for_each(aShownIndexes.size(), [this, &aShownIndexes, &bLockCheckedEntries](weld::TreeIter& rIter, int i) {</span></span> size_t nIndex = aShownIndexes[i];</span></span> insertMember(*mpChecks, rIter, maMembers[nIndex], maMembers[nIndex].mbMarked, bLockCheckedEntries);</span></span> }, nullptr, &aFixedWidths);</span></span> }</span></span> }</span></span> }</span></span> #ABB2BF);">diff --git a/sc/source/ui/cctrl/checklistmenu.cxx b/sc/source/ui/cctrl/checklistmenu.cxx</span></span> #282C34);"> a/sc/source/ui/cctrl/checklistmenu.cxx</span></span> #282C34);"> b/sc/source/ui/cctrl/checklistmenu.cxx</span></span> light-dark(#6F42C1, #ABB2BF);font-weight: bold;"> @@</span> namespace</span></span> ScCheckListMenuControl::MarkCheckedMembers()</span></span> {</span></span> if (mbHasDates)</span></span> {</span></span> // TODO: flesh it out later</span></span> }</span></span> else</span></span> {</span></span> // go over the members visible in the popup, and remember which one is</span></span> // checked, and which one is not by setting `mbMarked` to `true`; by default</span></span> // `mbMarked` is `false`, we clear all the marks when lock is unchecked, see</span></span> // at the end of this callback.</span></span> mpChecks->all_foreach([this](weld::TreeIter& rEntry){</span></span> if (mpChecks->get_toggle(rEntry) == TRISTATE_TRUE)</span></span> {</span></span> for (auto& aMember : maMembers)</span></span> {</span></span> if (aMember.maName == mpChecks->get_text(rEntry))</span></span> {</span></span> aMember.mbMarked = true;</span></span> /*</span></span> * if there are multiple entries with the same</span></span> * name in the range, they all show up as a single</span></span> * entry in the autofilter, so we can break</span></span> */</span></span> break;</span></span> }</span></span> }</span></span> }</span></span> return false;</span></span> });</span></span> }</span></span> }</span></span> IMPL_LINK_NOARG(ScCheckListMenuControl, LockCheckedHdl, weld::Toggleable&, void)</span></span> ScCheckListMenuControl::UpdateVisibleMembers(bool bSearchEditTimeout)</span></span> bool bLockCheckedEntries = mxChkLockChecked->get_active();</span></span> MarkCheckedMembers();</span></span> // TODO: change it later based on the `SearchEditTimeoutHdl` code</span></span> bool bLockCheckedEntries = !bSearchEditTimeout && mxChkLockChecked->get_active();</span></span> OUString aSearchText = mxEdSearch->get_text();</span></span> aSearchText = ScGlobal::getCharClass().lowercase(aSearchText);</span></span> // TODO: flesh this out</span></span> // TODO: flesh it out later</span></span> #ABB2BF);font-weight: bold;"> @@</span> IMPL_LINK_NOARG(ScCheckListMenuControl, LockCheckedHdl, weld::Toggleable&, void)</span></span> OUString aSearchText = mxEdSearch->get_text();</span></span> aSearchText = ScGlobal::getCharClass().lowercase(aSearchText);</span></span> #ABB2BF);font-weight: bold;"> @@</span> IMPL_LINK_NOARG(ScCheckListMenuControl, LockCheckedHdl, weld::Toggleable&, void)</span></span> }</span></span> ScCheckListMenuControl::MarkCheckedMembers()</span></span> {</span></span> if (mbHasDates)</span></span> {</span></span> // TODO: flesh it out later</span></span> }</span></span> else</span></span> {</span></span> // go over the members visible in the popup, and remember which one is</span></span> // checked, and which one is not by setting `mbMarked` to `true`; by default</span></span> // `mbMarked` is `false`, we clear all the marks when lock is unchecked, see</span></span> // at the end of this callback.</span></span> mpChecks->all_foreach([this](weld::TreeIter& rEntry){</span></span> if (mpChecks->get_toggle(rEntry) == TRISTATE_TRUE)</span></span> {</span></span> for (auto& aMember : maMembers)</span></span> {</span></span> if (aMember.maName == mpChecks->get_text(rEntry))</span></span> {</span></span> aMember.mbMarked = true;</span></span> /*</span></span> * if there are multiple entries with the same</span></span> * name in the range, they all show up as a single</span></span> * entry in the autofilter, so we can break</span></span> */</span></span> break;</span></span> }</span></span> }</span></span> }</span></span> return false;</span></span> });</span></span> }</span></span> }</span></span> IMPL_LINK_NOARG(ScCheckListMenuControl, LockCheckedHdl, weld::Toggleable&, void)</span></span> {</span></span> MarkCheckedMembers();</span></span> UpdateVisibleMembers(false);</span></span> // unmarking should happen after the members are inserted</span></span> if (!bLockCheckedEntries)</span></span> // unmarking should happen after the members are inserted or updated</span></span> // (in case there's a hierarchy, in which case we don't clear everything)</span></span> if (!mxChkLockChecked->get_active())</span></span>
terminal user interfaces (tuis) are much more powerful and versatile
compared to graphical user interfaces. you can run tuis without any
graphical environment, you can ssh into a system and attach the tuis
running in that system (easily with tmux).</p>
this shines when you are in a situation where the input devices are
blocked by some gui like a menu, and there's no way you can pass
commands to the debugger. if it comes to that, you can ssh from
another machine and attach the tui and continue from there.</p>


build systems to help you build habbits
2026-01-02T00:00:00+00:00
building habbits is not an easy task, they require change and change
creates friction. but not all changes have to create friction and
systems are ways to slip in changes into your routine in a way that
the resulting friction doesn't cause bruses.</p>
for example, i have some gym equipment at home and i tried doing some
exercises myself but i couldn't do it regularly because it was just
too boring doing it alone. so i joined a badminton academy. i just
have to go there and rest happens on it's own, some days it's matches,
which is fun, and some days it's a lot of running and training, which
is less fun, but with people around, it's doable with some chats and
smiles and screems :).</p>
i have a few rivals now, so i am careful about what i eat at home as i
want to build a good physique to match thier level, i jump ropes when
i am waiting for my turn on the court. one good system can create a
lot of positive feedback loops. i haven't stated the other benifits of
sports.</p>
another system i built recently was that of timelogging. previously i
used gtimelog to track the time spent on work tasks, but now i log my
activities as well to see where the day went exactly. i am not micro
managing anything but i am now conscious about where i spend the next
30m or 1h. time is the only constant you can't change :).</p>
</p>
Systems like these, paired with the ability to make steady progress</a>,
allow you to get the maximum value from your time.</p>


making progress on tasks
2026-01-02T00:00:00+00:00
it's quite easy to drift off in certain unwanted direction like
reading a comment in the codebase about a tool and then reading the
whole manpage of that tool, or joining the irc channel for that tool
to discuss certian term you couldn't understand from the man page. but
it wasn't about the tool in the first place.</p>
this is called 'getting distracted or sidetracked', and it's a big
hurdle preventing you from finishing the tasks. one has to narrow down
their focus to things which help make progress on the task. having an
agenda before starting the work helps, and there after you can just
check whether what you are doing aligns with the agenda or not.</p>
the agenda should be specific, it's your plate for the day. put no
more than what you can eat and digest. be consistent, and that's how
you eat an elephant, one bite at a time.</p>


the book printing episode (part 2)
2025-12-24T00:00:00+00:00
the last attempt</h2>
last time</a> when i printed some books, i basically
created images out of the pdf to then crop and put back into a pdf.
this approach worked however it added blur to the final generated pdf.
and there was a font problem where if the book/spec had a very thin
monospace font, i didn't know how to change it. i found a solution to
both of these problems.</p>
changing monospace font in the pdf</h2>
i searched quite a bit, on the archwiki and on forums in general and
i couldn't find some magical command to change a specific font in the
pdf. instead i found that i can edit the pdf with libreoffice-draw and
replace certain fonts with other fonts. this worked quite well.</p>
Steps:</p>

open the pdf in libreoffice draw</li>
right-click -> page properties -> set the margins to 0</li>
switch to the tabbed ui or open the sidebar</li>
click on the text-frame with the font to substitute</li>
copy the font name from the fonts dropdown list (on sidebar or on nbbar)</li>
click on menu Tools > Options > LibreOffice > Fonts</code></li>
add the font and it's replacement, select Always</code> checkbox, click apply & ok</li>
</ol>
</p>
you might want to adjust the replacement font sizes a bit or it might
be a bit off from the center of the line. as you can see below, the
exported pdf is much more readable & printable.</p>
</p>
reducing the page margins</h2>
pdfcrop</code> is an amazing tool which can remove the page margins, or set
them to a desired value. i set 25mm</code> on all sides with the following
command and you can see how much area we saved (effectively zoomed
in).</p>
1</span>pdfcrop</span> -</span>-margins</span> '</span>25 25 25 25</span>'</span> in.pdf</span> out.pdf</span></span></code></pre>
</p>
this might not seem like a big difference as these files are still
pdfs, but when they get printed to the paper, the one on the right
will be way more larger than the one on the left as the text is going
to get more area on the page.</p>
i am quite happy with how it turned out, though i have already printed
most of the books/specs i needed :_).</p>


knowledge building
2025-12-16T00:00:00+00:00
i recently learnt a very important lesson, the most important skill
one needs as a programmer is to "figure out the unknown". for most
great things, there aren't any predefined steps, people try different
things, fail at many. these failures/experiments help in knowledge
building and after a point they have sufficient knowledge to make it
work.</p>
i learnt that there are no shortcuts that one must take the same long
path that many took before them. it might be that the others who went
that way left some nice sign boards & journals about their journey,
but it might as well be the case that you are the first one exploring
that road.</p>
i was scared of failing, i would double check things on the internet
before writing them in the code, i learnt to be comfortable around
errors. it's fine if you can't get it to work in the first go, just
run it and figure out what's not working.</p>


hackers don't need permission to look at the source
2025-11-26T00:00:00+00:00
this blog is about approach, you are using emacs and you are annoyed
by a prompt asking you whether to create a missing directory or not.
one thing you can do is to go to the IRC channel and ask them how to
not see that prompt. other thing (the right thing) you can do is to
open the elisp code and try to find out what's printing that prompt.
once you found the source, try to implement the fix yourself and if
you are stuck somewhere, ask for some help.</p>
the application crashes, you got a stacktrace, don't post it on the
IRC channel rightaway and ask for help/(who knows what it is about),
put a breakpoint there and try to fix it yourself. if you aren't able
to fix it, ask for help. this differentiates a good programmer from
the rest.</p>


read the friendly manual
2025-11-26T00:00:00+00:00
the friendly manual has all the answers. it can be quite long
sometimes and it may require some tries before you find what you were
looking for. patience and reading skills are the key here. i often
make a mistake where i quickly scroll my eyes over the manual trying
to spot the answer, and most of the times, i miss the spot and thus
end up spending more time to find my solution.</p>
a good manual has topic wise examples, make sure you include them if
you happen to write one. but most manuals don't have examples, so
don't expect to find the solution straight away, it might require some
experimentation. you can ask on IRC channels and get pointers to the
topics which you should read from the manual to find what you are
looking for.</p>
don't use AI, it enforces bad habbits and expectations and you don't
build muscle over time as LLMs are black boxes. reading man pages
on the other hand is like using vim, it would be slow at first but
you build intuition and muscle memory over time and it keeps getting
better from there.</p>


reading comments, manuals, instructions
2025-11-26T00:00:00+00:00
reading is the single most important skill one requires as a
programmer. we don't just read the code, but the comments, the
reviews, the instructions and user feedback. reading is therefore a
skill we cannot ignore or assume as something which comes naturally.</p>
one must pay attention to each word with their whole attention reading
at a slow steady pace. i miss out on important details when i try to
read fast or skim over the text. :) that one time i asked for help
and i learnt that it was already mentioned by szymon in one of his
comments.</p>
reading requires patience, therefore it's not like one can be good at
reading and live a chaotic life, the whole lifestyle, things you do
in a day have to complement the conditions required for one to be and
remain a good reader.</p>


report complete and accurate observations
2025-11-26T00:00:00+00:00
we can also reword this topic as "asking for help the right way". we
are trying something, it's not working and we need help. we go to an
irc or matrix chat and share what we were trying to do. now at this
point we should make sure that we provide the complete context and
complete description of the problem and the findings from various
attempts at it.</p>
we should also avoid half baked sentenses because they can mislead
the readers about the problem wasting their time. sharing some
screenshots, pastebins and steps to reproduce are much appreciated.</p>


bias and assumptions
2025-11-19T00:00:00+00:00
confirm the code does what you think it does. i just copied some code
and refactored it into a function assuming that it takes me to a
particular cell. but actually it was code to assert that this cell is
a particular cell. that's why it's important to read code carefully.</p>
another such assumption can be thinking that you read all the code
in ana file d you know what it does. it happened to me once, i had
read some code a few weeks ago so i didn't bother reading it again
and assumed that i have an idea of what it does. turns out i didn't
quite understand the code i read the last time and i there were some
callbacks i wasn't aware of, which were needed to fix the problem i
was working on.</p>
there's no harm in quickly going over what you know once again, maybe
write it in a structured order, start with some questions and read
the code while finding answers to them. ask yourself, do i really understand the code i am working with</code> as that's the most important
question.</p>


the initial few hours into a project are a bit scary
2025-11-19T00:00:00+00:00
maybe i am the coward one, whenever i start a new project, i am scared
out of my wits, i quite literally feel a vacuum around me. at that
point the instincts take over and either i fight or flight :). i
recently learnt that it's all about understanding.</p>
as you start a new project, you know almost nothing about it. as you
read more and more code, when you ask questions and find answers to
them, when you take some help (after a few decent tries), you slowly
start understanding and pick up the speed, the fear goes away.</p>
the initial few hours were scary for me because i was rushing towards
the solution, through shortcuts in a town i knew nothing about, no
surprise they led me to some pretty scary places. approach a project
from the perspective of understanding the problem, the code around it.</p>


how to solve any programming problem
2025-11-19T00:00:00+00:00
understanding is the key. if you understand the problem space and
the problem surface, then it becomes as simple as wanting something
and knowing exactly what will do what and what one has to do to
get something to work. this works on all kinds of problems on all
scales, though larger problems require more time (patience) and well
documented logs to stay focused.</p>
asking good/decisive questions helps understand the problem
space/surface faster. questions like:</p>

what exactly happens when i do this</li>
how does that happen</li>
what does this code do</li>
how does the stack look like at that point</li>
how does the value of this variable change over some interaction</li>
</ul>
these questions give a direction to the investigation, threads which
you can hold on to, one at a time. and as you go over a few of them,
they start coming together and you reach a point where you have
covered quite a lot of the problem surface.</p>
with hard/complicated problems, shortcuts are almost always bad. while
estemating, almost always estemate time needed to cover the surface
area of the problem and a few days for the fixing the problem which
includes cleanup, tests and reviews -- you would have a working
prototype as you cover the surface.</p>


think at the global scope as you modify some local scope
2025-11-12T00:00:00+00:00
reading other's code and modifying it can be tricky, there might be
some code somewhere which uses the code you just modified and you have
no idea about it. therefore as you read/modify some code, ask yourself</p>

is this required?</li>
how does this relate to the other code, some of which i just read and some which i have no idea about.</li>
</ol>
don't keep the mental model limited to the local scope (file or
module), zoom out a bit and try to understand the code you are
reading/modifying in the bigger picture (series of events).</p>
just asking "what does it do and how" isn't enough. you also need to
ask what other code uses this code, how does changing this code change
the behavior of that code, and other similar questions.</p>
like while doing some code cleanup, ask yourself whether the code you
are removing/moving is used by some code somewhere which you aren't
aware of? i made some changes to the checkbox widget code and that
introduced some bugs in the dialog checkboxes, had i not checked
that, the bug would have made it to the release (but some tests are
failing, so thanks to the dev who wrote those tests).</p>



how to fix your code after code reviews
2025-11-12T00:00:00+00:00
usually the changes are in a series of commits one after the other.
start from first read all the comments and try to understand if they
suggest some small changes or something which spans multiple commits
and is related.</p>
let's say there's no such big change suggested, which is ususally the
case, then you start from the very first commit in the series and
implement the suggested changes. don't mark the comment as resolved
yet as these suggestions don't just apply to one commit, make sure you
look through other commits to see if this suggestion applies there
and if it does, make the fixes in those commits and then resolve this
comment. do it for reach comment.</p>
when you are fixing something, make sure that you test the fix on
top of the commit series and once it works there, you can just stash
the changes and apply and ammend them to a particular commit in
interactive rebase. the idea is to not checkout to a particular commit
and then implement the fix as that fix might not play well with the
following commits and then it would be just more work to test it
twice (and potentially fix it twice).</p>


experiments lead to deep insights
2025-11-11T00:00:00+00:00
programming is a creative domain and there are many ways to approach
a problem. experimentation is therefore important to understand
different aspects of a concept, problem or even the solution.
tutorials and books are usually linear, good ones suggest you some
experiments to do on your own.</p>
a good programmer should have the patience to stay with one concept,
problem or solution for a little longer and play with it, tweek the
parameters and see what happens. the insights you gain from that are
quite valuable.</p>


don't rush to get the changes in
2025-11-11T00:00:00+00:00
when something is almost done, it's tempting to quickly get it
reviewed and merged. while you shouldn't stall things unnecessarily,
it's equaly important that you don't create a rush to get the changes
in.</p>
if you are not sure about something, take some more time, understand
what works and why, potential bugs, add tests and then start the
review process. if the action statement involves the terms like last minute</code> or just before</code> or quickly</code>, then be extra careful and get
some more time if possible.</p>


remote work and staying online
2025-11-06T00:00:00+00:00
for a long time i have struggled with chat applications. as a remote
developer, chat is the only means of communication other than some
scheduled calls. and so i had to keep these chat applications running
in the background. if i turned on notifications on these applications
then they would just show every message sent, so that wasn't an option.</p>
often i closed these applications when i wanted some focus time but
then there was a part of my brain wondering about "what if someone
pings me about something".</p>
finally i found a nice solution to the problem. i just pin tabs on
the browser and that puts them out of the way. and if someone pings
me, the pinned tabs show a dot telling me it's time to check the chat.</p>
</p>


tracking progress on assigned projects
2025-11-01T00:00:00+00:00
often we are working on multple tasks at a time and we switch between
them, ask for a code review on one task and continue working on the
other. in all this to-and-fro, it's easy to forget about some task
assigned to you, or some PR which still hasn't been reviewed.</p>
one can go over all the mails and lists to stay aware of what's going
on and what's important, but i say there's a better way, one which
scales quite well even for large number of tasks. the idea is to have
one log file and in that have a section for each task with a rough
checklist of things which has been done and things which are in the
pipeline. very high priority tasks are at the top of the log file
while the less important ones are on the bottom side.</p>
you can either use markdown or some other file format for it, i use
vim's help format. whenever i commit something, or get a mail, or
chat with mentors about the task (and get some pointers), i either
cross-out some item from the list, or i add a new item to the list.
the idea is to keep this file updated with various developments.</p>
so let's say i am done with the first task and i asked gokay to review
it. i will add that entry to the list and then move this whole task to
the second position as then the priorities suggest that i work on the
second task till i get a review on this one.</p>
 1</span>---------------------------------------------------------------------------------------------------------------</span></span>
 2</span>[Cannot hide comments from the notebookbar > review tab buttons](https://example.com)</span></span>
 3</span>  - [x] some cleanup suggestions</span></span>
 4</span>  - [x] the comment line is still visible for the selected comment even after toggling it off</span></span>
 5</span>  - [x] recenter the document when the comments are manually removed and none are left</span></span>
 6</span>    - [x] don't show the comments or their lines when comments are hidden</span></span>
 7</span>    - [x] don't move the document when there are no comments on it (stashed)</span></span>
 8</span>    - [x] when all the comments are hidden and a new comment is inserted then just show all of them and adjust document margins to pull them in view</span></span>
 9</span>    - [x] when a new comment is inserted, comments are set to "visible" that triggers the callback which doesn't account for offset which the document is already at, and thus keeps moving the document as we insert comments, fix this</span></span>
10</span>    - [x] when all the comments are removed, why does the document keep moving left, where's the bug?</span></span>
11</span>    - [x] why doesn't the commentList.size value reflect the change in the callback when the comment is removed?</span></span>
12</span>    - [x] when document is zoomed in and a new comment is inserted, then this code should fire and adjust document to show comment or bubble the comment, currently it's just half visible.</span></span>
13</span>    - [x] test against pranam's pr -> all ok</span></span>
14</span>    - [x] fix the failing unit test -> it passed locally</span></span>
15</span>    - [x] check why comments are hidden when reducing the window width and fix it -> turns out the offset is increasing and decreasing as i resize why?. -> serious logical error</span></span>
16</span>    - [-] the comments hide when the document is resized horizontally and the tolerances are quite small -> turns out getSize returns int size for the map</span></span>
17</span>    - [ ] write massive amounts of tests to freeze the feature in time</span></span>
18</span>    + [ ] application crashes on context menu -> page style .uno:PageDialog</span></span>
19</span></span>
20</span>---------------------------------------------------------------------------------------------------------------</span></span>
21</span>[Notebookbarbuilder: Add checkbox + label widget](https://example.com)</span></span>
22</span>  - [x] read some typescript documentation</span></span>
23</span>  - [x] commit 1: JSDialogBuilder.js#L1099 -> separate file  control/jsdialog/Widget.Checkbox.js</span></span>
24</span>    - [x] commit 2: did some code cleanup in the original js file</span></span>
25</span>    - [x] commit 2 - ammend: replace var with const</span></span>
26</span>  - [x] commit 3: convert control/jsdialog/Widget.Checkbox.js -> control/jsdialog/Widget.Checkbox.ts</span></span>
27</span>  - [x] commit 4: add type for JSON in https://github.com/CollaboraOnline/online/blob/master/browser/src/control/jsdialog/Definitions.Types.ts and use in widget</span></span>
28</span>  - [x] szymon just merged this patch -> me should set it to draft from next time</span></span>
29</span>  - [ ] add new property for firing uno command on toggle on top :) (i think this means do the same like what happens when a toggle button is clicked which then fires a command)</span></span>
30</span>  - [ ] add a checkbox for ruler and bind it/make it work nicely</span></span>
31</span>  - [ ] add a checkbox for grid lines and bind it</span></span>
32</span>  - [ ] add a checkbox for another control (check if there are more which need this) ???</span></span>
33</span>  - [ ] look out for corner/edge cases like various places where we return if it's a radiobutton or checkbox</span></span>
34</span></span>
35</span>---------------------------------------------------------------------------------------------------------------</span></span>
36</span>[Style preview: Add button that expands container (GH#12171)](https://example.com)</span></span>
37</span>  - [ ] read and figure out the suggestions</span></span>
38</span>  - [ ] szymon said that there are some pointers</span></span>
39</span></span>
40</span>---------------------------------------------------------------------------------------------------------------</span></span>
41</span>[Design Bits : Cursor does not change when hovering or resizing the handles of an object](https://example.com)</span></span>
42</span>  - [ ] fix the regression nicely</span></span>
43</span>  - [ ] write a test for the regression fix</span></span>
44</span></span>
45</span>---------------------------------------------------------------------------------------------------------------</span></span>
46</span>[GH#12177 Refactor and Split COOLWSD.cpp into Logical Modules](https://github.com/CollaboraOnline/online/issues/12177)</span></span>
47</span>  - [x] pushed the first dumpWsd refactor, thanks ash and mst</span></span>
48</span>  - [ ] now separate out PrisonerRequestDispatcher</span></span>
49</span>...</span></span></code></pre>
all that said, one more thing remains, which is the most important in
this workflow, quick access. you should be able to open the log file
as quickly as possible, probably with just one keyborad shortcut. i
use neovim and tmux, and i have a script which opens a tmux popup
in the current tmux session with the file. this makes it quite easy to
go back-and-forth.</p>
 1</span>#!</span>/bin/bash</span></span>
 2</span></span>
 3</span>#</span> GNU GPLv2, June 1991</span></span>
 4</span>#</span> Copyright (c) 2025 Sahil Gautam <printfdebugging@gmail.com></span></span>
 5</span>#</span> See LICENSE for full license declaration</span></span>
 6</span></span>
 7</span>dependencies</span>=</span>(</span></span>
 8</span>    t</span>m</span>u</span>x</span></span>
 9</span>    n</span>v</span>i</span>m</span></span>
10</span>)</span></span>
11</span></span>
12</span>for</span> dependency</span> in</span> "</span>$</span>{</span>dependencies</span>[</span>@</span>]</span>}</span>"</span>;</span> do</span></span>
13</span>    if</span> !</span> which</span> "</span>$</span>dependency</span>"</span> ></span>/dev/null</span> 2</span>>&1</span>;</span> then</span></span>
14</span>        echo</span> "</span>$</span>{</span>dependency</span>}</span> not found</span>"</span> &&</span> exit</span> 1</span></span>
15</span>    fi</span></span>
16</span>done</span></span>
17</span></span>
18</span>tasks_dir</span>=</span>$</span>{</span>LOGS_DIR-</span>"</span>$</span>HOME</span>"</span>}</span></span>
19</span>tasks_file</span>=</span>"</span>$</span>{</span>tasks_dir</span>}</span>/tasks.txt</span>"</span></span>
20</span></span>
21</span>tmux</span> popup</span> -</span>w</span> 100%</span> -</span>h</span> 90%</span> -</span>EE</span> "</span>cd </span>$</span>{</span>tasks_dir</span>}</span> && nvim </span>$</span>{</span>tasks_file</span>}</span>"</span></span></code></pre>
let's say i am writing this blog and i want to open the tasks file, i
would just press a key-combination and this would happen. in the
second screenshot, a popup covers the terminal window and we have the
tasks file opened in it. now we can quickly edit, or quickly take a look
at what we are working on and what's next.</p>
</p>
</p>


printf-debugging
2025-11-01T00:00:00+00:00
printf-debugging is pretty useful in situations where you want to
understand the behavior of a function or a group of functions over a
certain action. in such cases, you can't really use a debugger and
set breakpoints specially if the interaction involves cursor as the
debugger will keep breaking at the set breakpoints and you would have
to either change window focus or move your cursor to the debugger
controls.</p>
for javascript, looking at the the logs in the console below while
interacting with the user interface elements is a nice way to see
the state of various variables in real time. though one needs to
carefully decide what they want to log and what not because these logs
pile up really fast. ideally i prefer 5-6 lines of logs per
interaction "while trying to understand/debug".</p>


writing code with a nicely* organized* context
2025-10-31T00:00:00+00:00
code has a context it's written in like the various files/modules
it interacts with, the various cases it is triggered in and how it
handles them. code (data and data-processors == functions) moves from
an organized state towards chaos if you just keep adding code without
giving a critical thought to the context.</p>
code readability doesn't mean just nice/understandable variable names.
the variable names should also represent the context in which they
are being written. the context tends to spread with time and just being
aware of this fact can help you avoid that. designing perfect code in
advance is almost impossible. in any real world setting, there are
invariants which you will know about only when you write code.</p>
code too is written in iterations over the initial prototype and it
changes form with each commit. so the focus should be that with each
commit, the code should become more readable, readable such that when
someone new looks at that code, they get the whole picture, they
shouldn't later find out that this code handles some edge cases which
are not obvious from the code, which are not described using comments
or the commit message.</p>
treating data and logic separately helps with this as then you think
of the data, the logic and the context that they interact in. then
you can keep an eye at each of these and improve things with each
iteration.</p>



haste is bad, think twice before pressing any button
2025-10-28T00:00:00+00:00
haste is bad for programmers, you hastily click a button and later
find that it was a mistake, you click on some other button to fix that
and you just pinged/notified/disturbed others (twice) cc'd on that
page.</p>
you might delete some important data or you might configure some wrong
setting on the server which might potentially affect thousands of
users. you merge an untested patch at the last minute which might
break the release.</p>
so think twice before performing any action. speak out what you are
about to do and ask your rubber duck "is it the right thing to do".</p>


the process matters if it gets results (mostly)
2025-10-28T00:00:00+00:00
processes are important, no doubts about that. processes by themselves
mean nothing, they can't exist in vacuum. and if a process exists for
something, some goal, some result, what's the point if it doesn't help
you progress towards that goal/result.</p>
so results matter at the end, and based on results and goals you
create processes which help you achieve them. in other words: get
stuff done.</p>
processes are medium difficulty to design and hard to implement. so,
you only do it for things that repeat often or are system critical.
everything else better to keep organic.</p>


what editor you use matters!
2025-10-28T00:00:00+00:00
editor is a window through which the programmer looks into the world
of computers. if that window is small and translucent or very big and
transparent affects how you see the world beyond it. does the window
ask you to sit at a certain position at a certain distance to get the
best view, or does it get out of your way as soon as you start looking
through it?</p>
neovim is a great editor, it gets out of my way as soon as i start
using it, the muscle memory kicks in and i navigate through the code
effortlessly. neovim's loclist</code>s lets me get a list of references for
a variable and i can travel through that list with M-n</code> and M-p</code>.
then if i want to preserve this list and do the same for some other
variable i found while investigating, i can do that because loclists
are window local to a tab/window.</p>
</p>
another interesting feature is outline. instead of scrolling through
the file and reading it to find something, i can just search in the
outline and get an idea of what's available in the file/module. this
makes life so much easier.</p>
</p>


when to ask others to review your patches
2025-10-28T00:00:00+00:00
reviewers are developers often busier than you :) so if you cc them
as soon as you push the patch, "they can't do anything" since the ci
hasn't finished. what if the ci fails? they will get a notification
too and they can't do anything, and you just wasted their time.</p>
so, ask others for a review (cc them or message them) only once the ci
passes and you want a final thumbs up from them. asking for help is
different from asking to review, if you are stuck and have exhaused
quite a few approaches, you should ask for help. see reading others'
code</a></p>


don't stress about it too much
2025-10-27T00:00:00+00:00
all this time i was quite unfair to myself, i treated myself like shit
and i expected things based on distorted understanding of the past and
my abilities. back then i just attempted something and i was able to
do it. the attempt was without any expectations, it was just a try, it
worked out, fine, if it didn't work out, it would have been fine then
too.</p>
the whole thing is "if you want to do something", reasons don't
matter, then just do it. if you are able to do it, fine. and if you
are not able to do it, then too it's just fine, who cares. don't
burden yourself with comparison with yourself or the other, it doesn't
matter at the end. just find something which you like and give it a
try, a playful attempt.</p>
that doesn't mean it will be easy, but who said you can't take breaks
and slow down a bit when things get difficult. just pay a little
more attention and it's a matter of time before you understand that
difficult thing too.</p>
having an image of yourself is the most unfair thing you can do to
yourself. you won't understand the code at first glance, you have to
experiment and read it bit by bit and make sense out of it. you will
be more focused at sometimes and less otherwise, who cares. don't beat
yourself over every little thing.</p>
software as a profession needs decades of time investment before you
truely start understanding anything. and it asks that investment on a
daily basis, you have to be consistent. don't micromanage every aspect
of the experience, just take small steps one at a time in the right
direction and things will be just fine.</p>


reading other's code
2025-10-23T00:00:00+00:00
often a task involves jumping into a new area in the codebase and
figuring out how the code there works, what causes the buggy behaviour
and how to fix it. here are the levels at which this is done:</p>

get pointers from someone who knows that area well</li>
read the code and build a mental model</li>
git log and see the commit-messages and diffs which added/modified the code</li>
ask for help :)</li>
</ul>


only commit messages (and tests) survive the test of time
2025-10-23T00:00:00+00:00
commit messages and tests survive the test of time therefore should
have enough information for others to make sense. just having a good
commit title isn't enough, include reference to the commit hashes
which this commit builds on, not the immediate parents but the distant
ones if any.</p>
the rule of thumb is to imagine some new dev (or yourself) reading
your code in future and by then you forgot everything about the code.
the commit message and the tests should have enough information for
the reader to quickly (in reasonable time) understand what's going on.</p>


push -> review -> rework -> review cycle, the programming pipeline
2025-10-23T00:00:00+00:00
for a long time i believed my work is done as soon as i have a working
patch and i push it, it's on the reviewers then to check it and either
push it or ask for changes. pushing the changes is only half the work.</p>
the rest of it involves checking which patches are pending, pinging
the reviewers after a reasonable amount of time, making sure the
patches are rebased and fixing issues pointed out in the reviews.
if one isn't paying attention, these can quickly pile up and then
it would be hard for both the reviewer and the uploader to navigate
through that pile.</p>


profiling code in browser
2025-10-23T00:00:00+00:00
browsers have a performance tab in the developer tools console.
it usually has a button which when clicked starts recording the
performance statistics, then you perform the activity and hit stop
recording.</p>
after that it presents you a nice ui with call-trees, flame-graphcs
and screenshots. you can then find out the action which you want to
profile and look through it. you do it twice, once with your changes
and once without your chanes and see if your changes made it worst
somehow.</p>


writing tests for your code
2025-10-23T00:00:00+00:00
tests are very important, often 1 test is equivalent to 20 future bug
fixes. documentation gets outdated, comments get outdated, but tests
never get outdated. they document the behaviour and enforce it on each
change.</p>
countless times it has happened that i pushed some code and someone
broke it. qa tagged me on that because they found my commit introduced
the now-buggy-feature. having tests ensures this never happens, when
you push a test, you are saying "don't break my code!".</p>


log files are better than stdout
2025-10-22T00:00:00+00:00
often error messages or verbose command outputs are big text walls
with densely packed information which is hard to navigate on the
stdout. redirecting it to a file and then reading that file helps as
then you can format the output, separate out important parts from
unimportant ones, save it for later review etc.</p>
editors can be customized to highlight the keywords like ERROR</code>,
FAILURE</code>, the whole line with such words can be highlighted. you can
also grep out these words from the file. redirecting to a log file
makes life easy.</p>


focus, attention, reading and deep work
2025-10-12T00:00:00+00:00
reading, focus, attention are quite important skills for a software
engineer to be good at. how good you are at these skills depends on
the environment more than you, choices are yours to make though.</p>
i am back to using a single monitor instead of two because i find it
easy to focus when i have a single monitor. reading a book before
sleeping is another thing i am doing now.</p>


searching for help on a disfunctional internet
2025-10-11T00:00:00+00:00
:) internet is quite functional if you know what you want, it's not
a safe place for the clueless wonderers, it has never been. after
gathering some basic vocubulary from the internet you should ask about
it on appropriate irc and matrix channels. after that you would have
a pretty good idea about the topic. i got a gamedev/opengl mentor on irc.</p>
books by far are the best place to gain deep knowledge about any topic
if you are just starting out. it can either be a traditional book or a
website like learncpp.com</a> and learnopengl.com</a>. if you want to know
about the practical usage of that knowledge, you should dive into open
source projects.</p>


starting the day with a list of tasks
2025-10-11T00:00:00+00:00
same as you don't take on the ocean without a map of the seas, you
don't start your day as a programmer without a clear plan. the plan is
basically a text file with the list of tasks you would be working on
during the day and the timeboxes for those tasks.</p>
so while working on those tasks, you would have a clear idea of the
progress you made that day and you would be able to adjust your pace
accordingly. while investigating or programming, one roams around the
codebase a lot and often gets lost. having such a list quickly reminds
you of the priorities. read a timer is better than a clock for timeboxing</a>
to learn about timeboxing.</p>


a timer is better than a clock for timeboxing
2025-10-11T00:00:00+00:00
timeboxing means allocating certain amount of time to work on some
specific task. while working it's easy to get sidetracked from the
original task, so it's important to keep asking yourself, "what am
i working on now", "what am i trying to achieve by working on it"
"what's my approach" and "by working on it, am i making progress on
the task".</p>
don't use a wall-clock for time tracking, it's a distraction, instead
use a timer application like alarm-clock-applet</a> which tells you "how
much time is left" in this timebox. when i use a timer, i feel as
though time doesn't exist and it's just me in a box. clock on the other
hand introduces an overhead about what time it is now and all the
implications that awareness brings about.</p>


comments are better than separate file worklogs
2025-10-11T00:00:00+00:00
a worklog is a journal, but for projects. you write things you found
during investigation like weird error messages, approaches which don't
work and build a mental model of the problem on paper (a text file).
but there's a problem with this separate file approach, it makes you
switch context quite too often and that adds overhead as you come back
and pickup from where you left.</p>
comments solve this issue. with multiline comments, you can add as
much information as you want next to the code without any context
switch. you can number those comments to leave a trail which you can
backtrack on. it also comes in handy when you want others to look at
your code and suggest changes as you don't have to share a separate
log file to communicate your observations and reasoning as you log
that right next to the code you change. later you can just remove the
unneccessary comments and keep the important ones.</p>


approaching big projects
2025-10-02T00:00:00+00:00
the first stage is rapid prototyping where you build a rough
working prototype of the final project with the core functionality.
code organization should be avoided at this stage and focus should be
on exploration and implementation. this way one can avoid surprises and
find pitfalls earlier and fix them. the prototype doesn't have to have
all the bells and whistles, the idea is to understand most of the landscape
in the least amount of time to avoid surprises later.</p>
starting with a rigid structure is a bad idea as that sets you off in
certain direction, which works for well known problems like compilers
and regexp engines, but for more complex problems which don't have a
clear implementation roadmap, it's like shooting a few of your toes
off at the start of a sprint. delay design decisions</a>
even during the implementation stage.</p>


no task is easier than other
2025-09-26T00:00:00+00:00
i think i wrote about this before, but will do again. no task is
easier than other, some take less time, some take more. i made a
similar statement recently "this is easy, just a 10m task" regarding a
task, and it took me quite some time to finish it. similar thing
happened with another taks in the past, i thought it's easy and i
overlooked some details, which were caught in a code review.</p>


refactoring code
2025-09-26T00:00:00+00:00
in delay design decisions</a>, we talked about not
refactoring ahead of time when you don't know what problems lie ahead.
that was all true, but that only applies to projects in their initial
stage. this doesn't apply to multi people projects which are past that
initial stage.</p>
interfaces can also be used for refactoring, but it can be a little
tricky. interfaces introduce some assumptions and if the platform api
or the implementation api doesn't conform to those assumptions, it
becomes a complex mess pretty quickly.</p>
so if you are working on multiple projects, then note that they may
require totally different approach to things as basic as refactoring.
the rules which apply to one might not apply to other. usually asking
the question "can this be improved" takes you to a crossroad where you
have all the options cached into your head to decide what's best.</p>


data and system security
2025-09-19T00:00:00+00:00
data at rest should be encrypted, i.e through disk encryption. data
which moves around should be encrypted either with a password or with
asymmetric keys. disable sshd.service</code>, keep passwords super secret.
don't execute any script from the internet on your system. use a password
manager to generate and store passwords.</p>
have multiple copies of the data, with multiple git hosting providers.
private repositories aren't private, never push plaintext secrets.
backup data at regular intervals on hard-drives, once an ssd is dead,
your data is lost forever. use open source software and get into a habbit
of reading and auditing other's code.</p>


getting things done
2025-09-18T00:00:00+00:00
it takes time. put in time and you get things done. put in little
little time in multiple places and you hardly make any progress in
any of them. if you hit a wall, ask yourself what's the problem and
how it can be fixed. always maintain a log of what you thought and did
and what you found. initially it takes some time before things start
making any sense.</p>
ask for help from your mentors or from devs on irc as soon as you find
you are not making any progress even after trying a few approaches. a
fragmented effort doesn't produce much results, so make sure you are
not shifting contexts often.</p>


delay design decisions
2025-09-15T00:00:00+00:00
delay design decisions for as long as possible, only work on things
which you think are absolutely neccessary to make progrss. long
functions, long files are not bad specially when you are starting out.</p>
this is good because the future you would have more context on the
problem and would be able to make wiser choices, also then the
consequences of wrong decisions would be low as you would have made
quite some progress by not building blocks and falling over them over
and over.</p>


search the error message on the internet
2025-09-15T00:00:00+00:00
some error messages like file not found can be fixed by some
investigation, other's which are more complex can be googled. it's
quite possible that someone else got that error and asked about
it either in some github issue or some developer forum like stack
overflow.</p>
asking on irc/matrix can be helpful, you get help pretty quickly on
irc/matrix specially for errors related to languages and tools. you
can also get some good ideas as people there are quite experienced
with software and tools.</p>


don't delete your code, even if you think it's useless
2025-09-06T00:00:00+00:00
i have made this mistake over and over, if i don't like the code, i
just delete it (or used to do so), but that's a foolish mistake. after
learning the hard way, i found that i should store whatever piece of
code i write, in a separate git repository if it's a neat project or
in some common dump repository. this way it will not be lost.</p>
countless times i have needed the same piece of code and i was like
"holy shit! i deleted that last week". code is an asset when you are
able to look into it and recall things, it's a liability when it's
running on other's system, so in that case producing too much code is
not a good idea if you can go by in less.</p>


writing code top down
2025-08-25T00:00:00+00:00
the high level understanding of the problem/code comes first. once you
have that, implementation becomes quite easy. then you go to the lower
level details like the language constructs and the apis needed for the
implementation.</p>
while writing code we start with high level functions and break them
into smaller helper functions doing the low level stuff. we don't mix
high level functions with low level operations. this doesn't mean you
start out with some design or write a lot of boiler plate code. read
delay design decisions</a> and refactoring code</a>
to know more about design and refactoring.</p>


programming and questions
2025-08-24T00:00:00+00:00
if you have questions while working, note them down in the logs, ask
later. some questions can distract you from the important issue at
hand. often staying with your questions gives you answers to them.
don't ask questions ahead of time, they are just distractions.</p>
for valid questions, first look for the answers yourself. if you don't
find anything after a few attempts, ask your mentors or developers on
irc. ask one question at a time. if you have some new questions about the
answers you are getting, note them down, first let the current context
conclude.</p>


english for non-natives
2025-08-24T00:00:00+00:00
speak slowly, that's the mantra. focus on delivering what you think.
it will make through without any issues. trying too hard is the first
step to failure. small pauses while thinking are fine, everyone has to
do a word lookup, even the natives.</p>
don't fake the accent. i know some people who do that, and even i
can't understand what they are saying. good people generally don't
care about your accent as long as they hear you. there's a vocabulary
associated with the professions, make sure to learn it. "shooting
in the foot" is a well known one in the c/c++ community.</p>


stages in a programming pipeline
2025-08-24T00:00:00+00:00
understanding the problem</h2>
the first stage involves reading/preparation</code> before you jump
into the code. you read the ticket in this issue and take notes
about what's the problem and what are the proposed solutions, who's
mentoring the project etc.</p>
rapid prototyping</h2>
once you understand the request, the prototyping and exploration</code>
stage starts. this involves trying different approaches and code
reading. the goal is to cover the most breadth in the least amount
of time. read approaching big projects</a>, comments are better than
separate file worklogs</a> and refactoring code</a> to learn more. during
this stage, you sit down with your mentors and iterate on the ideas
quickly and find what works.</p>
refactoring and code cleanup</h2>
after prototyping, you fill in the imprtant details to cover the edge
cases. once that is done and all the asks were implemented, you start
refactoring the code, to make it readable read. now is the time to remove
the project log comments from the code. be the first reviewer before
pushing the changes</a>.</p>
testing</h2>
tests are scary but they are important. once you push the change for a
final review, you start putting together a follow-up patch with tests.
code constructs and comments can express some assumptions but code
changes over time and comments are at a risk of becoming obsolete.
tests make sure that certain assumptions hold true and they will fail
if some change far away violates those assumptions.</p>


the importance of mentors
2025-08-23T00:00:00+00:00
early in a career in any field be it sports or programming, one needs
good mentors. mentors help you with the basics, support and correct
you when you make mistakes and keep a watch over you to not let you go
stray.</p>
one bad programming habbit i have is that i start running ahead of
myself, i would create an empty project and start with a logger
implementation and then would ask others how do we save user events to
the disk to be able to replay them. and i haven't rendered a single
triangle on the screen.</p>
thanks to nitrix</a> calling me a moron on #c, i realized this. i should
focus on making progress in the project and these abstractions like
logger, or classes/structs to bundle things together should come
naturally as an after effect, i shouldn't start with them.</p>
as someone learning, one should learn without any fear of judgement
or disapproval. good developers often don't sugar coat things and
sometimes it can be pointy. you are there to learn and learn from the
scoldings too, "why are you being scolded", what did you do wrong?</p>
sometimes in arguments over approaches, there is this urge to prove
your point and put the other's argument down, don't give into it.
always put both sides side-by-side and without bias see which one is
better, if you find other's argument week, point it out politely.</p>
            good mentors are gems and if you have one, find yourself lucky</span></span>
            and if you get a chance to mentor someone, find yourself lucky</span></span>
                            "you learn more when you teach"</span></span></code></pre>


raw tools are better than clicky-cliks
2025-08-22T00:00:00+00:00
i still think clicky-cliks like vscode have a point, i recently setup
an opengl project</a> and vscode made it possible for me to forget
about the build system and the debugger, and just focus on code. i
can clone the project on windows or linux, open it in vscode and the
extensions will be automatically installed, the workspace settings
will be applied.. see .vscode/</code>.</p>
but beyond that "cross platform, shared config, just code" usecase,
clicky-cliks are pretty limited. i was assigned a task to add german
translations of calc functions to online notebookbar. had i been a
vscode only person, the only approaches i could have thought of would
have been "do it manually for all 480 functions, one at a time", or
"ask copilot/llm to do it for me".</p>
the llm's output is quite unreliable, not something which you can just
push (if you are responsible) and if i had to then verify each one,
what's the point of using an allm in the first place.</p>
i had a list of english functions which i previously got by printing
them from a running libreoffice (as it loaded them). to get the german
translations, i created a shell script which looped over all those
480 functions and greped them from the translations repo, i found a
pattern in the greps.</p>
1</span>#.</span> BhqdB</span></span>
2</span>#:</span> sc/uiconfig/scalc/ui/headerfootercontent.ui:420</span></span>
3</span>msgctxt</span> "</span>headerfootercontent|buttonBTN_DATE|tooltip_text</span>"</span></span>
4</span>msgid</span> "</span>Date</span>"</span></span>
5</span>msgstr</span> "</span>Datum</span>"</span></span></code></pre>
so then i git greped for msgid \"$enName\"</code> with -A 1</code> to include
the next line, and i wrote it to a file. it looked somewhat like this.</p>
 1</span>..</span></span>
 2</span>msgid</span> "</span>Pages</span>"</span></span>
 3</span>msgstr</span> "</span>Seiten</span>"</span></span>
 4</span>msgid</span> "</span>Date</span>"</span></span>
 5</span>msgstr</span> "</span>Datum</span>"</span></span>
 6</span>msgid</span> "</span>Time</span>"</span></span>
 7</span>msgstr</span> "</span>Uhrzeit</span>"</span></span>
 8</span>..</span></span></code></pre>
then using neovim's macros and find/replace, i cleaned this up to align
every two consecutive lines. then i added the json constructs around each
line using the capture groups in neovim's find/replace. in the end i
had a reasonably reliable list of function names in english and german.</p>
1</span>{</span> en</span>:</span> '</span>Pages</span>'</span>,</span> de</span>:</span> '</span>Seiten</span>'</span> }</span>,</span></span>
2</span>{</span> en</span>:</span> '</span>Date</span>'</span>,</span> de</span>:</span> '</span>Datum</span>'</span> }</span>,</span></span>
3</span>{</span> en</span>:</span> '</span>Time</span>'</span>,</span> de</span>:</span> '</span>Uhrzeit</span>'</span> }</span>,</span></span></code></pre>
after greping i also used uniq</code> to remove duplicates. i had to read
the man pages while i was writing this script, and i could do both in
neovim (like this). this is why i think cli tools like neovim are far
superior to tools like vscode.</p>
</p>
clicky-cliks are still needed as cli tools are sometimes not supported
on all the platforms, neovim and it's clangd don't work that well with
libreoffice on windows, half of the editor is filled with red error
markers and goto-definitions are unreliable. so in those cases, a well
configured vscode might work better. it's important to develop muscle
memory with these raw tools so that whenever you find some non-trivial
task, you can use them and save some time and frustration.</p>


testing one last time
2025-08-22T00:00:00+00:00
it's important to test things one last time before pushing the changes
for review. often some change would break something else around it
which worked just fine before the change. if you work based on
assumptions then you would assume "something works as it did", but in
reality it does not anymore. it's a good practice to validate your
assumptions atleast once when starting the work, and once before
pushing the change.</p>


msys2 is amazing
2025-08-19T00:00:00+00:00
today i discovered msys2, thanks to a good friend who lives on #c irc
channel, nitrix</a>. msys2 from my perspective is
archlinux cli on windows, the package manager is called pacman</code>,
almost everything is available, glfw</code>, clang</code>, neovim</code>, cmake</code>,
ansible</code>... :) everything.</p>


it takes time, don't ^C immediately
2025-08-19T00:00:00+00:00
today i installed windows 10 in a vm and for some time the progress
bar on the installer was stuck to 0%, i thought something is wrong and
was about to press cross button but then at the last moment decided
against it, thought i should wait for a few more moments.</p>
all the sudden the progress counter changed to 100% and i learnt this
lesson. had i pressed that button, i would have wasted quite some time
as i am sure the next time it would have taken the same time, but the
frustration would have built up. but "sometimes things take time" this
shouldn't be used as an excuse for merging crappy code into master :).
so be patient but not blind, blind to obvious problems.</p>


look around the code you are editing
2025-08-14T00:00:00+00:00
sometimes you are blinded by your understanding of the problem, your
mental model. therefore one must ask others for code review to see if
what you think is indeed the best solution or if there's something
obviously wrong with it which you aren't able to see.</p>
sometimes the answer is in the code around the lines you are working
so make sure that you look around, read a few function declarations
above and below and see how things are done there, if it has anything
which you can reuse, some better way of doing things. sometimes it's
not "obvious" so read diligently.</p>


logging macros and programming
2025-08-13T00:00:00+00:00
recently i happened to write some code which i think was beautiful,
not because the code had something special about it, but the logging
macros were a sight to behold. they make the code rock solid, if
logging is on and the condition fails, it would be logged on the
stderr, or to a file making it much easier for the developers to find
what's wrong. they won't have to spend time to find where the issue
is.</p>
this reminds me of the verbose switch, a developer should include a
verbose flag in their logger implementation so that enabling various
levels of logging is a piece of cake, both for other developers and
the users of the software.</p>
 1</span>case</span> SID_NAVIGATOR_SELECT_COMMENT:</span></span>
 2</span>{</span></span>
 3</span>    const</span> SfxPoolItem</span>*</span> pItem</span>;</span></span>
 4</span>    if</span> (</span>pArgs </span>&&</span> pArgs</span>-></span>HasItem</span>(</span>FN_PARAM_1</span>,</span> &</span>pItem</span>)</span>)</span></span>
 5</span>    {</span></span>
 6</span>        OUString aCommentString </span>=</span> static_cast</span><</span>const</span> SfxStringItem</span>*</span>></span>(</span>pItem</span>)</span>-></span>GetValue</span>(</span>)</span>;</span></span>
 7</span>        if</span> (</span>SfxChildWindow</span>*</span> pWin </span>=</span> GetViewFrame</span>(</span>)</span>.</span>GetChildWindow</span>(</span>SID_NAVIGATOR</span>)</span>)</span></span>
 8</span>        {</span></span>
 9</span>            SwNavigatorWin</span>*</span> pNavWin </span>=</span> static_cast</span><</span>SwNavigatorWin</span>*</span>></span>(</span>pWin</span>-></span>GetWindow</span>(</span>)</span>)</span>;</span></span>
10</span>            if</span> (</span>pNavWin</span>-></span>m_xNavi</span> &&</span> pNavWin</span>-></span>m_xNavi</span>-></span>m_xContentTree</span>)</span></span>
11</span>                pNavWin</span>-></span>m_xNavi</span>-></span>m_xContentTree</span>-></span>BringCommentToAttention</span>(</span>aCommentString</span>)</span>;</span></span>
12</span>        }</span></span>
13</span>        else</span></span>
14</span>            SAL_WARN</span>(</span>"</span>sw.ui</span>"</span>,</span> "</span>GetChildWindow(SID_NAVIGATOR) == nullptr</span>"</span>)</span>;</span></span>
15</span>    }</span></span>
16</span>    else</span></span>
17</span>        SAL_WARN</span>(</span>"</span>sw.ui</span>"</span>,</span> "</span>failed to extract FN_PARAM_1 i.e. CommentNumber</span>"</span>)</span>;</span></span>
18</span>}</span></span>
19</span>break</span>;</span></span>
20</span>default</span>:</span></span>
21</span>    assert</span>(</span>false</span> &&</span> "</span>wrong request method</span>"</span>)</span>;</span></span>
22</span>    break</span>;</span></span></code></pre>


don't stop at just one change
2025-08-11T00:00:00+00:00
senior developers don't stop at just one patch in the area. they send
patches from one area in dozens, each building over the previous, or
maybe not. this might be because they notice problems as they go over
the code and then as a consequence end up writing a lot of patches to
fix those.</p>
simply put, be interested in the code around the change, don't just be
focused on fixing the issue at hand and you would build insights over
time. an easy way is to zoom out at the mental model of the code you
just worked on, and push the boundaries of that model just a little
beyond the known region.</p>


read others code and review their patches
2025-08-10T00:00:00+00:00
i have noticed that senior/experienced developers don't shy away from
poking into other's patches. this is a great habbit to inculcate as
you keep yourself updated with the changes happening in the codebase.
you would pick up good habbits as you read others patches. this down
the road would save you a lot of time in reviews.</p>
you then know who worked on what yesterday and whom to talk to about
certain areas of the codebase. reading patches and asking quesions
also helps improve the code quality and it is a nice social thing in
itself.</p>


the book printing episode
2025-08-02T00:00:00+00:00
the problem</h1>
over time i found quite a few programming books which i wanted to
read, books like sicp</a>. but these books were quite expensive online,
sicp was listed on amazon around ₹4400/€44/$51. printing it myself
would cost me ₹800 which is a steal of a deal.</p>
but there was one issue, the lisp code is synatx highlighted i.e. when
printed in grayscale, the readability is compromised. i searched on
the internet "how to convert a colored pdf to a black-and-white pdf"
and the results weren't that useful. it wasn't that simple, but since
i am not an average computer user, i saw an opportunity.</p>
putting it together</h1>
i found pdftoppm</code> which could convert the pages of the pdf file into
images and imagemagick</code> which could transform the appearance of the
images and put them back into a pdf file. after reading imagemagick
wiki</a> for quite some time, i found a few options which gave me
exactly what i wanted.</p>
1</span>magick</span> $</span>input_file</span> \</span></span>
2</span>    -</span>colorspace</span> Gray</span> \</span></span>
3</span>    -</span>level</span> 40%,100%</span> \</span></span>
4</span>    -</span>gravity</span> Center</span> \</span></span>
5</span>    -</span>crop</span> 90x90%+0+0</span> \</span></span>
6</span>    +repage</span> \</span></span>
7</span>    $</span>output_file</span></span></code></pre>
this converts the image to grayscale and increases the contrast
deepening the blacks, crops the extra margin space giving us a zoomed
in image.</p>
automating things with a makefile</h1>
a makefile is basically an evolved shell script, it can do everything
which a shell script can do, but in a makefile one can define the
relationships between sources and targets and this with the -j</code> flag
exponentially speeds up things.</p>
 1</span>SHELL</span>       =</span> bash</span></span>
 2</span>input_pdf</span>   =</span> sicp.pdf</span></span>
 3</span>output_pdf</span>  =</span> sicp_converted.pdf</span></span>
 4</span>page_count</span>  =</span> $(</span>shell</span> pdfinfo </span>$(</span>input_pdf</span>)</span> | awk '/^Pages:/ </span>{</span>print </span>$2</span>}</span>' | sed 's/Pages://;s/ //g'</span>)</span></span>
 5</span></span>
 6</span>input_pdf_images_dir</span>  		=</span> $(</span>input_pdf</span>)</span>_original</span></span>
 7</span>converted_pdf_images_dir</span> 	=</span> $(</span>input_pdf</span>)</span>_converted</span></span>
 8</span></span>
 9</span>original_images</span> 	=</span> $(</span>foreach</span> page_number</span>,</span>$(</span>shell</span> seq -w 1 </span>$(</span>page_count</span>)</span>)</span>,</span>$(</span>shell</span> echo </span>$(</span>input_pdf_images_dir</span>)</span>/</span>$(</span>input_pdf</span>)</span>-</span>$(</span>page_number</span>)</span>.png</span>)</span>)</span></span>
10</span>converted_images</span> 	=</span> $(</span>patsubst</span> $(</span>input_pdf_images_dir</span>)</span>/</span>%</span>.png</span>,</span>$(</span>converted_pdf_images_dir</span>)</span>/</span>%</span>.png</span>,</span>$(</span>original_images</span>)</span>)</span></span>
11</span>sorted_images_list</span> 	=</span> $(</span>sort</span> $(</span>converted_images</span>)</span>)</span></span>
12</span></span>
13</span>all</span>:</span> pdf_to_images create_converted_pdf</span></span>
14</span></span>
15</span>pdf_to_images</span>:</span></span>
16</span>	mkdir -p </span>$(</span>input_pdf_images_dir</span>)</span></span>
17</span>	pdftoppm </span>$(</span>input_pdf</span>)</span> $(</span>input_pdf_images_dir</span>)</span>/</span>$(</span>input_pdf</span>)</span> -pn</span>g</span></span>
18</span></span>
19</span>$(</span>original_images</span>)</span> : pdf_to_images</span></span>
20</span></span>
21</span>create_converted_pdf</span> :</span> $(</span>converted_images</span>)</span></span>
22</span>	magick </span>$(</span>sorted_images_list</span>)</span> $(</span>output_pdf</span>)</span></span>
23</span></span>
24</span>$(</span>converted_pdf_images_dir</span>)</span>/%.png : </span>$(</span>input_pdf_images_dir</span>)</span>/%.png</span></span>
25</span>	mkdir -p </span>$(</span>dir</span> $@</span>)</span></span>
26</span>	magick </span>$<</span> \</span></span>
27</span>		-colorspace Gray </span>\</span></span>
28</span>		-level 40%,100% </span>\</span></span>
29</span>		-gravity Center </span>\</span></span>
30</span>		-crop 90x90%+0+0 </span>\</span></span>
31</span>		+repage </span>\</span></span>
32</span>		$@</span></span>
33</span></span>
34</span>clean</span> :</span></span>
35</span>	rm -rf </span>$(</span>output_pdf</span>)</span> $(</span>input_pdf_images_dir</span>)</span> $(</span>converted_pdf_images_dir</span>)</span></span></code></pre>
there's a lot of room for improvement, currently we convert the
whole pdf to images in pdf_to_images:</code>, one could break that into
individual step where the original image is generated on the fly so
that we can run that on multiple threads and speed up things.</p>
but this would take some time, some other day :).</p>


levels of abstractions (functions)
2025-07-31T00:00:00+00:00
what the function does should be apparent from the function, variable
and struct names. low level functionality should be separated out into
functions so that when someone is reading a high level function, they
have a choice of diving into details (i got that from clean code.
there can be exceptions to this but generally i like this approach).</p>


bad critics should be dealt with
2025-07-31T00:00:00+00:00
critiques are good, they help you improve, but not all critiques are
good, and for those bad ones, one needs to stand for their opinions.
these critiques don't provide any solid reasoning in their comments,
just say "i don't like it", "i don't agree", "i am against it", or
they use too many words which conveny almost nothing.</p>
good ones tell you "why they dislike the idea" and what they consider
a better approach/solution.</p>


reading error messages carefully
2025-07-31T00:00:00+00:00
often error messages are quite long and it's a hunt to find the
useful ones. redirecting the log/errors to a log file is one possible
solution. even then it takes patience and quite some scrolling before
you get to the important part. the editor can highlight keywords like
ERROR</code> or FAILURE</code> to help spot the hotspots.</p>


the natural way of expressing things
2025-07-31T00:00:00+00:00
each function or logical block of code has a direction, it calls some
functions on objects, gets some data, operates on that data. there are
multiple ways of expressing this flow, not all being good.</p>
this</a> commit demonstrates it pretty well, instead of checking if (vUrls.empty())</code> and returning, we check for the favourible case and
thus connect the logical chain with the previous statement i.e. get the urls</code> -> if not empty, open them all</code>. when written the bad way,
it reads like get the urls</code> -> return if empty</code> -> if not empty, open them all</code>, there`s redundent logic in this chain of thought.</p>


when learning to program
2025-07-31T00:00:00+00:00
150-200 page books are a good place to start. man pages are ok for
cli tools but for bigger tools and languages, one needs a good book.
after gaining some experience, one might want to dive deep into the
specification to learn more about the system.</p>
and it takes time. programming skills don't compound if you keep
switching context on a weekly/monthly basis. you have to do one
thing for years to get good at it. and it takes long sittings at a
time. constant context switching isn't helpful, you gain some insights
only when you spend some time with the problem.</p>


add nice screenshots to the patches
2025-07-31T00:00:00+00:00
when pushing ui changes, it's very very important that we add the
screenshots along with the change. that way it becomes very easy
for the reviewers as they know what to look for while testing,
often issues are directly visible in the screenshots, so the
review-rework-push cycle moves quickly.</p>


shiny object syndrome
2025-07-31T00:00:00+00:00
in disciplines like programming where you don't have a clearly laid
out plan, it's quite easy to pick up 10 things on the way and jump
from one to the other every other day and waste a lot of time doing
this.</p>
one must ask themselves what they are after, what they want to achieve
by doing one thing or the other and then focus on one thing at a time,
on the thing which makes the most sense at the moment.</p>


project planning and time management
2025-07-31T00:00:00+00:00
proper planning is the most important part of any project, you keep
track of the most important resource i.e. time. weekly milestones help
with this, you know where you want to be at the end of this week and
therefore you know how to spend the time you have. this way you are
not shooting arrows in the dark and have a roadmap.</p>
planning is not easy, you can over estimate your abilities and
add too much to your plate. so having a reasonable free buffer is
also important so that you have some time to be creative with your
approach, some wiggle room for possibilities.</p>


programming verbally and thinking with language constructs
2025-07-31T00:00:00+00:00
programming is an active process, you speak out what you see in your
head. just looking at the code is not enough to get things done in
reasonable time, you got to have a systematic approach. the processing
has to be on the conscious mind, not the subconscious. after a few hours
of verbal investigation, you understand what's going on.</p>
this is specially relevant when you are dealing with a large codebase.
comments are better than separate file worklogs</a>. a worklog helps you
externalize the mental model so that you can pick up where you left
the last time. an important use of worklog is hierarchies, parent-child
hierarchies and relationships of types with the others. so you add the
type to your hierarchy as you go on reading and at the end you have a
pretty clear picture of how things are laid out.</p>
while reading code, pay special attention to the types, and ask
yourself why is this type passed into this function, or in that
class's constructor. why this parent class instance keeps a reference
to the child etc. these help you build a mental model. thinking
in terms of functionality instead of parent-child terms helps as
parent-child analogy is just a language construct for who has what
functionality, code is always in terms of functionality.</p>


chatbots are not tools, just a search engine at best
2025-07-30T00:00:00+00:00
chatbots are not tools, most of the times they are black boxes
controled by big companies. they aren't reliable and to write
something usable, it takes more time to fix the code written by a
chatbot than writing it yourself from scratch.</p>
the worst part is that you don't have any control over their pricing,
the quality of results they produce and the algorithm working behind
the scenes.</p>


manpages and documentation are the original sources
2025-07-30T00:00:00+00:00
man pages and documentation are the original sources of knowledge on
any tool or language. good documentation involves tutorials to get one
used to the tool. then there are some good books on the topic.</p>
manpages, documentation and books can be outdated though. so it's
important to read them with a grain of salt and if something doesn't
match then looking at the code is the next best step. looking at
code (eg: oss projects) comes in quite handy when learning some new
language or library as it takes you beyond the tutorial.</p>


better tools exist, the cli ones
2025-07-30T00:00:00+00:00
cli tools are better than gui tools (generally) as they are way more
extensible and they don't change much over time. cli tools can be
cobbled together to accomplish some complex task. open source tools
are better than propriatery tools.</p>
since they don't change over time, you are less likely to face any
hinderance in your workflows. cli tools often provide qutie powerful
mechanisms (like vim macros) and complex tasks become quite simple
when you utilize these mechanisms.</p>


i love unit tests and code reviews
2025-07-29T00:00:00+00:00
unit tests don't just save me from extra work on regressions
introduced by someone else's changes somewhere, they also help the
other developers find bugs in their code. now when unit tests fail on
my code, i am thankful that someone wrote that test or else the bug
might have slipped into the code unnoticed.</p>
not to undermine the role reviewers have in making sure that the
code isn't sloppy or missing some edge case somewhere. i learn
from reviewers (senior devs) the way to think about edge cases and
potential bugs, how to find them and squash them.</p>


sometimes old way is the best way
2025-07-29T00:00:00+00:00
some problems are complex and comments and class hierarchy on a text
file might not be enough to understand the problem. a text file allows
you to write only in two directions, up or down.</p>
paper on the other hand provides you four dimentions and more
expressibility. you can draw boxes, arrows from one thing to the other
and illustrations. some problems require a more expressive medium than
just thought and a text file, and nothing beats the good old
paper-pencil combo at that.</p>


thinking of software and ux from the users' perspective
2025-07-29T00:00:00+00:00
as a developer, it's quite important to not design things for yourself
but for the users. the term users covers a vast demographic from ones
who are quite good at computers to the ones who don't have any idea about
computers and are trying to understand what all the options in the
user interface mean.</p>


real world bugs are not so simple
2025-07-28T00:00:00+00:00
some of these bugs don't show up when testing with a dummy document,
or testing in a developer environment. these bugs are quite hard to
reproduce. other bugs might trigger in certain conditions on only
certain systems.</p>
bit flags cause quite some headaches specially in languages like
c and c++ which don't even complaint about such errors. types are
another concern in such languages as you can often use wrong type like
equating/assigning to/from different sized integers. these are also a
nightmare to debug.</p>


the risks of copy pasting code
2025-07-28T00:00:00+00:00
every now and then you might copy some code from here and paste it
there forgetting to update to pasted code and the worst thing is that
it might still work :).</p>
then you get to know about this in production. worst when someone else
pushes a patch titled copy paste error and adds you as the reviewer,
have been there myself, not a good place to be in.</p>
if you have such copy-paste errors in your code, that means that you
are not reading the code properly. one should first go through the
code token by token and only as they parse the token in their head,
they should think of it's high level meaning and where it fits in the
mental model.</p>
while parsing each token, ask yourself, is this the right token? does
this belong here? is it used correctly? and based on that decide
whether a token should be there or should be removed. this should be
done while writing the code, while copy-pasting code and while code
reviewing.</p>


don't get lost in the surrounding code
2025-07-28T00:00:00+00:00
there are a lot of classes around the code that you are trying to
debug and understand, and it's easy to get sidetracked by going to
definition of class after class and digging into the specifics.</p>
therefore one should make their way through the code to the core of
the problem, to the code which is causing the issue and then expand
from there as much as required. setting the right breakpoints helps,
using conditional breakpoints and printf statements helps. if it's a
crash then stack traces tell exactly where you should set the first
breakpoint.</p>


the verbose switch
2025-07-28T00:00:00+00:00
every program has some kind of verbose switch, specially those which
run as daemons/clients/listeners. it enables various levels of
logging which helps us understand what's actually going on and fix our
issues.</p>
while writing your own programs, it's quite important to add such log
statements at key points such as conditionals and data state check
points so that if anything goes wrong, the users of your program get
to know exactly what's going on.</p>


self documenting code is a lie, write comments!
2025-07-26T00:00:00+00:00
comments should explain why the code is this way. this helps the
readers of the code quickly get clues about what is going on so that
they don't have to goto the definition of each call and figure things
out. header files should have doxygen comments to describe the api
and the internals of a struct like why it exists.</p>
here are a few code snippets from sanjay ghemawat</a>'s (a well known
google enginner) code, one can read the code with comments like prose.</p>
 1</span>//</span> findfilter is a filter that produces matching nodes under a filesystem</span></span>
 2</span>//</span> directory.</span></span>
 3</span>type</span> findfilter</span> struct</span> {</span></span>
 4</span>    dir</span>       string</span></span>
 5</span>    ifmode</span>    func</span>(</span>os</span>.</span>filemode</span>)</span> bool</span></span>
 6</span>    skipdirif</span> func</span>(</span>string</span>)</span> bool</span></span>
 7</span>}</span></span>
 8</span></span>
 9</span>//</span> find returns a filter that produces matching nodes under a</span></span>
10</span>//</span> filesystem directory. the items yielded by the filter will be</span></span>
11</span>//</span> prefixed by dir. e.g., if dir contains subdir/file, the filter</span></span>
12</span>//</span> will yield dir/subdir/file. by default, the filter matches all types</span></span>
13</span>//</span> of files (regular files, directories, symbolic links, etc.).</span></span>
14</span>//</span> this behavior can be adjusted by calling findfilter methods</span></span>
15</span>//</span> before executing the filter.</span></span>
16</span>func</span> find</span>(</span>dir</span> string</span>)</span> *</span>findfilter</span> {</span></span>
17</span>    return</span> &</span>findfilter</span>{</span></span>
18</span>        dir</span>:</span>       dir</span>,</span></span>
19</span>        ifmode</span>:</span>    func</span>(</span>os</span>.</span>filemode</span>)</span> bool</span> {</span> return</span> true</span> }</span>,</span></span>
20</span>        skipdirif</span>:</span> func</span>(</span>d</span> string</span>)</span> bool</span> {</span> return</span> false</span> }</span>,</span></span>
21</span>    }</span></span>
22</span>}</span></span></code></pre>


the art of writing commit messages
2025-07-26T00:00:00+00:00
the commit message should be clean and to the point. it should not
include any text walls which might make it hard for the reader to
distinguish useful information from some text that you thought would
be nice there.</p>
write everything that (you or) your fellow developer from future
should know about the code you are pushing, when they git blame and
read the commit message, they should get the whole technical and
design story of that change.</p>


push changes in a series of clean atomic commits
2025-07-26T00:00:00+00:00
each patch/commit that you create should do just one thing and
shouldn't do anything else. avoid unneccessary formatting changes and
cleanups in the middle of a feature commit as they just introduce
noise to the patch making it harder to review.</p>
when someone is reviewing your patch, they don't know anything about
it, so they have to load your-change into their head and make sense
out of it and when they find that they loaded formatting changes, they
have to take it out which impedes the process of reviewing.</p>
each commit should fix a subproblem and should be created as you fix
that subproblem. this way you don't have a lot of uncommited code at
later stages and thus avoid the risk of breaking something and not
knowing what broke, sure you can figure out, but that wastes time.</p>


don't write many conditions inside the conditional
2025-07-26T00:00:00+00:00
often we find ourselves in situations where we are have many
conditions with ==</code> and !=</code> and &&</code> and ||</code> in various
combinations. in such cases we should refactor the code and create
boolean variables out of those conditions and then put those boolean
variables in the conditionals. this makes the code much more readable.</p>
 1</span>private</span> adjustDocumentMarginsForComments</span>(</span>onZoomOrResize</span>: </span>boolean</span>)</span> {</span></span>
 2</span>    const</span> commentSection</span> =</span> app</span>.</span>sectionContainer</span>.</span>getSectionWithName</span>(</span></span>
 3</span>        app</span>.</span>CSections</span>.</span>CommentList</span>.</span>name</span>,</span></span>
 4</span>    )</span> as</span> cool</span>.</span>CommentSection</span>;</span></span>
 5</span></span>
 6</span>    const</span> cursorAtComment</span> =</span></span>
 7</span>        commentSection</span>.</span>sectionProperties</span>.</span>selectedComment</span> &&</span></span>
 8</span>        !</span>commentSection</span>.</span>sectionProperties</span>.</span>selectedComment</span>.</span>isEdit</span>(</span>)</span>;</span></span>
 9</span></span>
10</span>    if</span> (</span>!</span>onZoomOrResize</span> &&</span> cursorAtComment</span>)</span> {</span></span>
11</span>        commentSection</span>.</span>unselect</span>(</span>)</span>;</span></span>
12</span>    }</span></span>
13</span></span>
14</span>    const</span> commentsHiddenOrNotPresent</span> =</span></span>
15</span>        commentSection</span>.</span>sectionProperties</span>.</span>show</span> !=</span> true</span> ||</span></span>
16</span>        commentSection</span>.</span>sectionProperties</span>.</span>commentList</span>.</span>length</span> ==</span> 0</span>;</span></span>
17</span></span>
18</span>    if</span> (</span>commentsHiddenOrNotPresent</span>)</span> {</span></span>
19</span>        this</span>.</span>recenterDocument</span>(</span>)</span>;</span></span>
20</span>        return</span>;</span></span>
21</span>    }</span></span>
22</span></span>
23</span>    if</span> (</span>this</span>.</span>documentCanMoveLeft</span>(</span>)</span>)</span> {</span></span>
24</span>        this</span>.</span>documentScrollOffset</span> =</span> this</span>.</span>documentMoveLeftByOffset</span>(</span>)</span>;</span></span>
25</span>        this</span>.</span>scrollHorizontal</span>(</span>this</span>.</span>documentScrollOffset</span>,</span> true</span>)</span>;</span></span>
26</span>    }</span> else</span> if</span> (</span>onZoomOrResize</span>)</span> {</span></span>
27</span>        this</span>.</span>documentScrollOffset</span> =</span> 0</span>;</span></span>
28</span>    }</span></span>
29</span>}</span></span></code></pre>
this typescript code is quit readable, the boolean variables which are
later used in the conditionals give meaning to the bunch of conditions
themselves and thus we don't need comments there to describe what the
conditional is there for or what the conditions represent.</p>
there is no crouding in one place. had these conditions been placed
directly in the conditionals, the could would have been messy and
hard to understand as one wouldn't know what those conditions and
conditionals represent without some doing digging themselves.</p>


decoupling data from the processing logic
2025-07-26T00:00:00+00:00
you have data, some of it is global i.e. the application state and
some of it is local to modules or functions. some functions process
the data changing it form one consistant state to another and produce
no side-effect, while others produce side-effects based on the input
data. no function should do both of them together. we are not talking
about constructors here.</p>
this is relevant at the cleaning-up stage, not at the prototyping
stage where the soul focus should be on exploring hidden corners and
implementation details instead of building abstractions. read
refactoring code</a> and stages in a programming pipeline</a> to know more.</p>


good code vs bad code (and documentation)
2025-07-26T00:00:00+00:00
good code is very descriptive about itself, it doesn't present a
fragmented context/model of the problem to the reader but tries to
fill in as many details as possible, either through comments or by
using code constructs which make that aspect of the mental model
'obvious' at first look.</p>
the reader knows at the first look where to go next. enums and data
structures are one way to do it, proper naming of functions and
structures help quickly understand what data is being transformed in
what way. but most of the code out there is not that good, some of it
is written by me ;).</p>
documentation and manpages should have minimal examples so that the
users of the program/library have something to hold on to. maybe this
is what a tutorial is supposed to do. i hate man pages without any
examples at the end.</p>


you own the code you write, thus are responsible for it
2025-07-26T00:00:00+00:00
this applies to a junior++ && senior--</code> developer. during a project
there are a lot of moments which pivit the direction of development,
be it changes in the proposed interface layout, or some additional
feature/mechanism which aren't that simple.</p>
taking input/suggestions is nice but at the end you must decide for
yourself whether you want to follow those suggestions or not. because
at the end, you have to implement it and maintain it. having realistic
proposals and verifying their validity before starting the work is a
nice way to avoid such issues later down othe road. that said, things can
be incrementally added, one at a time.</p>


be the first reviewer before pushing the changes
2025-07-26T00:00:00+00:00
before pushing the patch, review it yourself both the small change
that you just made and where it stands in the long series of changes
or in relation to the change you are going to ammend it to. often
it happens that an ammend voids the previously added comments and
assumptions in code, so they need to be updated. then question every
single line as if it's not your code and then push and ask someone
else to review it.</p>
you are responsible for the changes you push therefore you should do
the most amount of work to see that it's correct. pushing changes
carelessly, expecting someone else to correct you shows how involved
you are in the process.</p>


complexity and clever solutions come back to bite you
2025-07-26T00:00:00+00:00
clever solutions are often complex and therefore only a few understand
them. thus other devs might change the code around your complex
solution and the whole thing might fall apart. thus it becomes a
maintainance nightmare.</p>
good reviewers usually don't approve such changes, or if they don't
oppose it, their reluctance to push it is quite clear. code is not an
asset, it's a liability, and i don't remember the exact implementation
details of projects i implemented an year ago. so keep it simple and
you would thank yourself.</p>

printfdebugging - programming

iteration is a feature, not a bug

refactors don't have to be messy

TUIs are far more flexible than GUIs

build systems to help you build habbits

making progress on tasks

the book printing episode (part 2)

knowledge building

hackers don't need permission to look at the source

read the friendly manual

reading comments, manuals, instructions

report complete and accurate observations

bias and assumptions

the initial few hours into a project are a bit scary

how to solve any programming problem

think at the global scope as you modify some local scope

how to fix your code after code reviews

experiments lead to deep insights

don't rush to get the changes in

remote work and staying online

tracking progress on assigned projects

printf-debugging

writing code with a nicely* organized* context

haste is bad, think twice before pressing any button

the process matters if it gets results (mostly)

what editor you use matters!

when to ask others to review your patches

don't stress about it too much

reading other's code

only commit messages (and tests) survive the test of time

push -> review -> rework -> review cycle, the programming pipeline

profiling code in browser

writing tests for your code

log files are better than stdout

focus, attention, reading and deep work

searching for help on a disfunctional internet

starting the day with a list of tasks

a timer is better than a clock for timeboxing

comments are better than separate file worklogs

approaching big projects

no task is easier than other

refactoring code

data and system security

getting things done

delay design decisions

search the error message on the internet

don't delete your code, even if you think it's useless

writing code top down

programming and questions

english for non-natives

stages in a programming pipeline

understanding the problem</h2> the first stage involves reading/preparation</code> before you jump into the code. you read the ticket in this issue and take notes about what's the problem and what are the proposed solutions, who's mentoring the project etc.</p>

the importance of mentors

raw tools are better than clicky-cliks

testing one last time

msys2 is amazing

it takes time, don't ^C immediately

look around the code you are editing

logging macros and programming

don't stop at just one change

read others code and review their patches

the book printing episode

levels of abstractions (functions)

bad critics should be dealt with

reading error messages carefully

the natural way of expressing things

when learning to program

add nice screenshots to the patches

shiny object syndrome

project planning and time management

programming verbally and thinking with language constructs

chatbots are not tools, just a search engine at best

manpages and documentation are the original sources

better tools exist, the cli ones

i love unit tests and code reviews

sometimes old way is the best way

thinking of software and ux from the users' perspective

real world bugs are not so simple

the risks of copy pasting code

don't get lost in the surrounding code

understanding the problem</h2>
the first stage involves `reading/preparation</code> before you jump into the code. you read the ticket in this issue and take notes about what's the problem and what are the proposed solutions, who's mentoring the project etc.</p>`