Stephen M.

I've seen a lot of bugs. (No, not another cicada post). Software here. Egregious, immediately noticeable bugs. The opposite - those that require 6 concurrent conditions and 6 hairs from your nextdoor neighbor and it still only triggers once a month. (Okay, 7 conditions, 6 hairs...don't split those hairs). A continuum of buggage. Those complicated ones, sans the hyperbole - those are your Zero day issues. Regression testing doesn't find them. A super wily code-reviewing look-at-it-all software QA professional (I know the best one)...might...but probably not. How do we even engineer testing all of the complicated conditions? The interrelationships at runtime? I don't see a lot of talk about "how could we have caught this?" in public for disclosed issues. Most of the fixes for Zero days (those security holes best known because they're patched with updates to software like Google Chrome browser, Apple's ioS, Microsoft Windows) are downplayed. You get "Hey, user, look at these new features you're getting, and in whispered voice, "and security updates." Not familiar with the term? Zero day means a security issue without a patch. When the patch arrives, there's a remedy for the problem. Users often don't APPLY the remedy until much later...its own problem...prolonging the risk of the Zero day issue. Back to my kinda silly example. That's a wicked hard problem to test for. A bunch of concurrent situations that then trigger the problem. But, when the problem's a known issue, it's not hard to re-trigger. And therefore exploit. So what do we do? Other than fixing/patching, and communicating? What else is there to add to this conversation? Sunday thoughts. Sunday thoughts.

13

7 Comments

Taken from TLDR - full article attached. "To automate entire job functions" it says. Talking about making your job easier? You won't have to do anything! 🤖 In two months they have generated 700k in ARR (Annual Recurring Revenue, so subscriptions. Artisan, a fast-growing startup founded in 2023, is revolutionizing the future of work by developing AI employees, called Artisans, to automate entire job functions, starting with sales. After initially struggling with a self-serve model, it transitioned to a sales-led approach, resulting in significant growth. Artisan is focused on building an efficient inbound lead generation system and aims to create the best outbound AI SDR on the market. It plans to expand into other areas like marketing and customer success. https://lnkd.in/eUnT972j

6

3 Comments

This is a bittersweet post (more on that later) and long. When I joined The ASSISTments Foundation over 4 years ago, our platform was a hodgepodge of code and frameworks accumulated over decades. Ruby on Rails, GWT, JSP, Java, an API with no standard, and a database and data structures that had long since lost their ability to scale with the kinds of things we needed it to support. All running on a few physical servers at WPI. There was SO much work to do if we were ever going to have a foundation on which to truly innovate. Over the last few years, we’ve moved our entire infrastructure to the cloud, rebuilt the teacher experience and student experience in Vue.js from the ground up, and launched a brand new product for school admins and instructional leaders. But the last step was the biggest: we had to refactor all five of our products to use our new RESTful API (SDK 3.0), migrate terabytes of content to our new database structures and build an entirely new content management and authoring system to support everything. Plus, we wanted to include some of the first new features not possible on the old system: new item types and an alpha version of teacher authoring for our longtime ASSISTments 1.0 users. On Tuesday, after well over a year of the most complex refactoring you can imagine, the team delivered flawlessly. Even though this is not the Oscars (and I certainly am not “the winner” of this), I’m now going to go over my time limit and praise the amazing team responsible for this: First, Director of Engineering Ryan Emberling and Senior Product Manager Cindy Starks organized and managed the entire project through the many, many curve balls we were thrown and pivots we had to make, building the management systems on the fly as we figured out this herculean task, with help from Michael Weingarth owner of our district admin product. Lead Designer Kyle Scheuing, working with our Director of Content and now Product Owner Dawn Peterson designed an intuitive but amazingly powerful authoring environment that is legitimately worthy of a design award if such things were given for authoring environments. Our engineering leads, Christopher Donnelly, Joan Wong, and David Magid—along with Ryan—self-organized in true agile fashion to lead the rest of the engineering team through countless hours of analysis, architecture decisions, code review, and God-knows-what-else. And finally, our amazing engineering team: Danita Forbes-Sample, Manuel Gonsalves, Rownok Nowrose, Brian Rojas, Jaime Torres, Jose Velazquez did months and months of work rewriting vast swaths of our codebase. I am so proud of this team, and honored to be able to work with them. Their achievement has set the stage for innovation at ASSISTments for years to come. The bittersweet part of this is that I will not be with them for that journey. I will miss this team incredibly, and I hope our paths will cross again.

