jb3689

I like this as reference. I haven't seen a design doc properly used for implementation in a long time. More often design docs are there to facilitate collaboration - here's the basis of conversation topics that are interesting; these are the things that matter most and here's the foundation for discussion so we can get aligned. It's all too easy for a team to ignore or TL;DR a design doc which goes on and on about things that don't matter, and that can become a problem for an architect trying to implementation which winds up going off the rails because no one actually read the doc.

“Don’t believe everything you read on the internet” seems like the golden rule we’ve all forgotten

"Do the work assigned to them" has multiple levels of abstraction. You could say it's the task level which would be entry level. You could say it's the project level which would be mid level. You could say it's the a service or domain which would be senior. Staff should be tackling org wide and cross-team issues. The amount of scope and clarity needed for a "problem" changes and gets larger in expectation and more terse in explanation the further you go.

Do people have fun building vim macros? Vim macros are awesome because they don't involve reading manuals, memorizing obtuse key commands which you never use on a regular basis, or understanding weird configuration lines - you just use the editor the way you normally would except you're hitting record. Vim's power is that I can be editing, notice I don't have something, make it in 2 minutes, and then get back to more normal work. At least try to understand the thing first before criticizing it?

Running tests is a good example: do you want to run them from your IDE or do you want to run tests in the terminal?

The IDE folks praise the simplicity of having one tool which can run tests quickly without requiring added context and with having other IDE features able to load test context quickly.

The terminal folks praise the modularity, at-will configuration, and transparency. You do things the way the rest of the community does which makes it easier to get support and debug when things go wrong. Tests become a small tool you can reuse in other contexts (git bisect, watch commands, CI)

Sometimes I feel like the only sane person in the room for not wanting to have to usher the LLM through phase by phase. Every time I need to choose the next skill or cat the next error is just a waste of my time that could be spent doing things that actually need my attention like making business tradeoffs.

Yeah, this is how it factually does work, but it’s not great. That’s why so many people are having to build custom tools to fill the gaps

You have a deadline and scope (of solution) handed to you from product/management. It’s the same issue now at work.

I’ve found LLMs very good at two things: 1. Recommending paths forward, 2. Following established architecture. Your job is to be able to treat the LLM and code as sheep

Why would you do anything else? It’s still faster than me doing it as long as I’m parallelizing. I can regularly get up to 5-6 things running in parallel at the moment with no downtime. I suspect by EOY I’ll figure out how to run more

$400 * 23 business days would be $9k. Sounds ballpark to me

A good interviewer won’t be looking for a single solution to the problem. I’d expect them to entertain the Google Sheets answer - it’s good signal that the candidate will consider what already exists in the world. I’d rather extend the problem: the team is spending considerable time iterating with manual entry, what would you do?

Distributed systems and probabilistic data structures really should be in every undergrad CS curriculum even if just in passing for the second

It irks me that these "just use Postgres" posts only talk about feature sets with no discussion about operations, reliability, real scaling, or even just guard rails and opinions to deter you from making bad design decisions. The author writes about how three nine's is multiplied over several dependencies, but that's not how this shakes out in practice. Your relational database is typically far more vulnerable than distributed alternatives. "Just use Postgres" is fine advice but gets used as a crutch by companies who wind up building everything in-house for no good reason.

The problem is that a lot of what is happening is within the executive branch's power and/or democratic. A nontrivial number of Americans support everything that has been happening. The expectation at a time like this would be that you have checks and balances working, but all other branches have yielded their power. I find that jaw dropping personally, but it's where we are. Midterms are happening soon and are the right place to disrupt congress.

On the other hand, no one cares about Velcro or Tupperware