The truth is uglier: developers burn out because of the system around coding, not the coding itself.

1. Unclear priorities
2. Constant interruptions (lack of possible focus)
3. Politics
4. Context chaos

Protections: draw hard boundaries, make priorities visible, limit your context surface, build allies, document the cost, know when to walk

we’re going from running 177 Cassandra nodes to just 72 ScyllaDB nodes. Each ScyllaDB node has 9 TB of disk space, up from the average of 4 TB per Cassandra node.

They migrated away from CassandraDB to ScyllaDB with a rust-based data service

Ideas for creative projects. Lean and have fun.

“What I cannot create, I do not understand”

One ting to consider: KISS. The program can crash or panic for a lot of code path. Implement only the necessary!

The problem is annoying and difficult. Also secrets can be easy to rotate, can not rotate or ones that attackers use.

You could be doing so many good data security practices, like secure-by-design frameworks, database and field-level encryption, zero-touch production, access control… but logging bypasses all of that… and ultimately degrades trust, in your systems and in your company.

It happens to companies of all sizes: X, Google Cloud, Facebook

Causes:

1. Direct logging
2. Kitchen sinks: objects that contain or hold secrets, often in opaque or unexpected ways. Errors of requests are examples.
3. Configuration changes: turning logging level to debug.
4. Embedded secrets: a token shared by URL
5. Telemetry: error monitoring and analytics are logs. They often provide the local variable context.
6. User Input: the user provides wrong but PII data in a wrong field for example.

Fixes:

1. Data architecture:part of the solution is reducing the number of data flows and shrinking the problem space so you simply have less things to worry about and protect. One logging utility!
2. Data transformation: minimization, redaction, tokenization (and the trolls: hashing, encryption, masking)
3. Domain primitives: “combines secure constructs and value objects to define the smallest building block of a domain”. new Secret("..."). They provide security invariants and guarantees that basic string primitives simply cannot.
4. Compile-time: a logging function that never accepts secrets (TS branded types helps!)
5. Run-time classes (extends String): it identifies the secrets. Overwrite the toString() method in JS to return [redacted] but an explicit unwrap() method for example.
6. Read-once objects: they throw an error or [redacted] in case of second read.
7. Taint checking: the general idea here is that you add taint to various sources (like database objects), and yell loudly if the data flows into certain sinks (like logs). Demo: https://semgrep.dev/playground/s/4bq5L It's awesome and not awesome as the same time.
8. Log formatters: redact known dangerous property names
9. Unit tests
10. Sensitive data scanner
11. Sampling (every cases instead of proportions)
12. Log pre-processors such as Vector
13. People

Strategy:

1. Lay the foundation: Developing expectations, culture, and support is a must-have. Define what a secret is. Use structured logs to allow operations on them.
2. Understand the data flow: with the foundation laid, the next best thing to do is to understand and chart out how secrets flow through your system.
3. Protect at chokepoints: CI/CD and App code first, before relying on the loggging library and other operation services.
4. Apply defense-in-depth: data transformation, read-once objects, log formatters in the library, log pre-processors, sensitive scanners, people
5. Plan for response and recovery