44

8 Comments

If you're the kind of person who's excited about all the recent S3 feature announcements (bucket policy unlocks via temporary root sessions, up to millions of buckets per account, pagination and region filtering for ListBuckets, conditional writes, ListCallerAccessGrants API) and you're attending re:Invent, then you should come to our storage track session, STG306 Advanced security patterns on Amazon S3. Learn how to use all the exciting new stuff securely in the most interactive format available at re:Invent!

94

2 Comments

This guy doesn't quite get it, some bullets from his "quiet quitting playbook" * Blocking out private calendar time - I advise teams and developers to do this to not be randomized and to have dedicated flow for their work * Artificially extending project timelines (claiming two weeks for one-day tasks) - Oh you mean pad our numbers so we estimate accurately? * Citing unclear specifications as blockers - never ending stories because of poorly defined specs/stories? * Making numerous small code refactors - Excuse me? All that tech debt that you said you were ok with us adding and promised to give us time to address that never happened? What about simple design, or the TDD loop? What about dealing with this big ball of mud? Or are you asking, "Why don't you just write it right the first time?" * Blaming build system issues - That the build takes 5 hours to run and non-deterministic test failures? * Claiming blockages from other teams - AKA external team dependencies are impacting delivery? * Using technical jargon about "race conditions" to justify delays - This guy obviously isn't technical. Ever tried to debug a "race condition"? * Deflecting tasks by requesting formal ticketing ("can you create a JIRA for that?") - I almost love this one the most. If I spin this another way, "Don't work on any item that I can't see on the Project Board please. https://lnkd.in/et4HYE9E

2

so what is your move gaes

1

Time to be fair.... In past posts, I have been less than complimentary of the DLC regulations that now make it more difficult to implement SMS into an application. I understand that all sorts of organizations use (and misuse) SMS millions (billions?) of times daily. I get that the new regulations make an attempt to reduce, as much as possible, SMS Spam. All in all, it just seemed like another example of hand-cuffing the good guys while trying to put some limits on the bad actors. My experience at the time was with #Twilio... and I tried to make it very clear that my frustration wasn't necessarily with them - they were doing the best they could to handle an avalanche of organizations trying to comply with new rules that everyone was stumbling their way through. I've been using Twilio for years and can't complain AT ALL about the platform performance for my particular small-scale needs. It was the nearly impossible approval process that really soured me. After nearly a year of living without application-based SMS (email only), I decided to revisit. The application was already all wired up for the feature - it was just dormant. This time around I was able to get up and running in 3 days... 99% of which was the DLC approval - which happened today. Kudos #Twilio for suffering through the tough days and making SMS once again something that can be done with very little pain. #twilio #sms #dlcapproval

2

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

Carta's data is ....off? Coastal Recruiting communicates with hundreds of engineers weekly, primarily in New York and San Francisco. We consistently encounter software engineers with 2-6 years of experience requesting base salaries between $180,000 and $250,000, plus equity. Perhaps "misleading" is a better term, as I frequently hear founders saying, "But Carta indicates we can hire this engineer for $140,000 to $160,000." We then observe Seed/Series A companies paying $200,000 to $300,000 for top talent. The disconnect may stem from the fact that companies raising funds from Sequoia, Khosla, Founders Fund, Lightspeed, a16z, KP, Greylock, Index, NEA, Lux, and others are not seeking what 95% of the companies providing data to Carta are seeking. These companies are looking for the top 0.01% of engineers. I say all this while also acknowledging my appreciation for Carta. I value the data and charts it provides, but it's important to remember: "There are three kinds of lies: lies, damned lies, and statistics."

26

9 Comments

