The feature in OxCaml that more languages should steal
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.
I'm leaving New York this December for the research triangle area of North Carolina. I've considered leaving New York many times for the same reason: lower cost of living to help me start a company without needing to force myself into a VC route. And now with The Consensus I have a project that 1) I fully believe in and 2) is going pretty well, so it's time to extend my runway. It has been a joy meeting so many cool people in New York over the years attending and running meetups. (NYC Systems is in good hands with my coorganizer Angelo Saraceno, who has been there since the beginning.) It's scary to leave the big city, the subway, the diverse peoples, the diverse food, the stores that are always open, to leave friends, to leave the place that everyone in the world seems to find themselves periodically coming to. But I'm also excited to go somewhere new and explore a new region of the country. (I spent my whole life in the north east). I have good memories of visiting the gardens at Duke, the lakes around Charlotte, the mountains near Tennessee. I'm looking forward to seeing them again and seeing more. DC Systems is within driving distance and I'm hopeful for groups in the research triangle, Charlotte, Atlanta, and around Virginia. I'm excited about all the students in the area. Excited to have a new excuse to bring PhD students out for Banh Mi. Mostly I'm excited to have more time to keep working on The Consensus. I suspect the triangle won't be my last stop, and maybe I'll be right back in New York in no time, but it's the right stop for me right now. So, say hi before I leave! Let's catch up one last time before my visits become more sporadic. And if you're a reader in the triangle area, give me your tips! And let's meet up when I'm settled.
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.
I quit my job at EnterpriseDB hacking on PostgreSQL products last month to start a company researching and writing about software infrastructure. I believe there is space for analysis that is more focused on code than TechCrunch or The Register, more open to covering corporate software development than LWN.net, and (as much as I love some of these folks) less biased than VCs writing about their own investments. I believe that more than ever there is a need for authentic and trustworthy analysis and coverage of the software we depend on. This company, The Consensus , will talk about databases and programming languages and web servers and everything else that is important for experienced developers to understand and think about. It is independent of any software vendor and independent of any particular technology. Some people were surprised (in a positive way) to see me cover MySQL already, for example. But that is exactly the point. I don't want The Consensus to be just "Phil's thoughts". I have already started working with a number of experienced developers who will be writing, and paid to write, for The Consensus. I also hope that this is another way, beyond the many communities I already run, to give back to the community such as in highlighting the work of open-source developers (the first interview with a DataFusion developer is coming soon), and highlighting compelling events and jobs in the software infrastructure world. The Consensus is entirely bootstrapped and will depend on the support of subscribers and, potentially, sponsors . The first few subscribers signed up just this past week. You can read more about the background and goals here , you can read about how contributors will work with The Consensus here , and you can get a sense for where this is going by browsing the homepage of The Consensus already. Thank you for your support in advance! Thank you to the folks who have subscribed already despite very little fanfare. Feedback is very welcome. I'm very excited and having quite a bit of fun already. We're all going to learn a lot. I started a software research company pic.twitter.com/PY3L0yhJlW
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.
The most conservative way to build a career as a software developer is 1) to be practical and effective at problem solving but 2) not to treat all existing code as a black box. 1 means that as a conservative developer you should generally use PostgreSQL or MySQL (or whatever existing database), Rails or .NET (or whatever existing framework), and adapt code from Stack Overflow or LLMs. 2 means that you're curious and work over time to better understand how web servers and databases and operating systems and the browser actually work so that you can make better decisions for your own problems as you adapt other people's code and ideas. Zooming out, coding via LLM is not fundamentally different from coding with Rails or coding by perusing Stack Overflow. It's faster and more direct but it's still potentially just a human mindlessly adapting existing code. The people who were only willing to look at existing frameworks and libraries and applications as black boxes were already not the most competitive when it came to finding and retaining work. And on the other hand, the most technically interesting companies always wanted to hire developers who understood fundamentals because they're 1) operating at such a scale that the way the application is written matters or they're 2) building PostgreSQL or MySQL or Rails or .NET or Stack Overflow or LLMs, etc. The march of software has always been to reduce the need for (ever larger sizes of) SMBs (and teams within non-SMBs) to hire developers to solve problems or increase productivity. LLMs are part of that march. That doesn't change that at some point companies (or teams) need to hire developers because the business or its customer base has become too complex or too large. The jobs that were dependent on fundamentals of software aren't going to stop being dependent on fundamentals of software. And if more non-developers are using LLMs it's going to mean all the more stress on tools and applications and systems that rely on fundamentals of software. All of this is to say that if you like doing software development, I don't think interesting software development jobs are going to go away. So keep learning and keep building compilers and databases and operating systems and keep looking for companies that have compiler and database and operating system products, or companies with other sorts of interesting problems where fundamentals matter due to their scale. LLMs and your career pic.twitter.com/lxu1HLF2LC
This year I ran three book club readings over email with 1,230 unique attendees. I ran 12 coffee club meetups in midtown Manhattan with 170 unique attendees. Angelo and I ran 6 NYC Systems meetups with 12 different speakers and 281 unique attendees. I took 3 visiting PhD students out for Banh Mi . I raised $6,915 for educational non-profits, offering chats in return. I got coffee, lunch, or took 30 minute calls with 55 people I'd never spoken to before in person or on video. (Most, but not all, were in return for fundraising receipts.) This list included women and men based in the USA, Germany, Canada, Nigeria, Nepal, India, the United Kingdom, Brazil, New Zealand, Israel, and Australia. (I think I'm forgetting one or two.) Thank you to every person who has been a part of these efforts, making them so special and so valuable. See you in the new year! Year in community pic.twitter.com/n7jrmsZiKN
Among the 50 books I read in 2025, I recommend the following 11 non-fiction and 7 fiction works (complete list here ). These were the 18 books that I rated a four or five out of five stars. This is the third or fourth time I've read this book and it has stood the test of time. It's been a few years since I last read it so it was a good reminder that a lot of the things I believe and tell people about writing actually just came from this book. The last 25% is a bit of a slog but nonetheless it remains one of the single books I think every professional should read. 5/5 I really like reading about how writers make their living. I've also been a modest fan of Asimov's works (I've loved what I've read I just haven't read that much). I also love to hear stories of first-generation immigrants to the US and also he lived in New York his whole life so it was quite enjoyable. 4/5 This was 100 years of the evolution of the film industry told basically entirely in disparate interviews edited together. 5/5 I love the history and business of newspapers and media. Moreover it's the guy that Citizen Kane was based on. 4/5 I have never learned about the history of Brazil and I found this introduction enjoyable. 4/5 I loved the retelling of human history focused on Persia (and later Iran). 4/5 I have never read about a supreme court justice before. This was a well-written biography and introduction to the history of law and law education. 4/5 Once again I love reading about newspapers and media and the business and history. This was told by the publisher of The Washington Post. 5/5 I've had this book about Warren Buffett on my shelf for nearly 10 years and finally went through it this year. A delightful and easy read despite the bulk. I only am unhappy that it focused more on family drama than on business decisions. Par for the course with biographies unfortunately. 4/5 This story spanned three or four major wars and a couple of continents. I didn't think I'd be interested in the history of luxury businesses but it has a lot in common with certain modern industries in tech too. You put premiums on relationships and building good faith and so on. 4/5 A history of Coca-Cola over the last 100 years or so. Lessons on how they dealt with competition (Pepsi and Keurig Dr. Pepper) and product revitalization (New Coke, Diet Coke, etc.). Quite an interesting read. 5/5 I got into horror fiction last year (not so much slashers but more just one of the better written categories of genre fiction). This book was one of my two favorite novels of the year. It's a fictional retelling of American history where a Native American becomes a vampire and takes revenge on American colonizers in the American West. 5/5 This was my other favorite novel of the year. I am embarrassed not to have read it before. It's a dystopian story about the USA if all women were required to give birth to deal with a fertility crisis. 5/5 A French woman gets to live forever but everyone she meets forgets her after leaving her presence. An easy and enjoyable read. 4/5 I love a good vampire story, and I love fictional retellings using fantastical horror elements to emphasize atrocities. Vampires employed by the US military help the US in the 1840s take Texas from Mexico. 4/5 This was a cute cozy mystery about British witches forced to hide from society, learning how to accept themselves and develop trust in their community. 4/5 I am likewise embarrassed I have not read this before, nor anything else by Austen. I'm told I haven't rated it highly enough. I will undoubtedly reread it. I loved the wit. It required closer reading than I expected. 4/5 This was a retelling of Adventures of Huckleberry Finn as told by the slave, Jim. If you saw the movie American Fiction a few years ago, it's the same author (of the original book). Everett has very interesting ideas and I look forward to reading more by him. 4/5 My 2025 year in books. 18 to recommend among the 50 I read. pic.twitter.com/mIcbPk7e5x
One of the biggest lessons I learned early in my career was from Drew DeVault at Linode, 10 years ago. He was one of the youngest developers in the company (only I was younger, at 20, at the time) but he cared really strongly about thinking through architecture and code decisions when the culture at the time was, and I love those guys, a little haphazard. Drew had no special position. We all had the same title, "Developer". But he argued so persuasively and so doggedly even when the entire organization seemed against him and somehow he eventually transformed the entire engineering organization. That's supposed to be impossible! It was entirely new to me. That you don't need to wait behind people with more experience to make the right decision. That you can be part of making the right decision if you can find the logic and the will to do it. It isn't that simple of course. Politics is politics. But there are plenty of companies with people who will make a good faith effort to do what makes sense but might, without someone's unasked-for effort, do not what makes sense but what is popular because what's popular just kinda seems easiest. And I always like working for these companies, and for the most part have been able to identify them during the interview process. I learned from Drew to put limited value in seniority. I learned that it's ok to debate. I learned to be prepared and to try to present the facts. I learned to be persistent when I wanted change. I learned that with these skills, it's possible for an individual to redirect the path of an organization. It took a while longer (and me driving one or two people on my team to quit, to my great regret) to learn when to do these things and when to let things go. Still, this lesson from Drew on what's possible always stands out in my memory. Thank you, Drew.
This is an external post of mine. Click here if you are not redirected.
Sometimes I get asked questions that would be more fun to answer in public. All letters are treated as anonymous unless permission is otherwise granted. Hey [Redacted]! It's great to hear from you. I'm very glad you joined the coffee club and met some good folks. :) You asked how to learn about systems. A great question! I think I need to start first with what I mean when I say systems. My definition of systems is all of the underlying software we developers use but are taught not to think about because they are so solid: our compilers and interpreters, our databases, our operating system, our browser, and so on. We think of them as basically not having bugs, we just count on them to be correct and fast enough so we can build the applications that really matter to users. But 1) some developers do actually have to work on these fundamental blocks (compilers, databases, operating systems, browsers, etc.) and 2) it's not thaaaat hard to get into this development professionally and 3) even if you don't get into it professionally, having a better understanding of these fundamental blocks will make you a better application developer. At least I think so. To get into systems I think it starts by you just questioning how each layer you build on works. Try building that layer yourself. For example you've probably used a web framework like Rails or Next.js. But you can just go and write that layer yourself too (for education). And you've probably used Postgres or SQLite or DynamoDB. But you can also just go and write that layer yourself (for education). It's this habit of thinking and digging into the next lower layer that will get you into systems. Basically, not being satisfied with the black box. I do not think there are many good books on programming in general, and very very few must-read ones, but one that I recommend to everybody is Designing Data Intensive Applications. I think it's best if you read it with a group of people. (My book club will read it in December when the 2nd edition comes out, you should join.) But this book is specific to data obviously and not interested in the fundamentals of other systems things like compilers or operating systems or browsers or so on. Also, I see getting into this as a long-term thing. Throughout my whole career (almost 11 years now) I definitely always tried to dig into compilers and interpreters, I wrote and blogged about toy implementations a lot. And then 5 years ago I started digging into databases and saw that there was more career potential there. But it still took 4 years until I got my first job as a developer working on a database (the job I currently have). Things take time to learn and that's ok! You have a long career to look forward to. And if you end up not wanting to dig into this stuff that's totally fine too. I think very few developers actually do. And they still have fine careers. Anyway, I hope this is at least mildly useful. I hope you join the Software Internals Discord and nycsystems.xyz as well and look forward to seeing you at future coffee clubs! Cheers, Phil I wrote a letter in response to a developer asking about how to learn systems. pic.twitter.com/2ILNpzl662
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.
This is an external post of mine. Click here if you are not redirected.