Software Engineering Radio - the podcast for professional software developers

Code Complete 2 [1] was one of the first coding books I've read. As with anything else, it's good to look around (HN is a good place) for people who have problems with the book. I think I learn as much reading the commentary people make about books like that as I do from the book itself.

I think I've listened to every podcast on software engineering radio a few times [2]. The older ones are especially nice because they usually pick a specific topic and cover the high points. I liked that I could listen to it while I was driving, or otherwise not in front of a computer.

It's specific, but Javascript: The Good Parts is probably the most used book I have on my shelf. It has such a perfect amount of usable information in it. It's pretty great. Again, it's definitely worth looking up critiques and counterpoints.

I've also got Introduction to Algorithms, which I use as a reference, sometimes. I switched over to The Algorithm Design Manual [5] after I saw it referenced in an older Steve Yegge post [6]. I read through the intro and it seemed like a book that would be more appropriate from an autodidactic standpoint. I really have no idea if that's going to pan out, since I'm not that far into it, but we'll see, for sure. Doesn't kill me to have an extra algorithms book laying about, though, and I've always got intro to algorithms for cross reference. I've found that I really need to have as many sources available as possible when I'm learning alone. Usually I don't get something until the fifth person describes it from the tenth different angle.

That's most of what I can think of off hand. I really enjoyed The Joy of Clojure [7], though haven't checked out the newer version. Programming Collective Intelligence [8] is a fun book, and is what made me want to go back down the maths route to get more into machine learning.

And of course habitually reading hacker news for an hour or three every night :)

So that's my totally inexpert list of random stuff that I enjoy

[1] http://www.amazon.com/Code-Complete-Practical-Handbook-Const... [2] http://www.se-radio.net/ [3] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... [4] http://www.amazon.com/Introduction-Algorithms-Thomas-H-Corme... [5] http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/... [6] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... [7] http://www.amazon.com/Joy-Clojure-Michael-Fogus/dp/161729141... [8] http://www.amazon.com/Programming-Collective-Intelligence-Bu...

I was a relatively early Tabnine user and suggested this time two years ago that people were “sleeping” on AI code completion. [1]

I read about and tried evaluating Kite at the time and it seemed like it was in some kind of private invite stage. I remember thinking it must have been acquired and wasn’t taking new users. This must have been an incorrect take.

I’m surprised Tabnine is not mentioned in this thread at all, though because that was acquired and afaik is still operating.

Before copilot came along, Tabnine, not Kite, seemed like the ai took to beat.

I also remember a Python dev relations person from Jetbrains going on a podcast and clowning on AI code completion. That was in April of 2021. [2] A month later copilot dropped.

The very strange thing about that was Jetbrains described efforts to build an ML-based code completion plug-in in 2016! [3] It obviously failed to follow through on that.

I still think G Co pilot represents a threat to jetbrains IDEs overall. Even the packaged autocomplete can’t compete on basic stuff copilot does now.

I disagree with the idea that AI code completion is not good enough yet. I see that said all the time and yet it can masterfully fill in boiler plate today.

It can be way better, particularly in languages outside JavaScript and Python, but it’s usable now and maybe even profitable as a service if the business is not leveraged by VC capital.

If you listen to the September interview with Eddie Aftandilian of Github Copilot you would realize how early it still is for that product, as how to measure success in code completion is something still requiring behavioral patterns that are still being recorded.

Here’s the episode, listen 20 mins in: https://www.se-radio.net/2022/10/episode-533-eddie-aftandili...

[1] https://news.ycombinator.com/item?id=25074393

[2] https://twitter.com/jetsetter/status/1379438096232587265

[3] https://blog.jetbrains.com/idea/2016/09/share-your-stats-to-...

There are many technical solutions to this problem, as others have pointed out. What I would add is that data at the edge should be considered immutable.

If records are allowed to change, then you end up in situations where changes don't converge. But if you instead collect a history of unchanging events, then you can untangle these scenarios.

Event Sourcing is the most popular implementation of a history of immutable events. But I have found that a different model works better for data at the edge. An event store tends to be centrally localized within your architecture. That is necessary because the event store determines the one true order of events. But if you relax that constraint and allow events to be partially ordered, then you can have a history at the edge. If you follow a few simple rules, then those histories are guaranteed to converge.

Rule number 1: A record is immutable. It cannot be modified or deleted.

