bryansum

Having also been part of an acquisition in 2020, I found her assessment of Twitter internally was spot on, and was something that I believe isn’t discussed enough in the context of the Elon acquisition.

There was a great sense of shared vision and purpose internally, but this also masked a fair amount of cynicism / political machinations (launch a feature we don’t actually believe to prove it won’t work — Fleets), engineering tech debt (I worked on the iOS client) leading to extremely long product / dev cycles, and ultimately the most destructive, a sense of complacency about it all. It was ultimately why I left, even before the Elon drama.

The Right to Read movie talks about this very topic, and features the author of this podcast: https://www.therighttoreadfilm.org/

Locket | Multiple roles | Full-time | Los Angeles, CA / SF / Remote (US / Canada) +/- 3hrs of PT | http://locket.camera

---

Locket is hiring!

Locket puts your best friends, relationships, and family at the center of your phone. Throughout the day, you’ll see live pictures sent from your favorite people, right on your Home Screen.

Locket launched one year ago and has gained incredible traction since then:

* 20M people have signed up

* Over 2 billion photos have been sent on the app

* Millions of people use the app daily

* Users love the product — thousands of people have created TikToks about the app, generating 100M+ organic views

* Selected as Cultural Impact Winner in the 2022 App Store Awards

We have a unique shot at becoming one of the defining social companies of the decade. If we’re successful, Locket can become the best way to feel closer to your friends and family. We want your help building Locket.

We have open positions for talented iOS engineers, a founding Android engineer, product designer, and full stack engineers.

Please visit http://locket.camera/jobs for more details.

Locket | Multiple roles | Full-time | Los Angeles, CA / SF / Remote (US / Canada) +/- 3hrs of PT | http://locket.camera

---

Locket is hiring!

Locket puts your best friends, relationships, and family at the center of your phone. Throughout the day, you’ll see live pictures sent from your favorite people, right on your Home Screen.

Locket launched one year ago and has gained incredible traction since then:

* 20M people have signed up

* Over 2 billion photos have been sent on the app

* Millions of people use the app daily

* Users love the product — thousands of people have created TikToks about the app, generating 100M+ organic views

* Selected as Cultural Impact Winner in the 2022 App Store Awards

We have a unique shot at becoming one of the defining social companies of the decade. If we’re successful, Locket can become the best way to feel closer to your friends and family. We want your help building Locket.

We have open positions for talented iOS engineers, a founding Android engineer, product designer, and full stack engineers.

Please visit http://locket.camera/jobs for more details.

Locket | Multiple roles | Full-time | Los Angeles, CA / SF / Remote (US / Canada) +/- 3hrs of PT | http://locket.camera

---

Locket is hiring!

Locket puts your best friends, relationships, and family at the center of your phone. Throughout the day, you’ll see live pictures sent from your favorite people, right on your Home Screen.

Locket launched one year ago and has gained incredible traction since then:

* 20M people have signed up

* Over 2 billion photos have been sent on the app

* Millions of people use the app daily

* Users love the product — thousands of people have created TikToks about the app, generating 100M+ organic views

* Selected as Cultural Impact Winner in the 2022 App Store Awards

We have a unique shot at becoming one of the defining social companies of the decade. If we’re successful, Locket can become the best way to feel closer to your friends and family. We want your help building Locket.

We have open positions for talented iOS engineers, a founding Android engineer, product designer, and full stack engineers.

Please visit http://locket.camera/jobs for more details.

Not exclusively, of course, but the degree of processing of food greatly influences our body’s insulin response, which can over time have huge impacts on health (leading to fatty liver disease / metabolic syndrome / obesity / diabetes). This is why, for instance, fruit juice is so much worse for us than the whole fruit — most of the fiber is removed which would otherwise slow down digestion and temper insulin response. For more info I’d highly recommend Jason Fung’s Obesity Code book — he’s a nephrologist specializing in diabetes treatment.

One point that's not being discussed enough -- using SwiftUI (since it's heavily value-typed / struct-based) prevents a whole host of problems around retain cycles, typically the bugbear of iOS dev. I recently built an iOS app from scratch with recent grads with zero Swift experience (but had done React).

It was ~2mo before they even had to learn what a retain cycle was, and that was from using UIKit.

Of course you still eventually see this if / when you use `@ObservedObjects` and their implementation, but in our case we were also using https://github.com/pointfreeco/swift-composable-architecture which hides this away as well.

