# discussion Published articles for discussion. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A critique of arguments for doing more AI DevFeed: [A critique of arguments for doing more AI]() Original publisher: [Read original article]() Author: Sergio Visinoni Published: 2026-07-08T09:16:36Z Content type: opinion Language: en Sources: [Sudo Make Me a CTO]() Topics: [Artificial Intelligence](), [Code review](), [engineering-culture]() Tags: [ai](), [charity-majors](), [code-review](), [discussion]() ### AI overview The article responds to two articles by Charity Majors, examining arguments about AI, resistance to AI enthusiasm, ethical considerations, and the role of code review. It argues that the articles' conclusions remain unconvincing to the author. ### Source excerpt A reaction to two recent popular articles by Charity Majors. Is AI a big deal? Is resistance to AI fundamentalism? Does the solution to the current problems emerge from doing more of it? ## Do not invite big-tech to join your digital autonomy discussion DevFeed: [Do not invite big-tech to join your digital autonomy discussion]() Original publisher: [Read original article]() Published: 2026-06-16T16:00:00Z Content type: opinion Language: en Sources: [Bert Hubert's writings]() Topics: [digital](), [Microsoft](), [amazon](), [Google]() Tags: [amazon](), [digital-autonomy](), [discussion](), [google](), [microsoft](), [tech]() ### AI overview The author argues that events about European digital autonomy should not invite representatives of US big-tech companies to help shape discussions about reducing dependence on big tech. The article says these companies have commercial interests that may lead them to defend existing arrangements, raise doubts, or promote disputed claims about sovereignty, while acknowledging that Europe may continue doing business with them. ### Source excerpt Some time ago, I attended an event to discuss European digital autonomy and digital dependencies. I accepted the invitation without checking too carefully, and I belatedly found out that most of US big tech was invited as well, and would be presenting their thoughts. Now, even in our gloriously digitally autonomous future, we'll still be doing business with Microsoft, Google and Amazon. And it is fine if they have a role. ## Kent Beck and Michael Grinich Discuss AI Adoption and the Future of Software Engineering DevFeed: [Kent Beck and Michael Grinich Discuss AI Adoption and the Future of Software Engineering]() Original publisher: [Read original article]() Author: Kent Beck Published: 2026-05-20T14:15:38Z Content type: opinion Language: en Sources: [Software Design: Tidy First?]() Topics: [Artificial Intelligence](), [future of software](), [Software Engineering](), [engineering-culture](), [dev-tools]() Tags: [ai](), [developer-tools](), [discussion](), [engineering-leadership](), [future-of-software](), [leadership](), [software-engineering]() ### AI overview Kent Beck and Michael Grinich discuss how AI adoption is affecting the broader technology ecosystem, software costs, competition, and engineering leadership. They also discuss enterprise developer tools and the motivation to build software. ### Source excerpt Michael Grinich & Kent Beck on AI adoption, the future of software engineering, and what enterprise developer tools reveal about where tech is headed. ## Academic Chat with Murat and Aleksey: 5 Cs of the Invisible Curriculum. DevFeed: [Academic Chat with Murat and Aleksey: 5 Cs of the Invisible Curriculum.]() Original publisher: [Read original article]() Author: Aleksey Charapko Published: 2025-10-10T22:31:34Z Content type: article Language: en Sources: [Aleksey Charapko]() Topics: [abstraction](), [Continuation]() Tags: [academic](), [collective](), [craft](), [curiosity](), [discussion](), [other-thoughts](), [research]() ### AI overview A discussion about the skills and qualities needed for PhD research, framed around the five Cs: Curiosity, Clarity, Craft, Community, and Courage. It especially considers research taste, levels of abstraction, curiosity, stopping points, and the influence of academic communities. ### Source excerpt Instead of reading papers, last night, Murat and I engaged in an interesting discussion on skills, traits, and qualities needed for a PhD. This discussion came as a follow-up to Murat's recent blog on "The Invisible Curriculum of Research." In his blog, Murat discusses "Curiosity, Clarity, Craft, Community, and Courage" as skills/qualities of a good [...] ## Cumulus: A Cloud-Oriented Version of Elevation of Privilege DevFeed: [Cumulus: A Cloud-Oriented Version of Elevation of Privilege]() Original publisher: [Read original article]() Author: Adam Published: 2023-04-06T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [Cloud](), [version]() Tags: [cloud](), [discussion](), [technology](), [version]() ### AI overview Cumulus is a cloud-oriented version of Elevation of Privilege from TNG Technology Consulting. The article describes its threat categories and assesses them as realistic, broad enough to prompt discussion, and clearly written. ### Source excerpt Cumulus is a cloud-oriented version of Elevation of Privilege ## Making Better Pull Requests DevFeed: [Making Better Pull Requests]() Original publisher: [Read original article]() Author: Eevis Panula Published: 2023-01-03T08:57:47.653000Z Content type: tutorial Language: en Sources: [Eevis Blog]() Topics: [pull-requests](), [Open Source](), [Maintainers]() Tags: [best-practices](), [context](), [contribution](), [discussion](), [maintainers](), [open-source](), [pull-requests](), [review](), [scope]() ### AI overview A tutorial on improving pull requests for open-source projects. It recommends keeping changes in scope, giving reviewers context, including pictures of changes, and using pull requests for discussion while checking each project's contribution guidelines and templates. ### Source excerpt Hactoberfest is here! Time to find those issues and participating repositories, write some code, and create pull requests! I've been eagerly waiting for October, mostly because of Hacktoberfest. Last year, I participated in Hacktoberfest by being a contributor and a maintainer. If you're interested, you can read about my blog post about last year's experiences: Eevis Panula - Story of an accidental open source maintainer This year, I decided to take it a bit easier. I mean, as mentioned in the blog post, last year we bought a house and were moving during October. Another challenging thing from last year was the maintainer part. I loved it, but it really, really stressed me out. So I'm not going to do it this year. And there's another piece to the puzzle this year as well: I'm switching jobs, so that's another reason to take it easy during this Hacktoberfest. One big part of Hacktoberfest is creating pull requests. I remember the first time I made a PR in an open-source repository. I didn't know the repository's maintainers, and it didn't have any guidelines for pull requests, such as a pull request template. I had no idea what the maintainer expected from a PR. I felt super anxious. If I had known back then what I know now, it would've been easier for me. So that's why in this blog post, I'm sharing some tips on how to make better PRs. These are the best practices I've picked up along the way. However, note that there might be some other conventions in the project you're contributing. Be sure to check them. There might be a pull request template or contribution guidelines. The tips I'm going to give are the following: Keep the pull request in scope Give context to the reviewer Add a picture of the changes Pull request is a place for discussion Keep the Pull Request in Scope One reason for keeping the PR in scope is that smaller PRs are always easier to review than those with lots of changes. Sometimes, of course, the feature you are working on is a big one, and thus ## What problem are we trying to solve? DevFeed: [What problem are we trying to solve?]() Original publisher: [Read original article]() Author: Map Published: 2022-11-28T19:23:56Z Content type: opinion Language: en Sources: [Craig Kerstiens]() Topics: [structure]() Tags: [discussion](), [product-management](), [structure]() ### AI overview The article argues that meetings often lose focus when participants lack a clear problem, agenda, structure, or goal. It recommends stating the meeting goal in advance, documenting notes, and asking what problem the group is trying to solve when discussion has drifted. ### Source excerpt If you want to seem like the smartest person in the room, wait for a break in conversation, after sitting quiet for 15 minutes, and ask "What problem are we trying to solve here?" It works every time. We've all been there. You walk into a meeting, there are 10 people in it. It gets rolling, different folks chiming in. A few people seem to be taking personal notes, they always do. There is the person that scheduled the meeting, but they're not the person that usually makes decisions. It's primarily going back and forth between 3 individuals with 7 others watching on. You're 15 minutes in, and while there has been lively discussion already... you find yourself back on the original point from minute 1 seemingly lost 14 minutes and you're unsure to what. A healthier environment ideally has an agenda sent out ahead of time. Based on the agenda there is a clear structure planned for the meeting which presumably points to a clear goal. Even without an agenda an alternative structure would be a clearly stated goal in the invite. Within the meeting you SCQA-it up live. Huge bonus points if the meeting invite includes a link to the notes doc where meeting notes will be transcribed by an explicit scribe for the meeting, sent out after for folks to agree/confirm as a good record of the meeting. As a facilitator as good as you may be, you're still going to end up in the first situation. Every time wait 10-15 minutes, then ask the question. It seems to be more effective after you've had the detour vs. leading off with it in the first 1 minute. Even better internalize the question to yourself vs. just making yourself look good by asking it (which will happen). ## Advice on Managing Imposter Syndrome and Choosing a Software Engineering Team DevFeed: [Advice on Managing Imposter Syndrome and Choosing a Software Engineering Team]() Original publisher: [Read original article]() Author: Rahul Pandey Published: 2022-10-07T15:05:55Z Content type: article Language: en Sources: [Alex Chiou]() Topics: [Software](), [coding]() Tags: [career](), [discussion](), [event](), [manager](), [remote-work](), [risk](), [slack](), [software-engineer](), [startups](), [team](), [video]() ### AI overview This newsletter covers group office hours for Taro Premium members, four ways to address imposter syndrome, and advice on choosing a company and team as a software engineer. It emphasizes priorities, team supportiveness, risk tolerance, and the differences between Big Tech and startups. ### Source excerpt Hey everyone πŸ‘‹πŸ½ Today we'll cover: ## Documenting a Possible Biology Discovery as an Experiment DevFeed: [Documenting a Possible Biology Discovery as an Experiment]() Original publisher: [Read original article]() Published: 2021-08-19T07:27:09Z Content type: opinion Language: en Sources: [Bert Hubert's writings]() Topics: [Computing]() Tags: [computing](), [discovery](), [discussion](), [dna](), [science]() ### AI overview The author reflects on the uncertainty of making a possible discovery in biology as an outsider, describes the value of academic peer feedback, and begins documenting the discovery process to solicit input and maintain pressure to continue. ### Source excerpt So, I think I may have discovered something interesting in biology! Professional scientists know this feeling all too well. Exhilarated that it looks like you might be the first person ever to know something, but worried sick that it might not be real. Also, you might be fooling yourself - and you are the easiest person to fool. And even if it is real, does it even mean something? Or did you effectively discover that hot things are not cold? ## Branch predictor: How many "if"s are too many? Including x86 and M1 benchmarks! DevFeed: [Branch predictor: How many "if"s are too many? Including x86 and M1 benchmarks!]() Original publisher: [Read original article]() Author: Marek Published: 2021-05-05T22:00:00Z Content type: article Language: en Sources: [Marek Majkowski]() Topics: [x86](), [Cloudflare]() Tags: [architecture](), [article](), [benchmarks](), [blog](), [cloudflare](), [discussion](), [hacker-news](), [travis](), [x86]() ### AI overview The article examines how many conditional branches affect branch prediction, with benchmarks covering x86 and M1 systems. It also points to discussions about BTB behavior, M1 branch-predictor interactions with the iCache prefetcher, and related commentary. ### Source excerpt Branch predictor: How many "if"s are too many? Including x86 and M1 benchmarks! I published an article on Cloudflare blog: Notable discussions mentioning this work: - Looking at BTB behavior and size: a comment on my work from Travis Downs, followed by response from Linus Torvalds. - Discussion on M1 architecture, with fascinating take on branch predictor interactions with iCache prefetcher. - Hacker News commentary ## Show me your code: how buildkit can help integrating GoReleaser with multi-arch Docker manifests DevFeed: [Show me your code: how buildkit can help integrating GoReleaser with multi-arch Docker manifests]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2020-04-28T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [Docker]() Tags: [blog](), [discussion](), [docker](), [multi-arch]() ### AI overview A discussion about Docker BuildKit, GoReleaser, and multi-architecture Docker manifests. It also states that future GoReleaser release announcements will be published on the GoReleaser blog. ### Source excerpt A discussion with Tibor and Geanluca about Docker buildkit and GoReleaser. ## Observations from Government, Medicine, and Capitalism DevFeed: [Observations from Government, Medicine, and Capitalism]() Original publisher: [Read original article]() Published: 2019-02-28T01:09:26Z Content type: opinion Language: en Sources: [Jessie Frazelle]() Topics: [digital](), [Microsoft]() Tags: [department-of-defense-dod](), [digital](), [discussion](), [government](), [microsoft]() ### AI overview The author reflects on observing work in government through the Defense Digital Service, medicine by shadowing a surgical resident, and planned observation of private equity. The article highlights differences and parallels in organizational structure, culture, and accomplishment-based incentives. ### Source excerpt I've had a bit of a crazy week. Tuesday, I got a tour of the Pentagon from a friend that is in the US Digital Service (USDS) for the Department of Defense (DoD), called the Defense Digital Service (DDS). Wednesday (the day of writing this), I shadowed a friend who is a surgical resident during their shift in a hospital. Friday, I have plans to shadow a friend who is an investment banker at a private equity firm and will do a follow up post. You can consider this like "Eat. Pray. Love." except it's "Government. Medicine. Capitalism?" First, I would like to thank everyone for sharing a bit of their life with me and now I get to share what I learned from these experiences with you. When I went into this, I didn't think much of it. I wanted to go to DC to see some museums and ended up texting my friend on the way down so we made a day of it. My other friend, who is a surgical resident, and I had once gotten into a pretty deep discussion about how weird tech's culture is compared to theirs so I always had an open offer to see how they work. Then I posted on twitter what I was doing and I guess there was a sort of pattern so it became a thing... Sweet, it's on, Friday I'm going to be a douchey investment banker at Lehman Brothers, no just kidding some private equity firm, but I nailed the joke I'll fit right in ;)https://t.co/yz3EgKD2Ib -- jessie frazelle πŸ‘©πŸΌπŸš€ (@jessfraz) February 27, 2019 Let's dive into what I've learned and observed, then I will try to put a nice ribbon on it and tie it all together for you. Government. Let me start by saying, if you ever have a chance to do a stint at the US Digital Service it seems absolutely amazing. The program is great for tech people who want to have an impact on modernizing technology for the government. Having just left a job at Microsoft, I was quite familiar with a very large organizational structure and the power dynamics that exist in people with titles. It was interesting to me to see the parallel between that and the setup o ## Threat Model Thursdays: Crispin Cowan DevFeed: [Threat Model Thursdays: Crispin Cowan]() Original publisher: [Read original article]() Author: Adam Published: 2018-07-05T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [Security](), [Vulnerabilities](), [Architecture & Design]() Tags: [diagram](), [discussion](), [security](), [trust](), [vulnerabilities]() ### AI overview The article reviews Crispin Cowan's threat-modeling approach, focusing on precise definitions of security principals, attack surfaces, trust boundaries, and security boundaries. It also discusses identifying system connections, assessing complexity, prioritizing mitigations, and documenting threat models. ### Source excerpt [no description provided] ## Threat Model Thursday: Talking, Dialogue and Review DevFeed: [Threat Model Thursday: Talking, Dialogue and Review]() Original publisher: [Read original article]() Author: Adam Published: 2018-04-12T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [Security]() Tags: [design](), [developers](), [discussion](), [operations](), [reviews](), [security]() ### AI overview The article contrasts collaborative, whiteboard-driven threat-modeling dialogue with late-stage threat-model reviews. It argues that dialogue helps teams explore tradeoffs with developers and operations, while reviews often validate completed work or revisit decisions in a judgmental way. ### Source excerpt As we head into RSA, I want to hold the technical TM Thursday post, and talk about how we talk to others in our organizations about particular threat models, and how we frame those conversations. ## Security Engineering: Computers versus Bridges DevFeed: [Security Engineering: Computers versus Bridges]() Original publisher: [Read original article]() Author: Adam Published: 2018-04-11T00:00:00Z Content type: opinion Language: en Sources: [Shostack & Friends Blog]() Topics: [Security](), [Architecture & Design]() Tags: [discussion](), [security](), [security-engineering](), [security-research]() ### AI overview This commentary compares security engineering with bridge engineering, arguing that public criticism, questioning, and investigation of failures are essential to improving designs and advancing the field. ### Source excerpt [no description provided] ## Project Phoebe - starting the discussion on Mutative Design - Tanya Karsou DevFeed: [Project Phoebe - starting the discussion on Mutative Design - Tanya Karsou]() Original publisher: [Read original article]() Published: 2015-12-08T18:51:34Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Simulation and Design](), [interfaces](), [Users]() Tags: [android](), [design](), [designer](), [discussion](), [exploration](), [interfaces](), [project](), [thoughts]() ### AI overview This article introduces Project Phoebe, an exploration of Liam Spradlin's Mutative Design methodology. The approach aims to create interfaces that adapt to users' differing realities rather than designing for averages, while acknowledging that the concept may not yet be feasible to build. ### Source excerpt Our designer Liam Spradlin has just released Project Phoebe, an exploration of design methodology that seeks to solve the problem, designing for averages. ## The Rule of Thirds: A Follow-up on Heroku Postgres Team Planning DevFeed: [The Rule of Thirds: A Follow-up on Heroku Postgres Team Planning]() Original publisher: [Read original article]() Author: Map Published: 2013-08-13T20:55:56Z Content type: opinion Language: en Sources: [Craig Kerstiens]() Topics: [Heroku Postgres](), [data](), [Users]() Tags: [customers](), [data](), [discussion](), [heroku](), [heroku-postgres](), [teams]() ### AI overview This follow-up explains how the Heroku Postgres team uses the Rule of Thirds as an approximate prioritization exercise. It recommends gathering customer and market data, discussing that information informally, and collaboratively collecting and organizing feature ideas. ### Source excerpt Several months back I wrote about how we do higher level, long term planning within the Heroku Postgres team. If you haven't read the previous article please start there. The exercise or rule of thirds is intended to be approximate prioritization and not a perfect science. Since that time I'm familiar with some teams both in and out of Heroku who have attempted this exercise with varying levels of success. We've now done this process 4 times within the team and after the most recent exercise attempted to take some time to internalize why its worked well, creating some more specifics about the process. Heres an attempt to provide even more clarity: Gather data ahead of time Its really common to have a list things to work on, but knowing the impact of those is commonly pure speculation. There may be some people that talk to customers, but even then its a subset of your actual customer base. Going into the exercise as much data you can have ahead of time on impact of features and specific problems helps. In our case we do this by: Surveying current customers and users Surveying attriters Engaging with customer facing teams to hear trends Input from external parties such as analysts on trends Allow for casual discussion We typically conduct our planning exercise at an offsite, this is a multi-day time of team bonding, planning, hacking. We intentionally schedule our planning excercise towards the end of the offsite. This allows us to have updates/presentations frmo the data we've gathered and from those that are customer facing. Presentations are meant to be short and direct, discussion can flow casually after. This gets a lot of people on the same page at a smaller level and reduces the problem of too many cooks in the kitchen come time for the actual exercise. The rule of thirds Creating the list Coming to the exercise itself... We begin by everyone writing a list of their ideas individually, this is meant to be a list of the features we want to place on the grid. At th