For sure. The literal first two pages of any book, essentially the back of the cover and the title page, always host a huge list of pages plus summary of something interesting i saw in the book. For instance, it will say something like:
* p85, interesting semaphore usage
or some such. This also condenses the books to important things so I can do a speed read to recall the most important parts.
For Oauth I'd like to borrow what I would describe humbly as a better analogy, and it comes from Douglas Crockford, and so adapting it from him commenting on Monads in Functional Programming, it goes something like this:
"OAuth is a simple idea, but with a curse: once you understand it, you lose the ability to explain it."
Chomsky never argued it was words (and how couldn't it be words, for there are millions of words from 100s of 1000s of languages), just a configuration to eventually learn those words.
I am not sure if this will help you, but have an extended, deep conversation with ChatGPT about your resume. Tell it who you are, what you excel at, and list projects and technologies. Then, paste a couple of the job postings that did not work for you.
This might sound silly to you, but it absolutely works, because it will distill your experience better, ask you to re-arrange and generalize, and more importantly, it is far superior to us in finding unique key word combinations that work.
the user who wants it? and a premature retort: if the feedback is "the user / PM / stakeholder could be wrong", then... that's where we are. A "refiner" LLM can be fronted (Replit is playing with this for instance).
To be clear: this is not something I do currently, but my point is that one needs to detach from how _we_ engineers do this for a more accurate evaluation of whether these things truly do not work.
I am not so sure. Code by one LLM can be reviewed by another. Puppeteer like solutions will exist pretty soon. "Given this change, can you confirm this spec".
Even better, this can carry on for a few iterations. And both LLMs can be:
1. Budgeted ("don't exceed X amount")
2. Improved (another LLM can improve their prompts)
and so on. I think we are fixating on how _we_ do things, not how this new world will do their _own_ thing. That to me is the real danger.
I get the concern, however. But, short of nuking the actual .git directory, the upsides are worth it, in my opinion. Cursor offers filtering via a mini-prompt in its YOLO mode, so does Windsurf. The idea is killer, it allows it to progressively build and also correct its own errors. e.g. Cursorrules can be told to run tests after a feature is generated, or typecheck, or some other automated feedback-loop your codebase offers. That's pretty neat!
Better yet, setup a dev container first. Then, at most, your local DB is the only concern. If still paranoid (as you should be), suspend your network while the agent is working. :D
- Everything public in Slack. Create a fun-sounding moto that discourages DMs. Even if a DM happens, and the back and forth resulted in a consensus, share that consensus in a public channel (which makes it searchable).
- Record your team meetings, preferably with software that can AI-summarize. Folks on vacation / leave can get the rundown easily.
- Encourage the sharing of solutions to various problems (technical or otherwise) in Slack. If a developer is stuck, and someone helped them in a huddle or a pairing app, share the solution afterwards (again, makes it searchable). Discourage the over-sharing of screenshots (of your application and other things). Again, not searchable. If one must be shared, describe it. For instance, many devs share a picture of a stack-trace. Not super helpful for others. Grab the text and dump it to Slack.
- Have a good pairing software setup, unblocks for when Slack back and forth is too tedious. I like Tuple (tuple.app).
- Connect your issue tracker to Slack, if you use one, makes creating issues easy. Linear does this well.
- If feasible, have your team meet in person, cadence up to you, but at least once. Meeting the people in real life humanizes them more. I know it sounds silly to say, but it's very true in my experience. Your people will seem even lovelier.
I like this analogy a lot. It's possible that forced externalization of thoughts accidentally causes the omission of crucial data. That is, much more goes on in your head, you probably laid out the whole algorithm, but being asked to state it on the spot and in clear, serial words is causing you to bork it by taking shortcuts.
Hm, I thought Happy Eyeballs (HE) was mainly concerned with IPv6 issues and falling back to IPV4. I didn't think it was this RFC in which finally some words were said about round-robin specifically, but it looks like it was (from this article).
Is it true then that before HE, most round-robin implementations simply cycled and no one considered latency? That's a very surprising finding.
To be inspired by something really has no bearing on how the _inspired_ thing is built. I think you place much emphasis on that but really it does not bring much to the argument. One can say that a plane was inspired by a bird (and it is, since we wouldn't to build one if we didn't see birds flying), but a plane is not designed like a bird.
I also somewhat contest that "interesting behavior comes from the emergent runtime interaction of tons of tiny components". There can be very tight, hierarchical structures to programs designed in the way Alan Kay talks about. He is promoting clear, manageable interactions, not emergent unpredictability, which is something I am sure you came across (we all did), but I would not go so far as describe the whole model of Kay as "fundamentally misguided". He talks of "clear fences", which can be understood to refer to things like "actor-based" models, with controlled, clear messages, as done in languages such as Erlang.
> open source stuff with long history of maintenance and improvement
improvement and maintenance is continent on usage, and having been used at Netflix, this project is in a better place to have already faced whatever bug you are worried about (and let's be real, 99% of applications wont ever get the luck to exercise code paths sophisticated enough to find bugs Netflix has not found already).
You might be unnecessarily projecting here. You don't have evidence to support that open sourcing this might have been for any other reason than it is simply good for the community to have.
The same reason Babbage never built the full Difference Engine. Design of this sort allows some tinkering unbothered by the constraints of actually building it (if you know history of the Difference Engine you know how many ideas it unleashed even if never really built to completion except in recent times for display at a London Museum :p).
newspeak is for dramatic (and dare I say, rather fun) effect. I think his point is straightforward and not confused: one style and one liner for the entire programming language prohibits personal expression of style. A linter to enforce your own personal / team styles is a good idea. I don't see the confusion. You might disagree with one or both, but to me it seems logically consistent with the premise of the article which is that personal style is important in programming.
Programmer at Vendr in Boston. Previously, Grubhub, https://pace.car in Germany, startups in Brazil and Morocco.
Get in touch via wael . khobalatte @ Google's famous email service.