Yes, I recently built an entire app with 70+ frameworks that works fine in Previews. The key is to isolate dependencies into their own modules, and also split those into interface / live implementation modules if needed if the live impl causes preview crashes. See https://www.pointfree.co/episodes/ep171-modularization-part-...

Muze | React Native Engineer | Remote or Brooklyn office | https://muze.chat

Muze is rethinking chat as a freeform canvas where talking with friends is more expressive and playful. You can check out videos demoing the app here: https://linktr.ee/muzejobs. If you'd like to demo the app feel free to contact us.

  * Sequoia backed, seed stage
  * Significant product demand from Gen Z
  * Engineering team includes top names in RN community

To apply, email jobs@muze.nyc

Looks like that would've probably been caught if it were written in Swift.

Absence of evidence is not evidence of absence.

Bird is hiring iOS developers too! Apply through the link above, or you can also email me at bsummersett@bird.co if you have any questions.

One huge problem is that there’s no context-indepedent definition of quality code, and criticisms often suffer from hindsight bias.

Jaron Lanier characterizes these kinds of companies as "Siren Servers": http://marginalia.lareviewofbooks.org/the-vibrant-religious-...

Not to mention smoking is often a social activity -- the "smoke break."

Great point; the question then becomes why is this interference necessary? Largely due to ads. Instagram made their feed algorithmic recently for this reason.

"IBM says it's ready to receive its next Apple check"

I'd assume because DASH is generally a newer spec, and HLS was driven by mobile usage

FYI: your link to the GitHub project halfway down the article is broken.

More information available on the author's blog: http://allievi.sssup.it/techblog/?p=798

My pleasure. I figured this was a bit more manageable than doing d3.js at the moment ;).

Excellent reference. Papert created his own theory called constructionism based on the tenants of learning by doing and accumulated knowledge acquisition (genetic epistemology). He emphasized making learning tools meaningful and relevant to children, so that they could use their prior experiences to help model new concepts. With LOGO, children used imperatives to command a turtle around on screen. When things went wrong, children could "act like a turtle" to debug, often by physically acting out the commands themselves. He called it body syntonic learning, as opposed to the more traditional disassociated learning we typically see. Shameless plug: I recently wrote more about this in a review of the book "Mindstorms" that this was an excerpt from: http://bsumm.net/2012/07/01/mindstorms.html

Simula67, the version most identify as Simula proper, actually evolved concurrently with Smalltalk.

Rick DeNatale's memoir has a great article debunking some early OO myths -- http://talklikeaduck.denhaven2.com/2006/07/29/about-me

pe·nul·ti·mate/peˈnəltəmit/

Adjective: Last but one in a series of things; second last: "the penultimate chapter of the book".

This seems conceptually similar to http://www.cascading.org/ (at least looking the code examples: http://www.cascading.org/1.1/userguide/html/ch02.html).

Could you provide some more context to your statements? What does Firefox have to do with Adobe?

It's funny you bring this up, because just yesterday I was using HTTParty and was getting strange errors when I was doing POSTs / PUT queries (basically the REST API I was using was giving me 500s and I didn't know why). After looking at your source, I then immediately realized I had to use the :body param instead of the :query param to pass in www-urlencoded values. Whether that reflects on the consistency or documentation of the API is another matter, but it just proves your point about the importance of being able to grok code.

Having lived in Michigan for almost all my life, I find Mr. Byrne's conclusion and observations about Detroit to be pretty accurate. I want to point out that not all parts of Detroit are ruinous; mid-town with Wayne State University, the DIA (Detroit Institute of Art), and other universities in the area make for an interesting and healthy part of town. As far as the tech scene, I'd say it's mainly concentrated in the Ann Arbor area.

I don't finding anything about Milgram demonstrating evil in man; it demonstrated the willingness to take orders from a perceived authority.

One of the points Larry Augustin makes is that languages become more complex as they adapt to a wider range of use cases. The fact that people end up using languages outside of their intended contexts strikes me as a case of not using the right tool for the right job. This is why learning a wide variety of languages is important -- it gives people perspective and opens up new and better ways of solving the problem at hand.

I think programmers, in general, aren't comfortable creating their own DSLs or language-level abstractions to problems, and this often leads less than ideal workarounds.