Guy Argo

🏎️💨 Making of a Ridiculously Fast™ API client in R. Why my package is **~17x faster** than the community alternatives that call the **exact same API endpoints**. 👇🏽**design choices matter** ✨ https://lnkd.in/ggi_2XyQ

129

2 Comments

Having a ton of fun writing an ORM for V2 of Case Kit. Typescript has such an incredible type system. I have autocompletion for column names, the ability to include relations, relations of relations, etc etc etc... all returning properly typed data (no classes in sight). It's been really satisfying seeing it coming together, and it's been great getting my hands dirty with some (relatively) complex generics. And to head off the obvious question… why aren’t I just using Prisma? Well there’s a couple of things I’m doing differently that I think are marginally better: there’s no code generation involved here, it’s just types (inspired by Drizzle); there’s no Rust binary you need to deploy, and it hews much closer to Postgres behaviour and syntax (the aim here is not to abstract away which database you’re using). But the real blocker to me using Prisma was that its extensions don’t support modifying queries of nested relations - a hard requirement for me due to the way I have multitenancy and soft deletes set up. It’s not shown in the video but the Case Kit ORM lets you write simple middleware that will be applied to every level of a nested query. Perfect for setting timestamps or adding clauses on tenant id or things like that.

21

OK so the reality of some conferences is pretty grim - very surface-level, vendor-driven content. I'm NOT a fan of 20-minute sessions... I can barely understand the problem being discussed in that amount of time. It just does not work for me. That's where UberConf makes a huge difference. 90 min in-depth sessions, on relevant topics by industry experts and practitioners. Conference size is limited to maintain a very comfortable environment without the need to walk 15 min to your next session, or it gets filled up. ooh... food is also great, fully catered for breakfast, lunch, and dinner (guaranteed great food)! https://uberconf.com/ I'm excited to join the amazing speaker line-up for a third year in a row. The opportunity to engage, share, and learn with the best (both speakers and attendees) is second to none. I've got a couple of new sessions planned, but I am most excited for: Crafting Consistent APIs at Scale: Embracing Linting and Reusable Models. Turns out that creating resources and building APIs in a distributed model is hard (who knew right?)! As teams expand and projects multiply, maintaining a unified API design can pose significant challenges. This presentation delves into the powerful combination of linting and reusable models as tools to navigate these challenges and ensure consistency across large-scale API ecosystems. Come check it out! Discount Code: uber24-travis4

22

5 Comments

Back in August 2023, Elon Musk said: "I think it's important for a leader to be at the front lines. The challenges are in ramping up production … It's about being in the factory and understanding where the issues are, and I want the very opposite of being up in an ivory tower; I want to be in the middle of the battle, and so that means putting my desk in the middle of the factory." What does "be on the front lines" mean in a remote software engineering context? 1. Create a culture of work review: This will allow you to contribute to your team's code and architecture from a peer perspective. This not only shows your commitment but also allows you to understand the design, codebase, and challenges intimately. 2. Participate in code reviews: Reviewing code isn't just about catching errors; it's also an opportunity to understand different approaches and patterns your team uses. By actively participating in code reviews, you not only provide valuable feedback but also learn from your team members. 3. Whenever you can, code: You don't have to get tasks as your other team members do, but as the technical leader of your team, you must act in the front of supporting business needs and, at the same time, protecting your team focus. Ensure you can help your team by coding any new needs or bugs that might come up, if necessary. 4. Debugging and troubleshooting: When issues arise, don't just rely on your team to solve them. Dive into the problem, debug the code, and work with your team to find solutions. This hands-on approach demonstrates your willingness to tackle challenges head-on. 5. Stay up-to-date with technology: Software engineering is rapidly evolving. Keep yourself updated with the latest technologies, tools, and methodologies by actively learning and experimenting. This allows you to provide informed guidance and make better decisions. 6. Be accessible and approachable: Make yourself available to your team for questions, discussions, and brainstorming sessions. 7. Contribute to technical documentation: write technical documentation, including design documents, API references, and user guides. This ensures that your understanding of the project is well-documented and helps onboard new team members more effectively. 8. Handle escalations and critical issues: When critical issues arise, be prepared to take charge and lead the response effort. Act decisively, coordinate with your team members, and work towards resolving the issue as quickly as possible. By being at the front lines in software engineering, you demonstrate your commitment to the team's success, gain a deeper understanding of the technical challenges, and foster a collaborative and supportive team environment. #remote #remotework #SoftwareEngineering #Leadership #HandsOnLeadership #TechLeadership #CodeReview #Debugging #TechnologyTrends #Teamwork #Collaboration #TechnicalDocumentation #ContinuousLearning #ProblemSolving #TeamSupport

