plans.txt the balancing act
Original Author: Sahil Gautam <printfdebugging@gmail.com>
Homepage: <https://printfdebugging.in/>
License: GNU GPL v2
==============================================================================
CONTENTS
0. Diving Deep diving-deep
1. Actively Avoiding Shortcuts actively-avoiding-shortcuts
2. Raw Tools raw-tools
2. The Balancing Act the-balancing-act
3. Getting the Basics Right getting-basics-right
4. Mastering the Basics mastering-the-basics
5. Stepping UP the Game stepping-up
6. Programming Literature programming-literature
7. Projects projects
==============================================================================
Diving Deep diving-deep
i was sitting in a class without anything to do, so i started reading the
man page for ctags, i read a few paragraphs, tried a few of those
commands or options, and i realized something really important...
there are many many options that one doesn't even get to know about if one
doesn't dive deep into the specification/manpage/docs. tutorials and stack
overflow posts are good, but they help you till a certain point beyond
which you "have" to dive deep into the source code or the docs in order to
make any further progress.
i found a bug in my work-logging script, it represents time as integer, so
1.5 represents 1.5 x 60 minutes, but i wanted it as HH:MM. i had two
options, ask copilot to fix it for me, quickly, or put in some hours and
do it the hard way myself. i choose the hard way, i am glad i did. after
reading through python docs, testing that in small programs, i ended up
with a great understanding of date time objects, datetime.strptime() and
datetime.strftime() functions.
i felt great joy in searching for things, not getting them in the first go,
searching again, and again, testing that... and waiting patiently for the
moment when 'it clicks'. i went back deeply understanding the problem, the
process and the solution. having deep diving instincts go a long way in the
journey of becoming a good programmer.
==============================================================================
Actively Avoiding Shortcuts actively-avoiding-shortcuts
shortcuts seem convenient at first, but if you take an average, they don't
help much. if the 'shortcut plan' doesn't work as planned, it usually
takes more time than the 'usual hard way' approach, not to mention the
frustration.
shortcuts work because they are tricky, and therefore complicated. the
'boring, hard way' takes time, but is really really simple. there are
hardly any 'got you' moments in the 'boring, hard way', so it hardly falls
apart. on the other hand, if even a single thing is out of place, the
'shortcut plan' fails.
for example, i used LSPs in the past and there were moments when they
would just fall apart, like on windows and i was left helpless in those
moments. so i replaced LSP with ctags, a really simple tool, one which
i can read, modify and rewrite to suit my workflow.
i also removed autocompletion popup from my editor because since i was
able to just tab complete the function and variable names, i wasn't
remembering them, my memory was getting sloppier. when i write code
without autocompletion, i feel a sense of ownership, i feel "i wrote this
code", and the process has become much more fulfilling.
because of this, i now read the code properly and don't just move my eyes
over it. i remember things now.
==============================================================================
Raw Tools raw-tools
i was using neogit, a git client for neovim. it broke in the middle of a
git rebase -i, started throwing errors. i realized that if i knew raw
git well, this roadblock would never have appeared in the first place.
raw tools (tools on cli, without any prettify non-sense) are rock solid,
they might be a little hard to grasp at first, but once you know your
commands, it will never dissappoint you.
switch the workflow by learning the commonly used/needed commands and then
figure out the rest by diving into the manpages and docs as you find time.
take notes on the way to not forget things.
==============================================================================
The Balancing Act the-balancing-act
it's often the case that one finds oneself interested in many things and
isn't able to decide which one to start with. the balancing act says...
- organize all the choices into labeled baskets
- then create time some slots on the positive side of the timeline
- pick up a few from each basket and place them into the slots
- the complexity of items in the slots should increase gradually
- then allocate time for items from each slot in your day/week
this way one doesn't feel like missing out on something, and if one
consistently works on the things, things start coming together. this is
really easy in theory but requires seriousness, discipline and commitment.
==============================================================================
Getting the Basics Right getting-basics-right
- [ ] the c programming language
- [ ] a tour of cpp
- [ ] learn opengl
- [ ] beej's network programming guide
- [ ] gnu make macros
- [ ] sfml blueprints
- [ ] 10km/day x 100 days (1000km)
- [ ] 20 pushups/day (2000 pushups)
==============================================================================
Mastering the Basics mastering-the-basics
- [ ] writing an interpreter in go
- [ ] writing a compiler in go
- [ ] crafting interpretrs
- [ ] the book of shaders
- [ ] raytracing weekend series
- [ ] vulkan tutorial
- [ ] 10km/day x 100 days (1000km)
- [ ] 30 pushups/day (3000 pushups)
==============================================================================
Stepping UP the Game stepping-up
- [ ] structure and interpretation of computer programms
- [ ] clojure programming language
- [ ] regexp engine from scratch
- [ ] arena allocation and garbage collection
- [ ] the art of x86 assembly
- [ ] kohi game engine
- [ ] computer graphics by armin
- [ ] real time rendering
- [ ] 10km/day x 1000 days (10000km)
- [ ] 30 pushups/day (30000 pushups)
==============================================================================
Programming Literature programming-literature
- [ ] vulkan specification
- [ ] opengl specification
- [ ] x86 specification
- [ ] c specification
- [ ] c++ specification
- [ ] gcc specification
- [ ] opengl superbible
- [ ] opengl programming guide
- [ ] x11 programming manual
- [ ] beautiful code
- [ ] coders at work
- [ ] the philosophy of software design
- [ ] the architecture of open source applications
- [ ] operating system in three easy pieces
- [ ] windows system programming p2
- [ ] windows system programming
- [ ] programming windows 5e
- [ ] write great code 1 - 6
- [ ] 66 effective debugging tactics
- [ ] the art of debugging
- [ ] systems performance
- [ ] introduction to algorithms (clrs) (in c)
- [ ] game engine arcitecture
- [ ] game programming patterns
- [ ] unicode text rendering
- [ ] variable width font rendering
- [ ] collabora TTT talks
- [ ] 10km/day x 1000 days (10000km)
- [ ] 20 pushups/day (20000 pushups)
==============================================================================
Projects projects
- [ ] suckless
- [ ] dwm
- [ ] dwl
- [ ] foot
- [ ] dmenu
- [ ] st
- [ ] surf
- [ ] tabbed
- [ ] feh
- [ ] sxiv
- [ ] mu
- [ ] zathura
- [ ] mpv
- [ ] bash
- [ ] thunderbird (chat and mail internals)
- [ ] rawtools
- [ ] gdb
- [ ] rr
- [ ] perf
- [ ] make
- [ ] ctags
- [ ] git
- [ ] clang-format
- [ ] callgrind
- [ ] text editors
- [ ] kilo
- [ ] kilua
- [ ] ded
- [ ] vim (read the code)
- emacs & exwm & xembed
- [ ] libraries
- [ ] glfw
- [ ] lua
- [ ] luajit
- [ ] tools/automation
- [ ] docker
- [ ] jenkins
- [ ] github and gitlab actions
- [ ] personal projects
- [ ] project earth
- [ ] project env
==============================================================================
vim:tw=78:ts=8:ft=help:norl:fdm=marker:fmr=<<<,>>>:ma:noro