(via https://sebsauvage.net/links/?LscYqg)

The method to build software feature by iteration is a mistake long-term.

Carrying over this approach past the learning phase was a mistake.

It is possible to dramatically cut the amount of bugs you introduce in the first place, if you focus on optimizing that (and not just the iteration time)

One super power is bugs can be found while reading the code.

The key is careful, slow reading. What you actually are doing is building the mental model of a program inside your head.

If you are reviewing a PR, don’t review just the diff, review the entire subsystem.

Follow the control flow or stare at the state

KISS for maintainability: "Nothing in Rust forces us to get fancy. You can write straightforward code in Rust just like in any other language. But in code reviews, I often see people trying to outsmart themselves and stumble over their own shoelaces. They use all the advanced features at their disposal without thinking much about maintainability."

Here an real life example.

But if simplicity is so obviously “better,” why isn’t it the norm? Because achieving simplicity is hard!

Even in Rust: abstractions are never zero cost for developers.

Often, simple code can be optimized by the compiler more easily and runs faster on CPUs. That’s because CPUs are optimized for basic data structures and predictable access patterns. And parallelizing work is also easier when that is the case. All of that works in our favor when our code is simple.

Most of the code you’ll write for companies will be application code, not library code. That’s because most companies don’t make money writing libraries, but business logic. There’s no need to get fancy here. Application code should be straightforward to keep your fellow developers in mind.

Tips:

• start small
• avoid optimization early
• delay refactoring: we have limited information at the time of writing our first prototype.
• write code for humans
• The right abstractions guide you to do the right thing

As a nuclear engineer, I have never been asked to show my portfolio of reactor designs I maintain in my free time, I have never been asked to derive the six-factor formula, the quantization of angular momentum, Brehmsstrahlung, or to whiteboard gas centrifuge isotopic separation, water hammer, hydrogen detonation, or cross-section resonance integrals.

There's something deeply wrong with an industry that presumes you're a fraud unless repeatedly and performatively demonstrated otherwise and treats the hiring process as a demented form of 80s-era fraternity hazing.

(via https://oldbytes.space/@arclight/115138550902542817)

The table is available as PDF https://dr-knz.net/programming-levels/prog-skill-matrix.pdf

Computer architectures encompass 13 orders of magnitude of performance! That’s roughly the difference between something like a trivial function call processing data in L1 cache to a remote call out to something in another region. People often make relatively “small” mistakes of 3 or 4 orders of magnitude, which is still crazy if you think about it, but that’s considered to be a minor sin relative to making the architecture diagram look pretty.

It's easy to accidentally perform expensive operations in software systems.

If we can delete a single unnecessary 109109 operation, that pays for a lot of unnecessary 105105 order operations.

Optimize for the higher order of magnitude.

Take a moment and think; what does everybody needs here?
What are the things this team struggle with?
How can I write up a doc, show what is wrong and propose a solution?

while they do a good job of teaching people how to program in the bare sense of the term, they don't really have a good grasp of how to go from writing code to building something useful for them or other people.

The reason we get muddled, I think, is that those of us who are practising engineers don't often quite get what we're teaching when we teach people how to write code

Code literacy means being able to map symbols to the things that the symbols represent in the same way as you do in any language, being able to understand how those symbols relate to each other to convey meaning and being able to do this in a fluid, intuitive way. It's the ability to read a piece of code in the same way that you would an essay, understand what it's doing and the thrust of what it communicates, both to you and to the computer.

The second part of seeing the world through an engineer's eyes is teaching people how to analyse and break down a problem so that it can be solved with software.

Finally, you have the ability to understand what a computer-type device might be doing day-to-day.

Also the ethics of care behind it.

So the author proposes HTML as a teaching tool, because HTML websites are great. Using CSS classes and ids are similar to references. Importing stylesheets is like importing modules. It has to be carefully thought about the design, and because deploying a website is relatively easy: You have to ship something from the start

Software engineers tend to be detached, demotivated and unwilling to care much about the work they're doing beyond their paycheck

We need to show them what the things we work with can do, we need to show them how they can use our tools to make the world better, and we need to give them a reason to care about what we do. And perhaps that could start with some personal websites.

What are developer's blocks?

All these practices (documentation, tests, CI) are valuable, but sometimes they just mount up until you’re blocked.

Either you are new to the project and you just feel overwhelmed or you’ve been working on the project for a while, but you run out of stream and get stuck. it may be due to overwork or a lack of motivation.

How to unblock?

1. Take time with learning. Sometimes, the docs or tests need to be read to get an idea of the externals. Eventually looking at the source code and building up a mental model of how it fall fits together. "If you think education is expensive, try ignorance"
2. Realise when you're tired
3. Work incrementally: implement it with the minimum effort. Circle back round to improve the tests, docs, etc...
4. Write a prototype: Concern yourself only with the happy path. If you’re trying to learn about a dependency, it’s sometimes easier to write a quick prototype of using the dependency, possibly in an empty repository.
5. Start with draft documentation: avoid premature docs polishing. Capture why you did things a particular way. Provide basic usage instructions.
6. Release early, release often

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can't trust the opinions of the others, because of the Blub paradox: they're satisfied with whatever language they happen to use, because it dictates the way they think about programs.

The source code of the Viaweb editor was probably about 20-25% macros.

Computer hardware changes so much faster than personal habits that programming practice is usually ten to twenty years behind the processor. At places like MIT they were writing programs in high-level languages in the early 1960s, but many companies continued to write code in machine language well into the 1980s.

The ideas of a grug developer.

How to do X in the browser dev tools.

• think about naming
• don't be afraid to say "no"
• code review is communication
• use multiple iterations of reviews
• don’t be a jerk
• try to run the code
• an opportunity to learn things
• avoid nitpicking
• ask stupid questions
• ask for feedback on the review style

I used to be on a team that was responsible for the care and feeding of a great many Linux boxes which together constituted the "web tier" for a giant social network.

At some point, I realized that if I wrote a wiki page and documented the things that we were willing to support, I could wait about six months and then it would be like it had always been there. Enough people went through the revolving doors of that place such that six months' worth of employee turnover was sufficient to make it look like a whole other company. All I had to do was write it, wait a bit, then start citing it when needed.

One near-quote from that page did escape into the outside world. It has to do with the "non-compliant host" actions: "Note: any of these many happen without prior notification to experiment owners in the interest of keeping the site healthy. Drain first, investigate second."

So the author created a list of actions; methods to apply for any given events.