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
- stream of consciousness
- the structured data with some organization; determine what parts
of the structure are difficult to articulate, then iterate on them
- 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/