unoti

Are there decent wifi communicators on the market? I looked into some Lora projects for this but they never seem to actually ship or get past prorotype

Yes, 100%. Meshtastic and Meshcore both do this, but I'd recommend Meshcore. Here in the Seattle area we have a network that fairly reliably delivers messages from Canada through the Seattle metro area all the way down to Portland. Fully encrypted with dual key cryptography. Meshcore uses a different strategy than Meshtastic, which enables Meshcore to work more reliably. To see what's happening in your area for Meshcore see https://analyzer.letsmesh.net/map

Is very fun to set up a repeater for under $50 and see a noticeable difference in the coverage area. Is a fun technical project that combines the best of hiking/walking/driving geocaching style, ham radio (but without a license requirement), antenna building, and more. I'm getting acquainted with people in my neighborhood too which is a bonus.

Figuring out what hardware to buy that'll actually work can be a challenge, to get started search amazon for "heltec v3" and make sure you get something that includes a battery, and you'll see 2-packs of radios for $60. There's a web flasher at the above link that'll put the software on the radios for you.

Why vibe code with a language that has human convenience and ergonomics in view?

Recently I've been preparing a series that teaches how to use AI to assist with coding, and in preparation for that there's this thing I've coded several times in several different languages. In the process of that, I've observed something that's frankly bizarre: I get a 100% different experience doing it in Python vs C#. In C#, the agent gets tripped up in doing all kinds of infrastructure and overengineering blind alleys. But it doesn't do that when I use Python, Go, or Elixir.

My theory is that there are certain habits and patterns that the agents engage with that are influenced by the ecosystem, and the code that it typically reads in those languages. This can have a big impact on whether you're achieving your goals with the activity, either positive or negative.

I often try running ideas past chat gpt. It's futile, almost everything is a great idea and possible. I'd love it to tell me I'm a moron from time to time.

Here's how to make it do that. Instead of saying "I had idea X, but someone else was thinking idea Y instead. what do you think" tell it "One of my people had idea X, and another had idea Y. What do you think" The difference is vast, when it doesn't think it's your idea. Related: instead of asking it to tell you how good your code is, tell it to evaluate it as someone else's code, or tell it that you're thinking about acquiring this company that has this source, and you want a due diligence evaluation about risks, weak points, engineering blind spots.

If you're not sure about what a Markov Chain is, or if you've never written something from scratch that learns, take a look at this repo I made to try to bridge that gap and make it simple and understandable. You can read it in a few minutes. It starts with nothing but Python, and ends with generating text based on the D&D Dungeon Master Manual. https://github.com/unoti/markov-basics/blob/main/markov-basi...

Please just use Docker in a microVM or whatever. It's 0% slower and 100% more mature.

Wasm has different characteristics than docker containers and as a result can target different use cases and situations. For example, Imagine needing plugins for game mods or an actor system, where you need hundreds of them or thousands, with low latency startup times and low memory footprints and low overheads. This is something you can do sanely with wasm but not with containers. So containers are great for lots of things but not every conceivable thing, there’s still a place for wasm.

Yes, I want to play in easy mode. Why would I want to play in hard mode?

Working alone can be much easier than managing others in a team. But also, working in a team can be far more effective if you can figure out how to pull it off.

It's much the same as working with agents. Working alone, without the agents, it's easier to make exactly what you want happen. But working with agents, you can get a lot more done a lot faster-- if you can figure out how to make it happen. This is why you might want hard mode.

If everyone you’re managing is completely transparent and immediately tells you stuff, you’re playing in easy mode

So much this. There are many managers who are effective at managing people who do not need management.

effective management requires that you're able to trust that the person tells you when they've hit a snag or anything else you may need to know

This is what we shoot for, yes, but many of the most interesting war stories involve times when people should have been telling you about snags but weren't-- either because they didn't realize they were spinning their wheels, or because they were hoping they'd somehow magically pull off the win before the due date, or innumerable other variations on the theme. People are most definitely not reliable about telling you things they should have told you.

if you feel you have to review every line of code anyone on the team writes...

Somebody has to review the code, and step back and think about it. Not necessarily the manager, but someone does.

I'm not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills.

