|
|
|
people say that ai is a tool just like any other tool and you should use it but i don't think it's a tool. tools are like neovim i.e. reliable and make the interaction easier, they don't off-load the responsibility of reasoning to something else but rather give you some amazing tools like the macro system and the scripting functionalities and then you decide how to use them to make your workflows faster and better.
not only the llms are black box but also ones controled by a few big companies each of which is pouring in money in this fire pit to reach there "first" and when they do, they would do everything to make the most profit out of them. and like politicians these companies want the average developer to be poor and dependent on their llms (i.e. food grains), or else how would they survive.
learn from the dragons who are the original sources of all knowledge, i am talking about manpages and the specification (info pages). and it's best to start a discussion around that in an irc channel related to that topic. that way you have expert opinion about the thing and you diversify your viewpoint. videos and random articles are really bad and ai is the worst. it should be built into your instincts that if you need to search anything related to some command or language, it's either manpages or some book.
professional tools can be quite complex and it's easy to get overwhelmed by all the options that they provide. so it's advised to start with a small/familear codebase and with a limited subset of the tool's functionality and then slowly expand to more niche use cases and to more complex codebases.
prefer command-line tools (e.g., gdb, objdump, git) and manpages over ide pretty printers or forums for authentic, up-to-date information. even though these tools seem daunting at first, once you get used to them, you understand the convenience of a "never changing interface" compared to the now-a-days ides which change the interface and functionality with every update, and most of the functionality is through extensions which might break at any time due to api mismatch or something.
rr is used to record the state of a program's whole execution and
then play it like a video (back and forth). conditional breakpoints
and watchpoints are a cherry on the top. callgrind and cachegrind
help identify performance bottleneck and memory issues.
sometimes tools fall apart, tools like git clients or language servers. in such cases it's better to go the old route and just compile the thing to see what the compiler has to say about the code. i think disabling lsp is not a bad idea as you are going to know what to write to do what already during the investigation, think about it.
i had to create an array of strings in typescript which were wrapped
around with _('') and i had to type each one manually. one way was
to type everything individually, or type these before hand and fill in
the words. another better way was to just type the words continuously
and then using vim regex put these around the words. that was much
faster. so learn these small mechanisms and you will find ways to use
them together if you ask yourself "is there a better way of
doing this".
one of the most important detail that one has to take care of while typing is that you have to tap the keys with the front of your fingers not the tips. tapping with the tips seems more convenient but it blocks gliding of fingers over other keys, whereas when you type with the front parts, your fingers are automatically lower than the tipped position and thus there is less delay in moving it from one key to the other.