Disclaimer: I am not a medical professional etc. So treat this with caution. Occasionally, I wonder if some techniques in software engineering work because a lot of devs have ADHD, diagnosed or not. (Not sure if anyone has actual numbers here: https://lnkd.in/eamW_Nqz) So it’s interesting to stumble across “body doubling” - the fact that having someone present helps with executive function in ADHD and wonder if that is why mobbing and pairing works so well for some developers. https://lnkd.in/eBrMQS84

32

18 Comments

This post serves as an excellent reminder that systems design and API design are *incredibly hard* to get right, *even* for people that have lots of experience and who have built similar systems in the past. As someone who has built systems used in production and lived to regret many of my decisions, I find this somewhat comforting. The linked sig-architecture thread [0] also has lots of interesting tidbits, including this bit from the legendary Tim Hockin: "Of all the APis we have, Node has some of the weirdest semantics. First, it's one of a very few "non-causal" objects(1) we have in core. Also, it is one of the oldest APIs, so it suffers from under-design, under-specification, organic evolution, and calcification - all contributing to or resulting from the success of k8s. If we were starting over, I doubt Node would be designed the same way. That said, we have to work with what we have. IMO, deleting a Node probably *should* cause a drain and should cause a controller to release the VM behind it (if appropriate), just like deleting a volume releases the disk behind it and deleting a service releases any LB attached to it. Can we fix that? I don't know...maybe?" https://lnkd.in/diFyvWhE by David Morrison [0] The whole thread is worth reading, but especially the laments of the folks that have been working on Kubernetes since the beginning: https://lnkd.in/d48cjiBZ

3

Dev agencies, if you don’t want to be treated as a commodity, stop acting like one. - Learn the business context for engineering needs - Stop squeezing your clients every opportunity you get - Prioritize transparency, communication, and accountability In short, position yourself as a partner that uses tech to solve business problems. You really can’t complain about being seen as a commodity if you treat everything as a transaction.

1

1 Comment

OK, let's talk about Platform Engineering. Good grief. Platforming is a topic that has grown into a life of its own in tech, and not in a good way. I'm going to row against the current. Platform teams are an anti-pattern. If your developers don't know how to properly provision and maintain infrastructure that is both supportable and minimizes cost and emissions, then you need better developers. Maintaining infrastructure in a consistent, supportable, optimized fashion does not require a team of people. A platform is not infrastructure nor is it the automation to maintain said infrastructure. A platform is a collection of APIs and messages that bind applications together. Again, this does not require a dedicated team of people. Platform teams are waste. Platform engineering is cover for justifying that waste. #platformengineering #platforms

8

13 Comments

I love Ken K.'s mindset of building a founding team of engineers as your starting 11. ⚽ The number isn't 11. Software teams aren't the size of a football team. But it's a great analogy to find your best starting team. For Devika, it was building teams in blocks of 4 and keeping the total engineering team at a mid-size of 24 -28. That way they could ensure they weren't too big and focus on quality of delivery. Focusing on quality and finding the best engineers for your starting team is the foundation for any startup/scaleup. If you are seeking to find your starting team of founding engineers or the next Principal Engineer to lead the growth and coding habits of your team, click on the "View My Website" link on my LinkedIn bio. To hear Ken's story of scaling Devika and helping build some of the country's leading tech companies listen to Episode 7 of ScaleUp Soundbytes. Link in the comments. #startups #techrecuitment #foundingteam #foundingengineer #football

10

I spent a lot of my operating career marketing to technical audiences at Facebook, Box, and Scalyr. My running joke was I love engineers so much I married one (shout out Chris Estreich!). I talk to a lot of founders of dev-focused companies who think they need someone technical or with an engineering background to run marketing. That's a mistake. You need a marketer who is excited to dive in and immerse themselves in their audience, in this case, engineers (and there are many flavors of engineers/devs). There are some areas, like creating technical content, that as a marketer, you need to work with others in your company to do well. I'm excited to be partnering with Justin Gage on a guest post for our MKT1 newsletter focused on how to create technical content. For all my dev marketers out there- who do you think does technical content well right now?

100

18 Comments

The revolution and all the hate Agile gets these days seem to be coming from bad integration of Agile in companies, which leads to bad experiences. But what needs to be separated in this equation is Agile methodology and bad experiences with bad implementation by managers in the same company. 💡🤔 Gojko Adzic makes an excellent point here — the normalization of Agile practices isn’t a sign of their decline; rather, it highlights their maturity. It’s easy to confuse the quiet efficiency of practices like automated testing and continuous integration with a lack of innovation, but in reality, these systems have become the bedrock of modern software development. Agile, in many ways, has succeeded so thoroughly that we no longer notice it. The fact that "agile" is in the background of our daily workflows should be seen as a win. It's a testament to the adaptability of teams that Agile and Scrum no longer need to be front and center in every conversation—they've done their job of empowering us to focus on delivering value rapidly and efficiently. This opens up opportunities to reflect on our processes and make incremental improvements while riding on the strong foundations Agile built. This isn't the end of Agile—it's its evolution into a natural state of being for teams. #agileisdead #agile #scrum

1

It's rather special to see Wordware (YC S24) featured up alongside incredible companies like Retool, Vercel and Replit. Less friction ➡ more iterations ➡ better products. Wordware does this for our customers when working with LLMs. Neon does this for our engineers when building Wordware. Neon 🤝 Wordware What a match. #llms #serverless #ai #postgres

132

16 Comments

In this exciting episode of the Mob Mentality Show, we are joined by Kyle Griffin Aretae to dive deep into the nuances of Test-Driven Development (TDD) and the crucial concept of "Goal-Centricity" in Agile practices. Kyle breaks down why TDD is so much more than just "test first" and challenges common misconceptions about this used development practice. If you're a software developer, Agile enthusiast, or just someone looking to refine your team's development processes, this episode is packed with insights you won't want to miss. https://lnkd.in/gUV9Ffwc https://lnkd.in/gmXf6fJ7 Chris Lucian We explore why treating TDD as merely writing tests first misses the larger picture and how adopting a broader, more progressive approach can help your team build better, more maintainable software. Kyle shares his thoughts on the primary value proposition of TDD, focusing on **fast feedback loops** and the **refactor step** at least every 5 minutes. He explains how smaller, healthier TDD cycles allow developers to stay nimble and avoid the trap of feedback loops that last 30 minutes or more. Thus, when fast feedback loops with constant refactoring are in place as the foundation, then the "test first" aspect of TDD really shines. A key takeaway from this episode is the impact of **social programming**, TDD, and **CI/CD (Continuous Integration/Continuous Delivery) pipelines**. We explain the importance of the "Pipeline First" principle when writing new code. We then dive into maybe Kyle's most controversial take on TDD: the idea that creating a **mini-plan** (a rough roadmap of what to do next) before writing tests might actually be more beneficial than strictly adhering to "test first." This, Kyle argues, leads to more robust code when integrated into strong social programming practices. We also touch on the application of **Maslow's Hierarchy of Needs** to TDD and the importance of satisfying basic development needs (like fast feedback and clean code) before tackling more complex issues. The episode continues with a discussion on the intersection of **Goal-Centricity** and Agile. Kyle questions whether Agile methods are effective without first agreeing on a clear goal. We explore scenarios where goals are unclear or where methods are imposed without understanding the desired outcomes. Kyle shares a fascinating example of a code freeze during "Black Friday" and the unintended consequences of such decisions. We also reference a powerful quote by **Deming**, "A goal without method is cruel," explaining how the opposite can be just as problematic.

10

5 Comments

It's been less than two weeks since we released Replit Agent into the wild. The response has been more than we expected. So many people have great ideas for software, and their creativity has just been unleashed. As a result, we're hiring for multiple roles in engineering to help double down on our efforts and keep improving it every week (our weekly all hands is called Weekly Wins for a reason). Want to be part of the action? Message me or just check out: replit.com/careers Want to know more about Replit Agent? Check out Matt's deep dive: https://lnkd.in/gb8z8i6S

44

3 Comments