Programming

CodeCrafters projects are nice. bun is a well designed project I use for inspiration (although it's in Zig). Love the way everything is commented out and the focus on performance.

Most useful thing to know when trying to solve problems especially related to programming is to stop thinking about shortcuts and abstractions early. Do the simplest thing that solves the problem. Then make pretty (add docs, nice designs, ..). Then make fast.

Weathering Software Winter is inspiring talk in building things for yourself.

My current stack for writing software is described here.

I have repo test, I use for code I want to just test execution of or share with others. It serves as nice way to share code snippets with others, way to try new libraries/frameworks or learn. It's mostly write only kind of repo with focus on ideas exploration.

Notes

How to write fast code: reduce memory access. All of these tips stem from that: 1. Reduce the size of your data structures so more can fit in CPU cache. 2. Replace strings with numbers. 3. Make use of bit flags. Don’t waste space on booleans. 4. Access memory linearly. 5. Make judicious use of the heap. Inline the most commonly accessed values, move large or less common ones to the heap. 6. Model data like a database. Normalize commonly used structures and pass ids rather than copying them around. 7. Consider using a struct of arrays rather than an array of structs. For example, if you have two types of value, store them in separate arrays instead of a single one with a type field. This reduces memory usage and makes iterating by type linear.
In software engineering there are two things you are trying to get right:
- Software Validation - Did we build the right thing?
- Software Verification - Did we build the thing right?
Software simplicity is a prerequisite to reliability.
A small, simple API is usually also a hallmark of a well-understood problem.
Run/Right/Fast.
- Make the code work I write is working. Then I can make it fast (if necessary). Solving the “correct/clean/performant code” problem all at once can be overwhelming. Don’t be overwhelmed. Solve one at a time.
Reducing the maintenance burden is, for most codebases, the biggest optimization I can do.
- Of course it's all about striking a balance, but 99% of the time there is a choice between performance and readability, readability is the right answer. Performance should only be chosen if it is absolutely necessary.
If I write ugly code, anyone who intends to fix a bug or add a feature will not enjoy his work and likely avoid it next time.
Explicit over implicit is almost always better.
One of my principles is to always strive for simplicity when creating. In retrospect, I've learned many thing that I previously thought too complex to understand. The complexities tend to dissolve when you realize they are mostly just extra distractions emerging from the pressures of engineering the thing... distractions that you probably find yourself inventing all over again once you've assimilated the core idea.
Readme driven development is pretty neat. Write the README first as a specification. Then write the code for it. Zeit do it often.
We are about to study the idea of a computational process. Computational processes are abstract beings that inhabit computers. As they evolve, processes manipulate other abstract things called data. The evolution of a process is directed by a pattern of rules called a program. People create programs to direct processes.
Always be looking for patterns. Abstract them always and only when it simplifies.
Persevere in getting an abstraction just right. When you find it, everything will magically fall into place.
The implementation is the design.
Hide whatever the caller shouldn't care about. In particular, you can remove type parameters with appropriate quantification.
Declarative configuration means that you write down the desired state of the world in a configuration and then submit that configuration to a service that takes actions to ensure the desired state becomes the actual state.
Every single feature makes product more complex, makes testing more complex, puts constraints on UI design etc. Controlling feature creep (also by revisiting old features) is very important to keep project healthy. Larger the project, more important it is.
“Simplicity” often just means that a concept fits cleanly in the maker’s head at a particular point in time. How many times have I returned to a project I thought was simple only to find I had burdened it with spooky magic because I didn’t benefit from critical distance at the time? When was the last time I deemed another person’s work “too complex” because I couldn’t understand it in one sitting and wasn’t aware of the constraints they were operating under? Answers: too often and too recently.
If we take a look at any given line of code in a method, we can nearly always categorize it as serving one of the following roles: 1. Collecting input. 2. Performing work. 3. Delivering output. 4. Handling failures.
Code duplication is far cheaper than the wrong abstraction. When the abstraction is wrong, the fastest way forward is back.
Senior skills: Understanding requirements and knowing when to clarify. Building what's actually needed. Working with others including leadership. Working with customers when needed. Attention to detail. Knowing when to challenge others. Ownership. Innovation. Adaptability to change.
Write the comments first, then fill in the code.
If your variable names are good enough you need way fewer comments
The mindset that has helped me to improve my skills is that you should always just roll up your sleeves and look at the running process and its code rather than wasting more than 5 minutes searching for help or pouring over documentation that’s out of date and never correct. Put a short time cap on the time you spend doing that, and then just put on your explorer hat and pull out your scary toolkit to hunt that thing down.
Practices you can follow to get 10x results with programming
- Understand the business reasoning behind the project…look for ways of exploiting that knowledge to minimize the amount of work done.
- Less code is always easier to debug…or if you can’t debug, throw out and replace.
- Clearly defined project goals and constraints and milestones make development fast and visible.
- Throwaway prototypes are faster than big projects and teach you more–and may be good enough for the business.
- Understanding, deeply, the tools you use and the basic principles of computer science and engineering help you prune solution spaces a lot better.
- Identify whether or not the framework/third-party app is actually delivering value over just implementing a smaller bespoke solution yourself. Color picker? Almost certainly. Database extension? Probably. Container orchestration for a static blog? Probably not.
- Pseudocode and stepwise refinement of the solution to a problem. If you can’t explain something with bullet points, you don’t understand it, and if you don’t understand it, you’re slow.
Code style comments are tiny cuts to someone's confidence and you should weigh that vs the value of the "fixing" it..
My measure of codebase quality these days is almost entirely "how easy is it to change". So readability is key, and also making sure that changes have to touch as few places in the code as possible.
1. You're not clever. 2. Distributed systems rule #1: Do not distribute the system! 3. Do not micro optimize. 4. Measure where your program spends time. 5. Optimization rule #1: Reduce I/O. 6. Should I use a distributed cache? No!
Top 3 motivation killers for developers: Slow environments to test. Micromanagement. Continuous legacy projects.
Software should be: Robust. Reliable. Stable. Simple.
Read, analyze and write lots of code. Don't be too concerned with the latest fads.
When I update dependencies, I generally try to check each update to see what has changed. This is where using a lot of dependencies becomes expensive, because it takes more work to update them. I don’t really see this process bring automated, unless a web-of-trust like thing got popular. But I’m not holding my breath.
99% of what I do in a large codebase is find pre-existing examples, copy-paste structure, fill in the holes and clean up. That's it.
Don't comment bad code. Rewrite it.
Universal property of software is that it evolves. And since human beings (us, developers) make it evolve, we need to make sure that making evolve will be as easy as possible, and as little error-prone as possible of course.
The developers who seem to have all the answers? They aren’t smarter than you. They’ve just seen that before.
Why do programmers reach for step-based debugging when tracing (print-based debugging) is generally more useful?
Computers, networking, etc are just an agreed upon spec of which bytes in which location result in which action.
Mutation at a microscopic level is totally okay. What matters most is avoiding mutation at the macroscopic level, like when the app architecture has many important modules mutating or monkey patching each other.
My general rule is that mutating off screen is dangerous, not necessarily bad but a red flag. I’ve found if you have to scroll up/down or change file to find a reference to some variable then there is almost certainly an increased chance of fuckery.
An anti-pattern is just a pattern used in a sub-optmial context. A good practice is just a practice used in the right context. You shouldn't talk about patterns and practice being "good" or "bad" without talking about the context in which they will be used.
“Change only one thing at a time” should be codified into every software change control process. There should be no implicit changes, ever. Every single bit of config needs to be captured as code.
Code affects humans, not machines. Think through the consequences of design decisions. Tradeoffs are everywhere, document them. Taking on technical debt should be an informed decision, not the default. All resources are finite. Know your complexity bounds and impossibility results.
We should have "code walkthrough" meetings, where someone who knows an aspect of the codebase explains how it works to everyone else. No PRs reviewed, no decisions made, just knowledge transfer.
You should own your core competencies.
If you write software that shows errors to users (so, software) please, do everyone including yourself a favor and keep some way of figuring out the causal chain that drove a certain decision by your program.
Don’t build software systems “to last”: we humans are terrible at predicting what changes we’ll need to make in the future. Instead, develop expertise at replacing systems. You know for sure you’ll need to replace it, so replace often, you’ll get better at it!
Writing a program: 1. Analyze the problem. 2. Build the flow chart. 3. Code the instructions.
Better direction is to speed up applications by cutting most of the bullshit (JS/HTML) and move workload to the GPU. Seems like a much cleaner total complexity than go for thin client / fat server again.
Recommendation I give everybody starting up in tech is: read the source. No matter what, read code.
Function should have one goal. It’s okay for it to do more than a single thing (even without splitting) as long as any codepath taken through it achieves the same goal, and doesn’t do things unrelated to that goal.
In your comments, write what you did and why, record your level of petulance (REALLY) and the StackOverflow link that made you realize something
If you want to learn programming better, don't immediately go and search for solution. Try and solve problem yourself given what you know. Then search and compare solutions.
Errors compound. Composing 6 such parts into a bigger system results in a system that is broken 50% of the time. Neglecting the error path scales poorly.
Developers are drawn to complexity like moths to a flame, often with the same outcome.
Don't freak out about your code being too slow until you've actually measured it to see if it's a hot path.
When exploring ways to do things, think about what it will eventually look like at the call site. Then work backwards from there to work out how it should work.
Locality of Behavior is not about about separating different languages into different files. It is always about putting together things that need to change together -- i.e. modularization (D.L. Parnas, On the criteria to be used in decomposing systems)

Genomics

Immunology

Startups

AWS

Serverless computing

Build systems

Computer vision

Algorithms

Formal verification

Blockchain

Figma

Message queue

Remote Procedure Calls

Psychedelics

Lysergamides

Tryptamines

Renewable energy

CSS

Game development

Game engines

CPU

Nutrition

Drinks

2018

2019

2020

2021

2022

Alfred

Keyboard Maestro

Xcode

Neural networks

Linear algebra

Logic

Automated theorem proving

Mathematical optimization

Statistics

Type Theory

Diseases

Music production

GraphQL

Internet of things

Peer to peer

VPN

GitHub

Containers

Kubernetes

iOS

Linux

Nix

Electrical engineering

Quantum physics

Functional programming

Interactive computing

Software testing

Version control

C

Clojure

C++

Dart

Elixir

Elm

Go

Go libraries

Java

JavaScript

JS libraries

React

Julia

Kotlin

Lisp

Nim

Objective C

OCaml

Processing

Prolog

Python

Python libraries

R language

ReasonML