Steven Pavett

Accidentally discovered a new way to work with GitHub Copilot today: write new tests based off test coverage reports. Copilot (or I) run this command to generate a report of all the uncovered lines in the current diff: pytest --cov --cov-report=xml && \ diff-cover coverage.xml --html-report coverage_report.html && \ open coverage_report.html Then Copilot reviews the report, summarizes the uncovered situations, and proposes new test cases to add, or if the code is truly unreachable, suggests deleting it. Just another reason why you should add diff-cover (or similar tool) to your projects!

115

4 Comments

How does GitHub approach measuring developer productivity, and the impact of AI in their own engineering organisation? With DX. With 150M+ developers using their platform and thousands of engineers building GitHub itself, developer productivity is central to their ability to innovate, attract talent, and deliver value to customers. We're so proud to partner with GitHub as they continue to define the future of software development. Data from DX now informs decisions and investments at every level of the org--from senior leadership to team managers--across AI tools, modern services, and monoliths.

77

5 Comments

Hand-tuning a system to achieve great performance is an anti-pattern. There should be no need to do so. Software exists to solve a problem for you; why should you have to tell it what's the best way for doing so? Instead, systems should be designed to automatically find the right configuration for things like number of elements in a batch, queue and buffer sizes, cache retention, etc. While it's an interesting question whether AI can help with that task, in most cases this isn't needed; classic control theory can do the job, fast, precisely, and cost-effective. As a maintainer of a library, and even more so of managed services, you should push back hard on every new knob, every additional setting, every new parameter for letting the user configure implementation details like that. It substantially reduces usability. It means pushing work to the user instead of having the software do it.

77

29 Comments

Terraform plans are noisy. We made them visual. When a terraform plan has dozens (or hundreds) of changes, it's hard to quickly understand what's going on. We fixed that in the Terrateam UI. Inspired by feedback from Derek Morgan, Terrateam now breaks down plan outputs by resource, showing what will be created, updated, or destroyed, with visual diffs for each field. #terraform

51

2 Comments

This is quality work. So glad to see compiler team digging in and getting a richer picture than “build fast” or “build slow”. I definitely think we need to focus on the perception of rust as having slow builds (and the reality it’s based on), but to do that, we need to be clear on what workflows and use patterns we are targeting. The fix for fast CI turnaround is not the same as the fix for fast iteration on a broken test, and iterating on a test is not the same as debugging a type error. https://lnkd.in/eSKkNgXb

98

The Blitzy platform pre-compiles and pre-tests code avoiding the back-and-forth debugging cycle to deliver working, validated code from day one. Watch the full breakdown with my co-founder Sid Pardeshi at https://hubs.ly/Q03F5DP50

27

When studying database internals at university, I always thought the most important part of building a production query planner is getting the cost-based optimizations right. At TUM, there's actually a whole course that focuses on cost-based join reordering. It's based on Guido Moerkotte's great book "Building Query Compilers". Here are the slides: https://lnkd.in/dcMt56M3 🎓 In that light, rule-based optimizations always seemed like the more basic part of query planning. In the past years at Firebolt my perspective on that has changed a lot. Especially with machine-generated SQL, we often see tons of redundancy that a (very) good rule-based optimizer should eliminate before cost-based strategies even kick in. Andrés wrote a great blog post about how we tackle this at Firebolt through redundant join elimination: https://lnkd.in/dGPU9_dM This is a great piece of writing if you want to learn more about how industry query planners work.

554

17 Comments

‘Mob Programming, also known as Ensemble programming, is an unusual approach to software development. Is it really as crazy as it sounds, or does it really improve the quality and efficiency of the work and help teams to learn more effectively, as teams that practice it claim? So what is mob programming, is this a kind of super-pair-programming or something else, and what is its impact on software development for teams that work this way?’ https://lnkd.in/gidJJxTd ‘In this episode, Dave Farley, author of “Continuous Delivery”, “CD Pipelines” and “Modern Software Engineering” describes how mob programming works, and what impact it has on the teams that practice it. Dave describes his personal experience of working as part of a mob for a day and how his opinion of mob programming was changed.’ Continuous Delivery Ltd Bernard McCarty Tom Farley Modern Software Engineering #ModernSoftwareEngineering

67

3 Comments