3

"Your main job is to make your product win." I think this should apply to any product that your company makes. I also like what he says following this statement about what is NOT your main job. I will summarize here: "Your main job is not to make your manager happy, it is not to make execs happy." Also, note, this main job doesn't only apply to PMs, but also to senior Engineering Managers, Tech Leads, and Designers. #makeyourproductwin #leadership

5

1 Comment

Been thinking a bit more about AI and programming. In a previous post, I mentioned that I was worried about the "uncanny valley" effect. For those who don't know, the phrase "uncanny valley" was coined to refer to people's reactions to human-looking robots. We aren't bothered at all by robots that don't look like human beings (think R2D2), or robots that look a bit like human beings (think C3PO). We aren't bothered by robots that look exactly like human beings (think Blade Runner). We *are* bothered by something that looks a lot, but not quite, like a human being - it doesn't blink enough, it's skin is the wrong texture, and so on. It's that dip in the middle - where it's almost, but not quite, human - that's referred to as the uncanny valley. I'm sure someone has pointed this out before, but I think the same curve applies to the usefulness of AI. As an assistive technology, when you know it is being helpful, but can't take over for you, it's useful. Think autocomplete, or grammar checking. As something that can completely replace a human being, it's useful. You can argue that we're getting close to that with, say, image recognition (leaving aside problematic biases). There is a similar valley between these two, where human beings think that AI can take over for them, but it can't. (This effect probably already has another name, but I don't know what it is, so I'll live with "AI Uncanny Valley".) This AI Uncanny Valley can lead to funny results, as it does for the law clerks who have ChatGPT prepare legal briefs, only to have judges point out that they are citing case law that doesn't exist. It can also lead to tragic results, as it does when people trust their lives to Tesla's "Full Self Driving" mode and get killed. But the bad outcomes aren't always so obvious. One of the strategies that gets proposed for AI-driven software development is to have users describe the outcomes they want - feed the system a list of tests that have to be passed - and let the AI develop code that will make the outcomes happen. To the user, passing all of the tests would make it seem like the AI did what it was supposed to do. The problem is that human beings are really, really bad at coming up with tests. I watched a talk (see below) by researchers at NC state recently, who did a study of novice programmers. They found (to no one's surprise) that novices undertested their code in general, overtested the parts of the code that worked, and that their tests often mismatched requirements. They recommended a checklist of best practices for test developers, of the same kind that surgeons use before an operation to prevent infection. Imagine a world where this is what drives software development. Novices state requirements, badly. Code is generated that meets those requirements, but no one wrote it, and no one understands it. Code lives in that uncanny valley and no one ever notices. And we think we have software quality problems today... #AI #testing

5

2 Comments

I don't usually talk politics on here, but this is an exception I am prepared to make as the proposed Fast Track, in its current form, is that outrageous and has to be stopped. I am not opposed to fast tracking certain projects that this country needs, hell no, do it, by all means, BUT the way this government is proposing to go about things, giving just 3 ministers ultimate control and ultimate power of what gets fast tracked allowing them to bypass literally every single protection this country has in place to protect our country and its environment, is simply overreach, dangerous, undemocratic, and quite frankly blatantly open for corruption as has already been shown by the number of recent conflict of interest stories around donations and mining companies linked directly to ministers that are one of the 3 ministers that will have ultimate control. There are companies already on the provisional fast track list that have had various projects denied before for by concerned groups, ministries, ministers, select comittees, and even the courts, yet these projects are now back on the table and entirely within the control of 3 ministers that hate transparency, oversight and due process. So, if you share my concerns with how much control this bill gives with nearly zero oversight and transparency, then come along to this March for Nature and help STOP THE FAST-TRACK bill. This bill is dangerous and needs to be stopped. This government needs to hear this in the strongest way possible.

4

*Bracing myself for the response I might get for asking this* Software Engineers: Would you ever consider working on an EQUITY ONLY basis (ie no salary, just owning a portion of the business, the value of which would increase as it progresses and scales)? Assuming: - The product is really interesting and so is the work - The product is in the "tech for good" space and would be a really positive contribution to parts of society - Seed funding is confirmed to be coming with several backers keen & they will able to offer a salary in the near future - The product is super early stage, you would be writing the software from the ground up, but the concept, design and business model once funding is received are all solid I know that there will be many who would never consider this under any circumstances and I totally get why, but just curious to hear if any of you would if it was for a product you believed in enough? And would you look at it on a full-time basis or a part-time basis? It's something I got asked about and so I thought I would throw it out to Linkedin to see what you all think rather than assuming that I know the answer on your behalf. #startup #founder #softwareengineer