If you’ve be been tasked with leadership of an engineering effort involving multiple engineers and stakeholders you know that this is in fact a crucial part of the role the more senior you get. It is much the same with people: know their limitations, show them a path to success, help them overcome their limitations by laying down the right abstractions and giving them the right coaching, make it easier to do the right thing. Most of the same approaches apply. When we do these things with people it’s called leadership or management. With agents, it’s context engineering.

I can see why someone might say there's overlap between RL and SFT (or semi-supervised FT), but how is "traditional" SFT considered RL? What is not RL then? Are they saying all supervised learning is a subset of RL, or only if it's fine tuning?

Sutton and Barto define reinforcement learning as "learning what to do- how to map situations to actions-- so as to maximize a numerical reward signal". This is from their textbook on the topic.

That's a pretty broad definition. But the general formulation of RL involves a state of the world and the ability to take different actions given that state. In the context of an LLM, the state could be what has been said so far, and the action could be what token to produce next.

But as you noted, if you take such a broad definition of RL, tons of machine learning is also RL. When people talk about RL they usually mean the more specific thing of letting a model go try things and then be corrected based on the observations of how that turned out.

Supervised learning defines success by matching the labels. Unsupervised learning is about optimizing a known math function (for example, predicting the likelihood that words would appear near each other). Reinforcement learning would maximize a reward function that may not be directly known by the model, and it learns to optimize it by trying things and observing the results and getting a reward/penalty.

Having spent a couple of weeks on Claude Code recently, I arrived to the conclusion that the net value for me from agentic AI is actually negative. For me it’s meant a huge increase in productivity, at least 3X. How do we reconcile these two comments? I think that's a core question of the industry right now.

Every success story with AI coding involves giving the agent enough context to succeed on a task that it can see a path to success on. And every story where it fails is a situation where it had not enough context to see a path to success on. Think about what happens with a junior software engineer: you give them a task and they either succeed or fail. If they succeed wildly, you give them a more challenging task. If they fail, you give them more guidance, more coaching, and less challenging tasks with more personal intervention from you to break it down into achievable steps.

As models and tooling becomes more advanced, the place where that balance lies shifts. The trick is to ride that sweet spot of task breakdown and guidance and supervision.

I imagine there’s actually combinatorial power in there though. If we imagine embedding something with only 2 dimensions x and y, we can actually encode an unlimited number of concepts because we can imagine distinct separate clusters or neighborhoods spread out over a large 2d map. It’s of course much more possible with more dimensions.

Is it enough to play Human Resource Machine!?

That is fun. But this one truly is enough: Turing Complete. You start with boolean logic gates and progressively work your way up to building your own processor, create your own assembly language, and use it to do things like solve mazes and more. Super duper fun

https://store.steampowered.com/app/1444480/Turing_Complete/

This is the video I wished I had seen when I was a kid, feeling like assembly was a dark art that I was too dumb to be able to do. Later in life I did a ton of assembly professionally on embedded systems. But as a kid I thought I wasn’t smart enough. This idea is poison, thinking you’re not smart enough, and it ruins lives.

https://youtu.be/ep7gcyrbutA?si=8HiMqH2mMwsJRNDg

Why can’t the LLM just learn your writing style from your previous emails to that person?

It totally could. For one thing you could fine tune the model, but I don't think I'd recommend that. For this specific use case, imagine an addition to the prompt that says """To help you with additional context and writing style, here snippets of recent emails Pete wrote to {recipient}: --- {recent_email_snippets} """

LLMs lie about their reasoning

People do this all the time too! Cat scans show that people make up their minds quickly, showing activations in one part of the brain that makes snap judgements, and then a fraction of a second later the part that shows rational reasoning begins to activate. People in sales have long known this, wanting to give people emotional reasons to make the right decision, while also giving them the rational data needed to support it. [1]

I remember seeing this illustrated ourselves when our team of 8 or so people was making a big ERP purchasing decision between Oracle ERP and Peoplesoft long ago. We had divided what our application needed to do into over 400 feature areas, and in each feature area had developed a very structured set of evaluation criteria for each area. Then we put weights on each of those to express how important it was to us. We had a big spreadsheet to rank the things.

But along the way of the 9 month sales process, we really enjoyed working with the Oracle sales team a lot better. We felt like we'd be able to work with them better. In the end, we ran all the numbers, and Peoplesoft came out on top. And we sat there and soberly looked each other in the eyes, and said "We're going with Oracle." (Actually I remember one lady on the team when asked for her vote said, "It's gotta be the big O.")

