Jack Niewiadomski

Software agents change coding. AI agents will build the same feature 10 times and select the best version. No limits, no guesswork—just optimized innovation. This is a radical new mindset: iterative, faster than ever, and powered by AI. 🚀 Nikita Shamgunov, CEO of Neon, is focused on the architecture of the future and creating for these next wave of agentic and code-gen applications powered by LLMs. A world where cost, infrastructure, and time barriers are tackled and AI agent development unleashes innovation at scale. The future of software development is parallel, not linear! And we'll need GenAI Friendly serverless database like Neon to make it possible. Watch the full episode to discover: - How serverless Postgres is enabling the next wave of AI-powered apps - Why "breadcrumbs" are crucial for AI agent systems - The architecture behind instant database branching 

1

I've been thinking a lot lately about ways of structuring IaC code, specifically - should this code be separate from application's code, or they can (should) be kept close to each other. When writing backend code, my rule of thumb about managing transactions (and other resources, like connections) is that a method or class cannot interfere with its (transaction's) state if that transaction has been started somewhere outside of that code. In simple words, only a piece of code that started a transaction should make a decision to commit or roll it back. Looks like this model can be applied to codifying infrastructure as well. If an application owns the lifecycle of an infrastructure resource, it is okay to put them in one source code repository. Short unpolished writeup on this topic: https://lnkd.in/emzDC9Nn

2

The "Scout Rule" is derived from the Boy Scouts' motto: "Leave the campground cleaner than you found it." In the context of software development, it emphasizes the idea of leaving the codebase better than it was before you worked on it. It can be translated as: "Always leave the code cleaner than you found it" Here are some suggestions: - If you notice mistakes in the surrounding code fix them right away - If the class/method is getting bloated, think about refactoring - If you come across outdated comments you should update, delete, or mark them as outdated - Clean up unused methods/variables/classes Over time you can make this a habit, so it becomes easier. https://lnkd.in/dvMdHBFG

20

1 Comment

Watch me stumble through the Advent of Code challenges using Typescript: Twitch.TV: https://lnkd.in/gjCHVejV YouTube.Com: https://lnkd.in/giEJz4xC The code is Typescript. The process is TDD. I use Co-Pilot (for better AND worse!)

8

1 Comment

I just watched a six year old code a whole game in 20 minutes from idea to execution (and another 40 minutes of improving gameplay via new prompts) and the only thing I had to do was help her spell some of the words in her head. 100% her hands on the keyboard using an IDE with AI agents (well, except for telling it to push to GitHub because she doesn’t know what version control or git are). Tell me again AI is not a big deal, I DARE you. If you want to play Silly Veggies, here’s the repo: https:// https://lnkd.in/gDBJPfSF

6

6 Comments

I’ve been having a few discussions with TDD aficionados.  We talked about whether they use TDD all the time. It appears that there are instances, particularly in graphical applications, where the test/evaluation is done post coding.  For example, rather than write an automated  test for an object’s depiction, they code and see whether the object appears correct. It was suggested that there may be other times when TDD might be less applicable.  For example, in a pool program, one needs to calculate the result of two balls colliding.  The inputs are the balls’ positions and velocities, and the outputs are the balls’ new velocities. (One could add angular velocity to make it a little harder.) So, I offer this as an interesting problem. Can this function be developed by TDD?  If so, what are the steps? Daniel Moka Al Shalloway Rob Myers Justin Beall Tim Ottinger John Crickett

6

38 Comments

15 years ago I contributed 2 chapters to Clean Code(https://a.co/d/5guLEzq), both related to threading. A second edition is coming out, and it occurs to me that while I don't do much direct threaded/parallel programming anymore, many issues around parallel execution still occur in systems where the stack "takes care" of all those details. Here's a collection of recent examples. This is a draft of a personal blog. The second version will go on the Industrial Logic, Inc. website. The final version will likely be added as an update for the 2nd Edition of Clean Code. Comments welcome, enjoy! https://lnkd.in/gWCUkK6V

9

Absolutely wrong. Second only to driving the clarity of your code, tests are notifiers of change. Any change. Yes, behavior is important, but so are the internal semantics at every layer of abstraction in your system. If your tests aren't blowing up when you make a change - any change - you are most definitely doing it wrong.

2

11 Comments

Copilot and development: What activities are easy to automate? Hear what Marcel Chabot - Development Manager at The TM Group, Inc. uses Github Copilot for: - Writing up to 50 lines of code - Clean up long and complex code - Write documentation - Explain what the code does How have you been using Github Copilot to make your job easier? Want to see the full 34min interview? Click the link in the comment section. Dynamics Compass #github #copilot #microsoftcopilot #msdynamics #microsoftdynamics #msdyn365 #d365

2

1 Comment

TLDR, but for CLI programs...uh, yes please! Quickly see a CLI's usage in nicely formatted way with examples. I've added `tldr` program to my toolbelt for sometime now - it quickly gives you the "TOO LONG DIDN"T READ" docs of a CLI program. tldr <CLI_PROGRAM> Checkout https://lnkd.in/eJgyec-f, for macOS you can install it via brew like so: brew install tlrc

2

I've been thinking a lot lately about how dogmatic software engineering is/has-become/always-was(?). I see so many so-called "best-practices" applied on projects that turn into utter disasters. I think I've got a way of reframing software engineering so we can actually have productive dialogs about what actually matters and what is actually harming our projects. If you are an experienced software engineer or project manager, take a look. I'd really like your thoughts and an open discussion on this topic.

5

It’s no secret—I’m obsessed with humanoid robots. Why? Because they’re cool—they’re revolutionizing manufacturing, reshaping the labor force, and pushing humanity forward in ways we’re only beginning to imagine. (and maybe I just need more help in life. Obviously). Here’s what’s happening in the world of my favorite humie heroes: 🤖🚘 Figure has teamed up with BMW, putting their humanoid robots to work in auto manufacturing. 🤖 📦Agility Robotics has introduced Digit, their incredible bot that’s already lending a hand in Amazon warehouses. And of course, there’s 🤖 🎁Tesla’s Optimus, aiming to wrap our Christmas presents (or take over other tedious tasks) by 2025. This article dives deeper into these robotic trailblazers—and my favorite “humies.” Which one’s your favorite? I can't decide, but hopefully you'll weigh in.

8

1 Comment

Super simple explanation of what goes inside the modern processors: https://lnkd.in/gkVtW3vv

3

If you think that keeping track of tools in software development is daunting, you're focusing on the wrong thing. Technologies keep changing, but requirements rarely do. Take version control, for example: we had SCCS in the 1970s, RCS in the '80s, SVN in the early 2000s, and Git and Mercurial after 2005. Yet the core requirement for version control remains the same. The same goes for CI/CD pipelines: CruiseControl in the early 2000s, Jenkins in 2005, then Travis and CircleCI. The need for automation hasn't changed. Infrastructure as code? We had CFEngine in the '90s, then Puppet in the mid-2000s, followed by Chef, Ansible, and now Terraform and CloudFormation. But the fundamental requirement is still the same. So, don't be scared. Focus on understanding the requirements and needs. The rest is just finding the tool that works best for you and reading the documentation.

42

Been doing some actual hands-on coding in the last week plus, and I can't say enough about Claude Dev. It would probably annoy expert coders (too slow and asks for too many approvals) and bewilder non-coders (too fast, makes sweeping changes that you have to approve) but for someone like me who knows what code looks like, wants to understand what the bots are doing (and sometimes redirect them) and can frame good questions about error messages, it is incredible. I've been using Cursor in parallel (including Composer mode) to do bits and pieces of this task, and Claude Dev is really a cut above. And right when I thought it couldn't get better, cached mode showed up and saved me 90% of the API costs lol Check it out, well done Saoud Rizwan: https://lnkd.in/e3NiYkes

5

Working on a specification for https://lnkd.in/g-pBfAQv. Then I can verify it with tests and https://blprnt.tech/. I'm reminded that wormwood is optimized for readable source code, not UX. There is very little syntax validation.

3

‘In this episode of “The Engineering Room” Dave Farley chats with renowned author, speaker and expert software developer Kevlin Henney.’ https://lnkd.in/gsenvBMQ ‘In their wide-ranging discussion they talk about: • Why Kevlin Henney is famous for big public software failures! • Software Engineering, mathematics and the interesting gap between formal programming and sloppy humans. • Architecture, empiricism and three ideas for design. • Coping with incomplete knowledge and making stuff that works in the real world. • Confidence, certainty and loose-coupling. • Learning from actual failure, not just simulation. • Programming is deceptively easy to start, and gets complicated really quickly: Low Code is no exception.’ Continuous Delivery Ltd Bernard McCarty #ContinuousDelivery

21