Rule number 2: A record refers to its predecessors. If the order between events matters, then it is made explicit with this predecessor relationship. If there is no predecessor relationship, then the order doesn't matter. No timestamps.

Rule number 3: A record is identified only by its type, contents, and set of predecessors. If two records have the same stuff in them, then they are the same record. No surrogate keys.

Following these rules, analyze your problem domain and build up a model. The immutable records in that model form a directed acyclic graph, with arrows pointing toward the predecessors. Send those records to the edge nodes and let them make those millisecond decisions based only on the records that they have on hand. Record their decisions as new records in this graph, and send those records back.

Jeff Doolittle and I talk about this system on a recent episode of Software Engineering Radio: https://www.se-radio.net/2021/02/episode-447-michael-perry-o...

No matter how you store it, treat data at the edge as if you could not update or delete records. Instead, accrue new records over time. Make decisions at the edge with autonomy, knowing that they will be honored within the growing partially-ordered history.

I like:

Defn: https://podtail.com/en/podcast/defn/

The REPL: https://www.therepl.net/episodes/ (Seems to have gone quiet)

ClojureScript Podcast: https://clojurescriptpodcast.com/

Functional Design in Clojure: https://clojuredesign.club/ (Also seems to have gone quiet since December)

LispCast by Eric Normand: https://lispcast.com/

Cognitect, the company behind Clojure also has their own podcast but I haven't found it to be that interesting most of the time, at least yet: https://www.cognitect.com/cognicast/index.html

Not specifically Clojure-related but has discussed a few times including wit Rich Hickey (as well as other unrelated great conversations!): CaSe https://www.case-podcast.org/

Completely not at all about Clojure but great software podcasts:

Go Time: Even though I hardly ever write Go, I find their conversations to be really great and having lessons beyond Go. It helps that I am interested in the language though: https://changelog.com/gotime

Web Development and Development in general - The Bike Shed: https://www.bikeshed.fm/

Software Engineering Radio: https://www.se-radio.net/

CoRecursive: https://corecursive.com/

Inside Java: https://inside.java/

I am the author of “Rust Web Development” (Manning) [1] and I am using Rust now at my third job full time for “web development” (which is: for backend services).

What I like about Rust, and where it makes the biggest difference to my previous jobs, is the type system and the compiler.

I am using it currently to build distributed systems, using gRPC, adding GraphQL services etc. So there is enough there to take you started without having to rewrite everything yourself.

The community is great to get answers, even many crates have active GitHub discussions or Discord servers.

Sure, there are differences in axum, actix and others. But to be honest, will this impact your productivity all that much?

For some cases, the tooling could be more mature, but the language itself makes you more productive and you are having more fun with it. I also talk about it on the Software Engineering Radio podcast episode. [2]

So I can’t speak for frontend apps, or if you come from Go etc. But I have fun using it for my side projects, and in my day to day life for 3-4 years now, Rust had a substantial impact on the productivity of teams I am working at.

Rough edges are there, yes. Async is maybe not as easy as in Go, and you have to think about memory management more. But these tradeoffs are worth it for me.

[1]: https://www.manning.com/books/rust-web-development [2]: https://www.se-radio.net/2023/05/se-radio-562-bastian-gruber...

So "demand side" means industrial efficiencies? I always thought of it as, you know, less end-usage.

Yes it's a small share of the total, and no I don't believe it's a matter of policy. It's cultural. Whose job do we think it is to "spend within our means" energy-wise? Everyone's? Or is it industry's job to just "make it work" so that we can keep black-boxing power, as we do water.

Example: I was at an airport café this morning and I noticed that the menu was displayed on three big display monitors. They were probably 42-inch screens, all showing the same static image. There were like 6 menu items, all minor variants on a cup of coffee. They were all clearly visible from every possible angle. The same job could have been done undistinguishably well by any single one of them—not to speak of a printed board.

I know, it's an airport for crying out loud. The energy used by those screens is too small to measure. What concerns me is that we (Americans at least) live in a society where someone—I would say thinks this is okay, but really just doesn't think about it at all.

So I completely agree about where our priorities should be, but I think that those levers would be easier to pull if we as a culture had a little more "mechanical sympathy."[0]

[0] http://www.se-radio.net/2014/02/episode-201-martin-thompson-... (Where I first heard of it, anyway.)