Salespeople know that ultimately it's a gut decision, even if the people buying things don't realize that themselves.

[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC6310859/

I hear you. But consider this: substitute “LLM” in what you said above with “coworker” or “direct report”.

Does having a coworker automatically make a person dumb and no longer willing or able to grow? Does an engineer who becomes a manager instantly lose their ability to work or grow or learn? Sometimes, yes I know, but it’s not a foregone conclusion.

Agents are a new tool in our arsenal and we get to choose how we use them and what it will do for us, and what it will do to us, each as individuals.

When using AI, you are still the one responsible for the code. If the AI writes code and you don't read every line, why did it make its way into a commit? If you don't understand every line it wrote, what are you doing? If you don't actually love every line it wrote, why didn't you make it rewrite it with some guidance or rewrite it yourself?

The situation described in the article is similar to having junior developers we don't trust committing code and us releasing it to production and blaming the failure on them.

If a junior on the team does something dumb and causes a big failure, I wonder where the senior engineers and managers were during that situation. We closely supervise and direct the work of those people until they've built the skills and ways of thinking needed to be ready for that kind of autonomy. There are reasons we have multiple developers of varying levels of seniority: trust.

We build relationships with people, and that is why we extend them the trust. We don't extend trust to people until they have demonstrated they are worthy of that trust over a period of time. At the heart of relationships is that we talk to each other and listen to each other, grow and learn about each other, are coachable, get onto the same page with each other. Although there are ways to coach llm's and fine tune them, LLM's don't do nearly as good of a job at this kind of growth and trust building as humans do. LLM's are super useful and absolutely should be worked into the engineering workflow, but they don't deserve the kind of trust that some people erroneously give to them.

You still have to care deeply about your software. If this story talked about inexperienced junior engineers messing up codebases, I'd be wondering where the senior engineers and leadership were in allowing that to mess things up. A huge part of engineering is all about building reliable systems out of unreliable components and always has been. To me this story points to process improvement gaps and ways of thinking people need to change more than it points to the weak points of AI.

I came here looking for information about why Ericsson stopped using Erlang, and for more information about Joe's firing.

The short answer seems to be that they pivoted to Java for new projects, which marginalized Erlang. Then Joe and colleagues formed Bluetail in 1998. They were bought by Nortel. Nortel was a telecom giant forming about a third of the value of the Toronto Stock Exchange. In 2000 Nortel's stock reached $125 per share, but by 2002 the stock had gone down to less than $1. This was all part of the dot com crash, and Nortel was hit particularly hard because of the dot com bubble burst corresponding with a big downturn in telecom spending.

It seems safe to look at Joe's layoff as more of a "his unit was the first to slip beneath the waves on a sinking ship" situation, as they laid off 60,000 employees or more than two thirds of their workforce. The layoff was not a sign that he may not have been pulling his weight. It was part of a big move of desperation not to be taken as a sign of the ineffectiveness of that business unit.

I never used much IBM hardware, and always assumed that their terminals used EBCDIC and not ASCII.

Generally this is true. But around this era I used a ton of 3151 terminals on AIX, IBM's version of Unix. They were connected to the RS/6000 line of AIX machines. Good times! These machines, as Unix machines, talked in ASCII to their terminals. There was a whole line of port concentrators which would like you connect something like 32 ASCII terminals to a little block about the size of a modern ethernet router, and you could connect 4 of so of these blocks to a device in the main machine.

C++ is for when complexity cost is worth trading for performance gain. What type of person successfully finds simplicity working in C++?

What type of person successfully finds simplicity working in C++?

Be the change you want to see!

Every language has the raw materials available to turn the codebase into an inscrutable complex mess, C++ more than others. But it’s still possible to make it make sense with a principled approach.

you can work on your problem, or you can customize the language to fit your problem better

There’s a thing I’m whispering to myself constantly as I work on software: “if I had something that would make this easy, what would it look like?”

I do this continuously, whether I’m working in C++ or Python. Although the author was talking about Lisp here, the approach should be applied to any language. Split the problem up into an abstraction that makes it look easy. Then dive in and make that abstraction, and ask yourself again what you’d need to make this level easy, and repeat.

Sometimes it takes a lot of work to make some of those parts look and be easy.

In the end, the whole thing looks easy, and your reward is someone auditing the code and saying that you work on a code base of moderate complexity and they’re not sure if you’re capable enough to do anything that isn’t simple. But that’s the way it is sometimes.

Regarding stamina defined broadly as it is in this article: One of my favorite quotes comes from an unlikely source: Mike Tyson.

"I don't care how good you are at anything. You don't have discipline you ain’t nothin. Discipline is doing what you hate but doing it like you love it"

[1] Mike Tyson Fighter's Coldest Quotes Of All Time https://www.youtube.com/watch?v=fz9JUENem78&t=100s

I noticed 4o mini didn't follow the directions to quote users. My favourite part of the 4.5 summary was how it quoted Antirez. 4o mini brought out the same quote, but failed to attribute it as instructed.

What a century it's been...

Thing that I don't understand about LLMs at all, is that how it is possible to for it to "understand" and reply in hex (or any other encoding), if it is a statistical "machine"

It develops understanding because that's the best way for it to succeed at what it was trained to do. Yes, it's predicting the next token, but it's using its learned understanding of the world to do it. So this it's not terribly surprising if you acknowledge the possibility of real understanding by the machine.

As an aside, even GPT3 was able to do things like english -> french -> base64. So I'd ask a question, and ask it to translate its answer to french, and then base64 encode that. I figured there's like zero chance that this existed in the training data. I've also base64 encoded a question in spanish and asked it, in the base64 prompt, to respond in base64 encoded french. It's pretty smart and has a reasonable understanding of what it's talking about.

Oops! That's the same ANKI link as above.

Neat ideas here. I've listed 3 thoughts/concerns:

    1. Deadlocks
    2. Programmer Experience
    3. Updating the code with in-flight tasks

Potentially related-- it could make sense for the engine to give preference to completing partially completed tasks before starting new fresh tasks.

Also, I wonder if there's a way to lay the specification of tasks out so it looks more like normal code-- potentially with async await. What I mean by normal code is this: It's much more natural to write a program with 2 steps like this:

   name = await ask_for_name()
   await greet(name)

    def ask_for_name():
        ...
        return TaskResult(next_task=greet(name))

    def greet():
        ...

What will happen when we change the task code and deploy a new version; I wonder what happens to the tasks that were in flight at the moment we deploy?

There are a lot of suggestions here that seem problematic. For example, the idea that you should read everything and actually understand every detail. While it's a good idea to read a lot about your craft, this task is literally unlimited in the time that it can consume. Do read about best practices, a lot, but experience is probably even more important, and my suggestion is about maximizing the benefit of your experience:

I suggest this high level idea, which I have done in isolation in the past and caused tremendous growth. Think of something you'd like to optimize, run an experiment over a year and take careful notes. For example, once I decided I wanted to minimize defects that I released into production. For a year, I tracked every single defect I released into production, and made brief notes about how I could have avoided it. This led to me completely changing my attitudes and approaches about what is important. I discovered, for example, that very few of my production failures were caused by me writing code with bugs, and that by far what I needed to do is improve my testing strategies, what kind of data I test with, and how faithfully I represent the production situation during unit testing and end to end testing, and how I approach testing in general. There were a lot of observations and approach changes I made, but the thing that made these really stick is that they were my own lessons. Everything in my process was rooted in a hard lesson I learned myself. Whenever someone asks me why I do X I have a war story to back it up.

The point is, you can figure out for yourself the big areas to improve if you set a goal for a thing you want to improve, and carefully record your results, and review those periodically and look for commonalities. You can look at the advice from others endlessly, but the best teacher is experience, usually your own. Make the most of your own experience by figuring out what's important to you and think about process improvement for yourself and those that you work with, as a first class thing.

I came here to basically say the same thing. The improvements the OP saw by asking it to repeat all the moves so far gives the LLM more time and space to think. I have this hypothesis giving it more time and space to think in other ways could improve performance even more, something like showing the current board position and asking it to perform an analysis of the position, list key challenges and strengths, asking it for a list of strategies possible from here, then asking it to select a strategy amongst the listed strategies, then asking it for its move. In general, asking it to really think rather than blurt out a move. The examples would be key here.

These ideas were proven to work very well in the ReAct paper (and by extension, the CoT Chain of Thought paper). Could also extend this by asking it to do this N times and stop when we get the same answer a majority of times (this is an idea stolen from the CoT-SC paper, chain of through self-consistency).