cleaning out open tabs

reflections on a decade of coding

https://www.scattered-thoughts.net/writing/reflections-on-a-decade-of-coding

• build your own text editor!
• learned a lot: lots of tiny changes in habits, processes and values; has lots of takes after programming for 12 years and lots of categories in which he has useful experience. I'll break these down and mirror the subsections

writing

https://www.scattered-thoughts.net/writing/writing/

• idea file for developing ideas
  1. stream of consciousness
  2. the structured data with some organization; determine what parts of the structure are difficult to articulate, then iterate on them
  3. can choose not to organize the ideas at all; this works moreso for experience reports than anything else, though
• deciding what to leave out is the most difficult part - alternate between generating ideas and refining them, and continue refining them until you think you have a clear purpose! don't get stuck in one "mode".
• revisit - add links, citations, fact-checking, etc. to precisely clarify your intentions.
• always illustrate with concrete examples - then wait a few days!
• avoid anything uncharitable or unkind. this only invites those who agree with you and completely fails to acknowledge differences.
• arguments aren't worth it either - not hacker news or anywhere else. writing defensively doesn't provide a lot of value to you, as it tends only to sell you on what you're already convinced of.
• getting stuck is hard - how to you make it through?

zig thoughts!

Rust vs Zig https://www.scattered-thoughts.net/writing/assorted-thoughts-on-zig-and-rust/

• zig is far simpler than rust! rust blasts you with language features that you'll take a significant time to understand. it's hard to design something in your head and resolve it completely, as it's difficult to understand how all of the different systems interact - it often feels like fighting the system rather than anything else.
• zig gets all of the mechanisms that rust has with `comptime`; macros and all, it can just execute the same runtime code at compile time so things are far easier to reason about.
• zig only proves type safety for things provided to the function, not every possible value; this means that systems leveraging zig generics can't be typechecked effectively, and it doesn't have access to any of the automatic, machine checked type constraints.
• CWE - CWE-1350: Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Wea… - come back to this! what often causes the most problems? looks like zig resolves most of the issues.
• zig uses far simpler abstractions for things like import. so much easier to include and use things!
• much lower cognitive overhead - more likely to receive very fast feedback loops. does not have detection for UAF, but it isn't super clear whether this is the best choice!
• shoutout to nanoprocesses: https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/: allowing things to run in sandboxed threads - brilliant!

testing

testing https://www.scattered-thoughts.net/writing/testing/

• debugging efficiency is super important
• make sure to test things directly rather tham implicitly - don't knock the unit tests because integration tests often don't directly give you the information you need when revisiting and debugging!
• marking tests as known failures is super valuable too - should not cause the test suite to fail, but should serve as history - what do you still have to fix? finding a bug you can't fix immediately: add as a failing test and link to the issue; if the bug is fixed later, the test suite then fails!
  • Joss: This pattern is valuable and it strikes me as a huge workaround to stay compatible with current systems. figure out a better way to handle it!
    • add some sort of todo list system to track what still has to be done with your programming; somehow automatically associate it with specific functions. you're just working with a graph1
    • in addition to the manual unit test form
  • testing nondeterminism: eat the pain at design time to make sure this can't occur; fixing the seed often isn't okay.
  • structured input from property based testing: https://hypothesis.works/articles/how-hypothesis-works/ look into this!
  • implement two different ways to compute the same output and test that they always agree
  • performance: run benhcarks automatically, record in a database, show graph of results over time. then you can reflect and see the trend over time to determine when changes to the system caused major performance regressions!

speed

https://www.scattered-thoughts.net/writing/moving-faster/