40

319 Comments

📰Introducing Miniflux: A Minimalist Open-Source News Reader🚀 Ever felt overwhelmed by information overload while managing multiple news feeds? Allow me to introduce you to Miniflux - an opinionated, lightweight feed reader that's going to change your life! 😊 Miniflux is written in Go and PostgreSQL, designed for simplicity, speed, and ease-of-use. Its minimalist approach avoids unnecessary features, focusing on the core functionalities of feed management. Why go for Miniflux? - Zero dependencies: Standalone binary ensures hassle-free installation 💻 - Single binary compiled statically without dependency - No ORM or complicated framework: Clean, efficient codebase for developers 🧑‍💻 - Modern Javascript (ES6 and Fetch API): Smooth user experience 🎯 - Extensive documentation: A beginner's best friend 📚 Personally, I've fallen in love with its simplicity. With Miniflux, it's now effortless to browse through different sources and enjoy the news without distraction. I am sure you will find it incredibly useful for your projects too! 💡 Now that you know about Miniflux, I'd love to hear your thoughts on the tool. Have you tried it already? How has it streamlined your workflow? Let's discuss the beauty of minimalism in software development! Feel free to share your feedback or ask questions about Miniflux here 👇 #Miniflux #FeedReaders #OpenSource #GoLang #TechCommunity

5

Substrate is live! After nearly a year of development, really honing the developer experience and performance tuning a very unique runtime environment, we're finally releasing what we feel is by far the best way to run multi-inference workloads (e.g. agents, multimodal text, json, image, audio, embedding pipelines, etc). Substrate lets you use a ergonomic SDK (we really obsessed over the abstractions and typeaheads) to describe precise and complex relationships between AI tasks. And—importantly—it's connected to a backend specifically designed to run these graph workloads as efficiently as possible (optimized models, auto batching, insanely fast inter-node RPCs). Given the current state of "AI" models, we really believe that this pattern is the most effective for building capable, reliable, legible, extensible features with AI that go far beyond chatbots. We need both heuristic models like LLMs as well as normal symbolic computation, and a flexible/scalable way to coordinate these two modalities. We've already seen organizations like Substack building some super interesting pipelines that they can easily understand and iterate on, that just work at scale. It's still early in a much more ambitious vision for us, but we think this V1 is not only ready but already a meaningful improvement to many implementations. Reflecting on the last year, I feel so much gratitude for the team that I'm working with: Ben Guo, Liam Griffiths, Rishabh Parikh, 💭 Kyle Pitzen, Chris S., (& Hanwen Wu soon!). With this launch, we're announcing an $8M Series Seed led by Lightspeed (Nnamdi Iregbulem+Guru Chahal) with participation from many others. Feeling a ton of appreciation for the folks that took a bet on us or have lent their time and advice: South Park Commons (Ruchi Sanghvi+Aditya Agarwal), Craft Ventures, Red Swan Ventures (Andy Dunn), Lorimer Ventures, Chris Best, Jairaj Sethi, iqram and the immigrant groove, Andrew Kortina, Guillermo Rauch, Immad Akhund, Sam Lessin, William Gaybrick, Gokul Rajaram, Jana Messerschmidt, Shreyas Doshi, Matthew Hartman, Mike Cohen, Sabrina Hahn, Anne Lee Skates, Shreyans Bhansali, Julian Connor, Namrata Patel + many many others. https://lnkd.in/eHq8KUkA

128

9 Comments

From IC engineer to C-Level exec, the most effective people I've worked with have one thing in common: they break down and decouple decisions. Optionality, trade-offs, last responsible moment, one-way and two-way door decisions, slicing, MVPs, proof of concepts etc. are all techniques they use for breaking decisions down and getting them made. The best engineers did this when working on code. Rather than trying to decide on all the functionality at once they'd be able to say "I can break this story down into smaller pieces of value that we can get released to users fast" or "we don't need to deliver this piece of functionality now, we can wait until we see how user's respond". The best architects, product managers and business leaders do the same thing. It's a real skill to decouple decisions. It's a real skill to be able to defer parts of a decision to next or later (or even never) to enable faster movement and lower risk. I have always been impressed when I witness it. Often it's obvious with hindsight and sometimes its completely out-of-the-box and you would have never have realised.

60

3 Comments