• want to be faster. actually solve the problem; avoid using fashionable tools or writing "elegant" code. these are wasted of time. it's possible to be so much faster.
• "some people are producing projects taht are far beyond what i could do in a single lifetime. I wanted to figure out how to do that." always reflect on what took you so long and how it could have been approved.
• always make decisions based on explicit goals. this avoids decision paralysis - ultimate enemy
• list out pro cons, focus on the data structure that puts you closest to the goal - ofte this is the one that is easiest to implement, barring some huge language failure.
• put everything into one file. iterate on it until you start to work with groups of things more frequently. group those into files. easy!
• "what should i do next?" prioritize time saved or quality improved. whatever will give the most information about how to proceed!
• do not thrash between two options.
• it's okay to write messy code. that leads to thrashing back and forth between things, or building things that are technically impressive but not at all important. often these abstractions have to be redone later when the requirements change.
• blocks of hours with no distractions. no multitasking. it's bad! you lose thinking context! addictive interactions encourage easier and more immediately rewarding behavior. don't do this - keep priorities straight.
• set alarms and delegate to these.
• avoid multitasking always. write down what you are doing, figure out how to do it, make the changes one by one, improve docs, then test. after that commit and merge the pr! make sure to have an explicit plan first though.
• make small changes. nothing should take more than a few hours. if it does, it's not a great change to make.
• much easier to jump in and out of things if everything is left working. don't leave things broken ever.
• it's never "just one more big push" - merge something that works.
• shorten feedback loops. how quickly can you evaluate the impact of decisions? create faster adn faster feedback loops.
• create a work journal. append only text file to log everything that's being done; what' done now, what has to be done in the future, and how we get from a to b.
• reduce mistakes. if a mistake is fixed, quickly review what exactly the mistake was, why it was made, and work through the code to fix the legacy code. if the change is too big to fix throughout, mark it as a todo and revisit it as something to deal with later.
• make low level skills - typing, editing code, thinking about code, etc. - automatic. do not let these things be points of resistance to you. identify these bottlenecks and identify what exactly is going wrong.
  • make notes of these inefficiencies, revisit then when you have time
  • explicit practice: what problems would you like to practice? how do you explicitly practice skills rather than implicitly working on things? drill donw on things.

speed matters

Speed matters

• being 10x faster changes the kinds of projects that are worth doing. be satisfied working with and on things that you've made yourself! that is such an important goal. something being 10x faster is absolutely worth developing the skillset for. if it's 10x slower, most htings you do now aren't even worth doing at all.
• how many ideas can yuou try out a year? how many attempts do you get? you need that feedback. more practice means more improvement, absolutely (if it's intentional).
• making more things is fun. how do you eke more performance out of yourself? how do you get better?
• zig is good

set goals

Setting goals

• measure progress - need some way of measuring how good you're doing! it's okay to have vague senses of things but they better be ironed out by the time you go to implement them - they should be consistent!
• goals shouldn't have drift. do things that you care about and you'll absolutely feel more motivated.

emotional management

https://www.scattered-thoughts.net/writing/emotional-management/

• exercise is a button you can push to reset mood!
• cancelling plans is procrastination black hole. work so so so hard to make those plans work. don't even consider having the option to cancel the plans - that's just you doubting yourself a day or two in advance.
• twitter is not easily educational. you're spending too much time on the bad stuff. community culture is bad and toxic; you may "internalize" the voice of anyone you spend time with anyways; this gets very bad when considering online spaces. contemplate what exactly you're spending time doing and who you're working with. stay with small communities that are focused on making things.
• derailing by distraction can be satisfying but is a sign you may be out of alignment with goals.
• Leave good evidence of yourself.

things unlearned

Things unlearned

• computing spreads much faster than education can.
• understand the most powerful languages so you can understand the differences in power between them. you can't understand what you don't know, and more powerful languages can lend you ideas to use in aft used circumstances.
• simple revolutions are only simple from a distance. most ideas have a huge number of almost identical ideas that don't work, with very very subtle reasons why.
• hopping from one superficial idea to another does not make progress on the fundamental problems, so those problems never end up even being solved.
• solve an appropriately sized subset of a problem, then adapt and expand to other solutions.
• don't spend much time looking for a bigger shovel. looking for tools is far too much of a waste of time. it's often just worth picking up something off the shelf that does most of the job well and working off of it.
• you need a baseline to compare things to - the mainstream tools - as they are the state of the art. always make sure you're familiar with the state of the art so that you know what to improve.
• languages are cool tools, but to make progress you need libraries. you need tools. you need ideas. knowing a language front to back is the only time in which it comes in handy - if you have incredibly fluency with a tool, it doesn't matter what problem you have to solve because the tool will solve it.
• OPPORTUNITY COST MATTERS MOST
• intelligence does not trump expertise.
• explore vs exploit - take the known payoff or go into the dark to gamble for a bigger one? exploiting is often a much better decision in most places because it lets you shortcut to solving more interesting problems.

new programming languages

gnu poke

___ —' \_____ ____) GNU poke __) Release notes for poke 1.0 __) —._______)

• GNU poke - Release notes for poke 1.0
  • interactive extensible editor for binary data
  • procedural language designed to interact wiht data structures!
  • super fun to use !! and the graphics are so cool! definitely revisit this when I pick up systems work I need to use to debug assembly, data in memory, etc.

lobster

https://strlen.com/lobster/

• optimized for games and graphical things

division of thoughts on kialo

https://www.kialo.com/