insightful diagram, and how as you move up the ladder you have to scale from hard skill to shift skills and business skills, on both sides you have to learn how to scale through others

9

1 Comment

Too much focus can make one's perception too narrow. My perception of #documentation has been too narrow. It's not often that something significantly shifts my perspective of something I'm so familiar with, but Adrienne Bellehumeur's "The 24-Hour Rule and Other Secrets for Smarter Organizations" has reminded me of the applicability of docs to workers of all stripes. I've often thought of doc authoring by domain—software, hardware, medical, automotive, aerospace, etc—but everyone from sales, to accounting, to legal, and every other work group needs docs in some format to be successful. Not everything is user docs or process docs. It's obvious when I write it out, but it's easy to forget. Bellehumeur herself has a finance background, so perhaps I simply needed some help to break out of my too-narrow focus. Food for thought. 🔗 https://lnkd.in/gu4yFW_X #techcomm #technicalwriting #docs #notes #pkm

21

1 Comment

For all those engineers out there building AI agents. You need to check out this #github repo. This is a great team tackling an important set of problems that engineers face, and this solution is significantly better than Langchain's approach. #ai #agents #ML

7

1 Comment

#throwbackthursdays You may have heard of London style Test Driven Development (TDD). You also may have heard of Detroit or Chicago style TDD. However, what do these two styles look like "out in the wild" in real production code? How about on teams collaborating via Ensemble Programming? Come join us as we share about our mob programming experiences of London TDD and Detroit/Chicago TDD. We not only talk about the pros and cons of each style in practice but we also talk about when they have seen each style done well and each style done poorly. Then they get practical about when to "shift gears" to experiment with a different style to fit the situation of the code and the team/mob. https://lnkd.in/g3MWjh5U #MobProgramming #TDD

8

I recently had an interview at Amazon that did not go well. It was a real shame because it was for the most promising position I could find: a developer support engineer position. So... what should I do? Well... doing nothing as I watch my savings evaporate is not an option. So, in addition to my job search, I've been working on a personal project. Since that project is still in its early stages, I prefer to keep that to myself. However: I will say that my project is an app that supports full-text searches. I'll also say that documentation and example usage of the Slick-pg library seemed scant. So... I built an example project and wrote an article about it on Medium. As for my job search: I hope to find something soon. In the meantime, I'll keep working on my personal projects to keep my skills sharp.

8

Consolidated my Notion homepage on a custom domain. I'm surprised it's not yet a native feature. I've realised that while pointing my personal website (https://angeloreale.com), I had lost most of my few years old SEO authority. So then, ... we just build it again. :) Recommending this Notion wrapper, and here is my referral link (I get some bucks if you sign-up using it): https://lnkd.in/dNKCuppi

🚨 I took down a major piece of infrastructure as a tech lead at Yahoo! and didn’t get fired…. I think this is the nightmare scenario for engineers - to not only break your own product, but to do broader carnage to systems at the company. I think we all fear what the repercussions are if we do this. However, when intent is good, recovery is swift and learnings documented, these things are actually quite formative. When it happened, I was able to remain calm and walk through a rollback in 2 minutes, which allowed the downstream infrastructure to recover in about 10 minutes. This was also the start to my reputation as a level-headed technical leader. Good relationships with my peers in the infrastructure team allowed us to quickly diagnose that my code push was the cause of the incident and take action. I was leading a team building a very powerful piece of software. We had a client library that was installed on every server and allowed us to push out front-end code to every web property simultaneously. Code changes would propagate in about 2 minutes from push. It allowed us to provide a consistent branding, search and navigation system.  Because we understood the power of the system, we also had plans in place if something went wrong and had practiced rollback and forwards. Typically, when things went wrong, they were minor UX bugs in the interface. Medium problems cost us some dollars in search revenues. However, this time, my change had a massive impact downstream. I had added a new polling feature that worked against the caching strategy of the platform I was calling. Within 2 minutes of diagnosis I executed the rollback strategy. The bad news was the product manager had to wait a few more days for the new feature to roll again respecting the caching strategy of the platform. The good news is that we recovered quickly. I learned a few lessons from this outage: 🚨 Outages happen all the time and you will likely not lose your job if you cause one. 📝 Your team should have plans should an outage happen how you will approach debugging and recovery. ⏰ Practice for urgent situations before they occur. 🏋‍♀️ Building and maintaining strong connections with leads of systems where you have dependency is key. 🧞‍♀️ I have a special ability to appear completely calm while feeling absolute panic inside, which is a good capability to have. 

59

9 Comments