Itamar Friedman, CEO and cofounder of CodiumAI, and Kyle Mitofsky, a Senior Software Engineer on Stack Overflow’s public platform, join the home team for a conversation about code integrity and how AI tools are changing the way developers work.

Episode notes:

CodiumAI plugs into your IDE and suggests meaningful test suites as you code. See what they’re up to on their blog or scope out their open roles. You can also follow them on Twitter.

Connect with Kyle on Linked, Twitter, or GitHub.

Connect with Itamar on LinkedIn.

Today’s Lifeboat badge is awarded to Héctor M. for answering Convert a string to a Boolean in C#. Thanks for spreading some knowledge.

TRANSCRIPT

The post Stress test your code as you write it (Ep. 581) appeared first on Stack Overflow Blog.

From the blog

What developers with ADHD want you to know stackoverflow.blog
For this followup post, we spoke with two Stack Overflow software engineers with ADHD about their experiences being diagnosed as adults, taking medication, and communicating about their ADHD at work.

Self-healing code is the future of software development stackoverflow.blog
Developers love automating solutions to their problems, and with the rise of generative AI, this concept is likely to be applied to the creation, maintenance, and the improvement of code at an entirely new level.

How to keep your new tool from gathering dust stackoverflow.blog
If you’re thinking about rolling out a new tool to your team, you should also be thinking about how to get colleagues and management on board, how to embed that tool in your everyday workflows, and how to assess whether it’s working as it should. Tech that solves human problems needs humans to participate in those solutions.

MosaicML: Deep learning models for sale, all shapes and sizes (Ep. 577) stackoverflow.blog
Ben and Ryan talk with Jonathan Frankle and Abhinav Venigalla of MosaicML, a startup trying to make deep learning and generative AI efficient and accessible for everyone.

Dev Tool Focus: gitStream (pull request labels and routing) promotion
Reviewing pull requests is not…fun. But it can be more efficient with the use of gitStream’s novel workflow automation that adds custom labels (ex. Estimated review time) and even assigns code experts (better than CODEOWNERS). Try gitStream today for free!

Interesting questions

Has there ever been a C compiler where using ++i was faster than i++? retrocomputing.stackexchange.com
It’s the whole reason ++C was created.

How did the shift from constructed mathematical objects to modern mathematics occur? hsm.stackexchange.com
When mathematicians switched from “impossible to solve” to “the solution is impossibility.”

Is there a general theory of intelligence and design that would allow us to detect the presence of design in an object based solely on its properties? philosophy.stackexchange.com
Consider the microchip: Without knowing the purposes of a chip, it’s difficult to investigate its structure.

False proofs that look correct cs.stackexchange.com
Perilous proof pitfalls present ponderous programming puzzles.

Links from around the web

Tech debt metaphor maximalism apenwarr.ca
Tech debt is a metaphor for financial debt, and this essay extends that metaphor out to its logical extreme.

What’s new in CSS – WWDC23 developer.apple.com
Check out the new layout and typography features in CSS!

The case of the two billion characters long string giodicanio.com
Weird things can happen when you misinterpret a string pointer, but Assembly can help!

Rotate your file funct.app
If you’ve ever wanted to send a file securely, here’s a useful tool that’ll help you do so. Check out the handy little FAQ to see how it works!

Spending hours searching for answers at work? Find them faster in Stack Overflow for Teams. Get it free!

The post The Overflow #182: Self-healing code appeared first on Stack Overflow Blog.

On today’s episode, we chat with Marcos Grappeggia, the product manager for Duet, an AI-powered assistant that can help you craft code by suggesting snippets—even full functions—as you write. Grappeggia explains why he thinks tools like this will augment, but not replace, the human developers at work today.

Episode notes:

Interested in trying Duet? You can get on the waitlist here.

You can learn more about tuning and deploying your own version of Google’s foundation models in their Generative AI studio.
If tuning a model sounds like a stretch, you can head to Model Garden, where a wide selection of open-source and third-party models are available to try.

TRANSCRIPT

The post Pair programing? We peek under the hood of Duet, Google’s coding assistant. (Ep. 580) appeared first on Stack Overflow Blog.

Down the rabbit hole we go: Do professionals trust AI?

The reality is that developers are already using AI. 44% of them use AI tools in their development process now, and 26% plan to soon. Even more of those learning to code (55%) are currently using AI tools, and these early adopters will become established AI users once they settle into a professional developer position. 

While a growing number of developers are using AI tools, they aren’t using a wide variety. We asked developers which tools they were using, and out of the 21 options we listed this year, a vast majority are just using the two popular products: ChatGPT (83%) and GitHub Copilot (56%). Professional developers may need time to adjust existing workflows, and will most likely be motivated by their junior colleagues who are using AI tools while learning to code.

It’s early days in the hype cycle for these newer AI technologies. We expect that a little more time may need to pass before we see developers using more AI tools more broadly. Another factor that may be contributing to the slow adoption of AI tools into the development process is that professional developers don’t highly trust the accuracy of AI tools. Of those using or planning to use AI tools, only 3% highly trust the accuracy they provide, and twice as many (6%) highly distrust them. While the majority (39%) are somewhat trusting of AI tools, this response tells us that AI tools still need to prove their usefulness. 

When it comes to important matters like school or work, these new tools are not an easy button, and the axiom “trust but verify” is most likely the best approach to integrating new tools in the development process. On the AI Stack Exchange site, one of the most-visited questions so far this year is “Why is ChatGPT bad at math?” The question deals with the inability of AI tools, specifically those trained on large language models, to understand complex questions. But people get these sorts of problems wrong regularly, as well. 

Where you are currently working also has an impact on whether or not you are using AI tools. Professional developers from India, Brazil, and Poland are most likely to use or plan on using AI tools as part of their development workflow—all responding at 70% or higher. UK, French, US, and German developers are more likely to say they don’t plan on using AI tools (responding at 36% or higher). A lot of new tech talent is being sourced from India and Brazil, a trend inferred from the large number of young developers in high salary-growth positions as reported in past developer surveys, so more prevalent use of AI tools in these regions makes sense. 

Why would the EU countries and the US be more likely to report resistance to AI tools? Recent news has highlighted the possibility of imminent EU regulations for AI via pre-existing GDPR laws, and France has already begun investigating complaints against ChatGPT. In the US, no regulations currently exist, but companies are beginning to publicize their policies for banning ChatGPT at work, while Stack Overflow and Reddit have also publicly stated that they will start charging for data access to protect the attribution and contributions of their communities. Accuracy concerns and rules, whether legal or in the workplace, are keeping developers from rapidly adopting some AI tools.

Curiouser and curiouser: Why use AI tools at all?

Regardless of current use and intentions to use later, developers are positive about the possibilities.  Most feel favorable (77%) towards using AI tools as part of their development workflow—but we do see some differences between groups. Blockchain developers, data scientists, and front-end or fullstack developers are more likely to be using AI tools now. Embedded application developers, desktop/enterprise developers, and hardware engineers are less likely to be using these tools and less inclined to use them in the future.

AI has a complexity cliff. Much like Helmsman’s complexity cliff, a concept found in project management, after a certain point, the ability for AI to handle all the nuances and interdependencies of a solution drops off. That’s when humans, their adaptability to apply judgment and have original thought, saves the day.   

Out of all the developer roles who have a favorable view of AI tools, senior executives top the list (63%) alongside data scientists and blockchain developers.  Developers working in data science and blockchain using AI makes sense: they are well-versed in this type of technology. It makes even more sense when we see the response to our question about what use cases developers have for AI tools they’re using today. The overwhelming majority use AI tools to write code (83%) or debug code (49%). We’d expect hardware engineers not to use AI for now, given their low confidence in these tools’ accuracy and the hands-on aspects of their job.  When we asked developers about the benefits of AI tools, 33% believe increasing productivity is the most important benefit.  Senior executives that do not have direct experience with these use cases may be in positions to see their colleagues’ explorations with productivity around writing and/or debugging code and want to try it out within their team or share amongst other people managers.  

We asked developers how they thought AI tools would evolve their workflow over the next year, and 77% feel that the next year will look somewhat or very different for writing code with AI, and 75% feel the same about debugging code with AI. Updating the tools and evolving the learning curve will likely benefit those currently using AI tools or planning to soon. 

The age of AI-integrated development is still in its infancy, but developers around the world have let us know that they are actively engaged, curious, and not looking away. Make sure to check out all the wonderful details at Stack Overflow Labs!

The post Hype or not? AI’s benefits for developers explored in the 2023 Developer Survey appeared first on Stack Overflow Blog.

We also took a look at the real sentiments behind this year’s surge in AI popularity. Is it making a real impact in the way developers work or is it all hype? Head over to the blog post for a recap of the top insights, but check out Stack Overflow Labs for the deep dive details.

The times, they are a-changin’ 

For those that are very early or very late in their coding careers, or just prefer other methods of online learning besides Stack Overflow, it’s safe to assume we may be under-indexing those folks.  Our top five key territories are the same as previous years with a slight shift in which countries are offering the top number of responses: the U.S. is consistently the number one country for responses, but this year we saw India drop from the second highest response rate to third place behind Germany.  Over two years, we have seen the responses from India drop 50% while responses from Germany have grown by 30%.  Indian developers taking the survey this year are skewing a little younger (89% under 34) compared to the age distribution of all respondents (62% under 34) so we may be missing responses from a segment of more experienced developers in India.  Overall, the age distribution has moved slightly older this year with 37% of respondents aged 35 or older compared to 31% last year.  

Among the top ten programming languages this year, we see three popular languages increase their standing: Python, Bash/Shell (all shells), and C.  

We know from tracking tags on Stack Overflow that Python has been growing in popularity for the last three years, and this year it’s moved up one spot to take number three. Along with the rise in Python’s popularity, we consistently see Python libraries rank highly in our popular “Other technologies and frameworks” section—NumPy and Pandas have been in the top ten for the last three years.  

C is an interesting language to see rise in popularity: it has not been in the top ten for programming languages in the Developer Survey before despite being around since the 1970’s.  The TIOBE index has C as the second most popular programming language as of June 2023 and has engagement numbers close to their number one language, Python.  Given that C is one of the most popular low-level languages, it’s the language of choice in embedded programming within IoT devices,  and it “powers almost every technological experience we have” according to Codecademy, it makes sense that developers are using C more than ever this year. 

The more popular a programming language is, the less experience on average we see reported from developers this year (around ten years for our top three languages, and closer to 14 years for those languages reporting less than 1% usage).  Less experienced developers reporting higher usage of some programming languages possibly strengthens the argument that a lower barrier of entry into the job force increases their popularity among coders.

Overall, the baseline for salary growth in 2023 was 10% over last year.  When controlling for comparable years of experience, we see a wide range of growth and decline amongst the programming languages (as much as 42% growth and 69% contraction year-over-year).  If we take a language’s popularity as a proxy for prevalence of developers in the labor market, then we could assume that salaries for popular languages will fall and less popular ones will rise. Our top three most popular languages—JavaScript, HTML/CSS and Python—all saw negative growth in median salary (ranging from 5-10% contraction) while the three least popular languages we can match to comparable experience—APL, Crystal and SAS—we see even less salary growth (ranging from 8 to 80% contraction).  But if we look at the same languages but adjust for less than average experience (for example, 5 years less experience than average per programming language), we see marginal growth for our top three and double-digit growth for APL and Crystal (SAS was filtered from the results for not having enough responses).  What we surmise is that developers’ negotiating power has been affected this year and those with a few less years of experience and working in more niche languages have more salary upside this year than developers with more experience in more popular programming languages. 

Get inspired by technologies admired and desired 

This year, we added a new section to the survey results for technology trends for those who have used or want to use programming languages, tools, environments, libraries, etc., that we have dubbed “Admired and Desired”.  Developers discover new technologies via Stack Overflow or their network, blogs, online forums, etc., and based on preliminary research, would like to try them out.  Once a developer has had a chance to try said technology out, how many of them would still want to use it?  

To better gauge hype versus reality, we created a visualization that shows the distance between the proportion of respondents who want to use a technology (“desired”) and the proportion of users that have used the same technology in the past year and want to continue using it (“admired”).  For those with wide distances between them (and the admired metric remaining on the larger end of the scale), we can infer that momentum generated by the hype grows with hands-on use. With shorter distances, we can infer that the hype is doing much of the heavy lifting as far as general popularity is concerned.  For example, we can see JavaScript, ranked as most popular programming language since 2011, has a relatively short distance between admired and desired (<10 percentage points), while Rust, a top choice for developers who want to use a new technology for the past eight years, shows a wide distance (>60 percentage points); Rust is a language that generates more desire to use it once you get to know it than JavaScript.  Seeing this growth in admiration for certain technologies gives us insight into what has staying power and what needs help in order to generate coveted evangelists to convert new users into ones that will stick around. 

Do admired technologies equate to financial security, as well?  The top admired programming languages (>70% who have used them in the past year want to continue using them)—Rust, Elixir, and Zig—all have 20% or more higher salaries than the overall median developers in 2023 (roughly $75K annually). There is certainly not a direct correlation between salaries and the admiration factor since we see Python, TypeScript, and HTML/CSS all have admiration scores above 60% but only make marginally better annual salaries than the overall median.  Perhaps part of the devotion to some of these popular and admired programming languages is the confidence developers attain by having that lower barrier to entry mentioned earlier; programmers can become sufficient and hired with less experience and get the benefit of so many online resources and Stack Overflow answers to help continue their learning process.

We have a video where we take you through our favorite highlights from the 2023 Stack Overflow Developer Survey. We started out trying to make this a 10-minute video, but we had so much to share…check it out here.

The post 2023 Developer Survey results are in: the latest trends in technology and work from the Stack Overflow community appeared first on Stack Overflow Blog.

Jim Highsmith, an original signatory on the Agile Manifesto, tells Ben and Ryan about what software development looked like at the time of the Apollo program, the evolution of user interface, and the meeting where “17 adventurous techies changed the world.” Plus: How a savvy shoe choice helped introduce Agile to Nike.

Episode notes:

Jim is a pioneering software developer who was one of 17 original signatories to the Agile Manifesto. 

His first engineering job was on a little NASA program you may have heard of: Project Apollo.

His latest book is Wild West to Agile: Adventures in software development evolution and revolution; get your copy here.

Find Jim on LinkedIn or his website.

Today’s Lifeboat badge winner is nCod3d for answering How can I find how many useful digits are in any given a number N?. Thanks for spreading some knowledge.

TRANSCRIPT

The post The meeting that changed how we build software (Ep. 579) appeared first on Stack Overflow Blog.

From the blog

More on our AI future: building course recommendations and a new data platform stackoverflow.blog
Our senior data scientist goes deep in talking about how we built our course recommendation engine.

CEO Update: Paving the road forward with AI and community at the center stackoverflow.blog
With all the significant changes in the industry, one thing has remained the same: companies are committed to driving productivity and efficiency throughout their organizations, and we continue to help our customers and community deliver both.

Building a safer community: Announcing our new Code of Conduct stackoverflow.blog
Since we last updated our Code of Conduct in 2019, the world has shifted dramatically. Hear from our VP of Community as we dive into our newest updates to the Code of Conduct.

This product could help build a more equitable workplace (Ep. 575) stackoverflow.blog
Today’s guest is Ilit Raz, founder and CEO of Joonko, which aims to build a more equitable workplace by automating the recruitment of diverse talent from underrepresented communities.

Is the document data model right for building your next app? promotion
The flexibility of the document model lets you shape data at every stage of development and benefit from the best structure that fits your needs. Watch on-demand “Intro to Data Modeling” to learn design patterns and use cases for the document model.

Interesting questions

Do stars become more metal-rich as they evolve? astronomy.stackexchange.com
It takes a big star to make real heavy metal.

Can you be fired for refusing to lie? law.stackexchange.com
Liar, liar or you’re fired?

Code readability or easy-to-debug? softwareengineering.stackexchange.com
Why not both? Both is good.

Would sending audio fragments over a phone call be considered a form of cryptology? crypto.stackexchange.com
Using pig latin might be more secure.

Links from around the web

Using the Y-axis to maintain focus and attention www.chrbutler.com
When you’re displaying information, you want to anchor the most important stuff just right.

useHooks usehooks.com
React is ten years old now. If you’re still getting the hang of it, here’s a great resource for modern hooks that you can use (that’s a pun).

Big tech’s biggest bets (or what it takes to build a billion-user platform) www.matthewball.vc
Here’s a deep dive into what the big tech companies decide to work on and the challenges they face when they do.

Email addresses are not primary user identities ntietz.com
A lot of software treats email addresses as immutable, forever entities, when that’s simply not true. Here’s a case study of how this can go wrong, and how you should handle emails in your applications.

Join a live webinar to learn the proven strategies for getting adoption and buy-in of new tools so that your team will use them to collaborate and be more productive. Register now!

The post The Overflow #181: More on our AI future appeared first on Stack Overflow Blog.

Today is a special episode recorded at Apple’s campus in Cupertino as part of this year’s WWDC. We got the chance to sit down with the folks who help to build Apple’s developer tools and discuss their newest releases, plus a hint of how they hope developers will create apps for their new headset and the world of spatial computing.

Episode notes:

Our guests today are Christopher Thielen, product manager for languages and frameworks at Apple, and Josh Shaffer, a Senior Director of Software at Apple with a focus on Swift frameworks. 

We discuss the introduction of Swift Macros, improving widgets with App Intents, and some of the new paradigms for crafting apps in visionOS.

If you want to get the full picture of all the updates Apple announced for software developers, you can watch this year’s State of the Union or dive into particulars with 175 different videos focused on key elements of the announcements.

TRANSCRIPT

The post Chatting with Apple at WWDC: Macros in Swift and the new visionOS (Ep. 578) appeared first on Stack Overflow Blog.

But for any piece of tech to work as intended, you have to make sure everyone on the team agrees on using this technology to solve that problem.

If you’re thinking about rolling out a new tool to your team, you should also be thinking about how to get colleagues and management on board, how to embed that tool in your everyday workflows, and how to assess whether it’s working as it should. Tech that solves human problems needs humans to participate in those solutions.

However passionate you might be, declaring that Tool X will improve every aspect of every business process is unrealistic, and unlikely to earn you the support of your colleagues and managers—especially if you’re asking them to learn something new or tweak their workflows to accommodate a tool whose value they’re not convinced of. 

Particularly when budgets are tight, many companies scrutinize tool usage to make sure they’re spending money wisely, not wasting it on shelfware—software you buy but never use. If your team isn’t aligned around the need for a new tool, adoption will probably be underwhelming, and your solution will end up gathering metaphorical dust.

In this article, we’ll lay out some strategies for keeping your new tool from becoming shelfware.

Focus on use cases

You can make a more compelling case for adoption by identifying the most impactful use case for your solution and leading with that. Aligning yourself from the beginning with a specific process like cloud migration or product releases can also help you articulate and demonstrate the value of a new tool. 

In a recent post on our blog, Chelsea Troy, a staff data engineer at Mozilla, suggests starting by talking about the problem you’re trying to solve (“We get so many notifications that we miss important alerts and aren’t able to focus on our work”) rather than centering your proposed solution (“Look at this neat tool I found for managing alerts”).

Another tried-and-true method of showcasing a tool’s value and sparking interest among the wider org is to roll it out first to one or two teams in a pilot, like Dropbox did with Stack Overflow for Teams.

Identify your advocates

A successful tool adoption starts with the early adopters, who play a critical role in demonstrating a tool’s value and communicating that value throughout the org. These early adopters are your true leaders, says Stack Overflow engineering manager Peter O’Connor. Identify champions at the individual-contributor level: tech leads or stack engineers who have the knowledge and credibility to drive adoption by demonstrating and socializing the tool’s value.

Once your early adopters are in place, using your tool to solve their problems and telling all their friends about it, it’s time to think about identifying someone in leadership who can serve as an executive sponsor and high-level advocate for your adoption. This person can help ensure that your proposed implementation aligns with your company’s strategic goals, assist in building support and overcoming resistance from other executives, and otherwise provide support and direction to drive adoption. An executive sponsor should understand:

• What problems the new tool can solve, and how that positive change will impact the organization
• Who’s involved in introducing the new tool and how those teams/individuals can support adoption
• How implementation will affect employees, consultants, and customers

To encourage ongoing usage after your initial rollout, it can be helpful to identify power users or advocates who can spread the news about the tool’s value, help others get up and running, and incorporate the tool into your existing workflows.

Build consensus over time

You want people to want to use your tool. For that to happen, you must understand the context of the technical system you’re operating in. “Context is king” when it comes to getting technical teams to make big changes, says Troy: “Who has context on the system is who has power on the team. And that drives more technical decisions than we’d like to admit.”

Understanding that context requires talking to your teammates about what they need—and, more importantly, listening to them. Commit to understanding what your colleagues need and show them that their input matters to you.

Your goal, in Troy’s view, is to create “an environment in which people are able to ask questions and express concerns.” Make your coworkers feel heard, and they’ll be more likely to listen when it’s your turn to speak. This environment, Troy explains, “makes the difference between the big changes that sail through with support and the ones that get stuck in the mud because the team dragged their feet or outright resisted them.”

This view is echoed by O’Connor, the engineering manager at Stack Overflow. Rather than issuing commands and rushing the adoption timeline, he says, teams that roll out new tools successfully ask for input, take time to build consensus, and foster a sense of psychological safety in their teams.

Make adoption frictionless

You can minimize friction around adoption if you invest the time and energy up front to talk with and listen to your teammates, understanding the nature of their pain points and laying out how your solution will improve things. If you come charging in with a fully formulated plan and no interest in a collaborative discussion, teams will be slow to adopt a new tool or simply reject it.

Keep in mind that a tool that fits seamlessly into the ecosystem of tools and processes your team is already using has a much better chance of being adopted enthusiastically than a tool that interrupts an established workflow. That’s one reason why developers tend to adopt our paid platform quickly and easily when our customers introduce it: they’re already used to turning to Stack Overflow’s public platform when they get stuck.

In a previous role, my colleague Ryan Donovan saw firsthand how reluctant people are to use a new tool if it introduces clunkiness to their workflow. He was tasked with helping the engineering org adopt a Q&A product, but people primarily went to Slack for questions. 

“Nobody was using the tool because it had a lot of proscriptive processes around it,” said Donovan. “First, all the questions were routed through pre-selected categories that we selected instead of letting the people with the questions select tags. Second, while the new tool had a Slack integration, leadership wanted to route questions to new channels specifically created to host questions. Both of these demanded workflow changes. No surprise that everyone still asked their questions in the team channels.” 

Say no to shelfware

You may have noticed that many of the strategies we recommend here come into play before the tool is actually rolled out. That’s because the best way to avoid shelfware is to do your homework ahead of time: 

• Learn where your tool can have the biggest impact
• Enlist advocates to demonstrate and socialize your tool
• Build consensus over time
• Minimize friction around adoption

To learn more about making tool adoption successful, register for our upcoming webinar: Five ways to drive tool adoption and avoid the dreaded “shelfware.”

The post How to keep your new tool from gathering dust appeared first on Stack Overflow Blog.

While the field is still developing fast, and factual errors, known as hallucinations, remain a problem for many LLM powered chatbots, a growing body of research indicates that a more guided, auto-regressive approach can lead to better outcomes.

This gets really interesting when applied to the world of software development and CI/CD. Most developers are already familiar with processes that help automate the creation of code, detection of bugs, testing of solutions, and documentation of ideas. Several have written in the past on the idea of self-healing code. Head over to Stack Overflow’s CI/CD Collective and you’ll find numerous examples of technologists putting this ideas into practice.

When code fails, it often gives an error message. If your software is any good, that error message will say exactly what was wrong and point you in the direction of a fix. Previous self-healing code programs are clever automations that reduce errors, allow for graceful fallbacks, and manage alerts. Maybe you want to add a little disk space or delete some files when you get a warning that utilization is at 90% percent. Or hey, have you tried turning it off and then back on again?

Developers love automating solutions to their problems, and with the rise of generative AI, this concept is likely to be applied to both the creation, maintenance, and the improvement of code at an entirely new level.

More code requires more quality control

The ability of LLMs to quickly produce large chunks of code may mean that developers—and even non-developers—will be adding more to the company codebase than in the past. This poses its own set of challenges. 

“One of the things that I’m hearing a lot from software engineers is they’re saying, ‘Well, I mean, anybody can generate some code now with some of these tools, but we’re concerned about maybe the quality of what’s being generated,’” says Forrest Brazeal, head of developer media at Google Cloud. The pace and volume at which these systems can output code can feel overwhelming. “I mean, think about reviewing a 7,000 line pull request that somebody on your team wrote. It’s very, very difficult to do that and have meaningful feedback. It’s not getting any easier when AI generates this huge amount of code. So we’re rapidly entering a world where we’re going to have to come up with software engineering best practices to make sure that we’re using GenAI effectively.”

“People have talked about technical debt for a long time, and now we have a brand new credit card here that is going to allow us to accumulate technical debt in ways we were never able to do before,” said Armando Solar-Lezama, a professor at the Massachusetts Institute of Technology’s Computer Science & Artificial Intelligence Laboratory, in an interview with the Wall Street Journal. “I think there is a risk of accumulating lots of very shoddy code written by a machine,” he said, adding that companies will have to rethink methodologies around how they can work in tandem with the new tools’ capabilities to avoid that.

We recently had a conversation with some folks from Google who helped to build and test the new AI models powering code suggestions in tools like Bard. Paige Bailey is the PM in charge of generative models at Google, working across the newly combined unit that brought together DeepMind and Google Brain. “Think of code produced by an AI as something made by an “L3 SWE helper that’s at your bidding,” says Bailey, “and that you should really rigorously look over.” 

Still, Bailey believes that some of the work of checking the code over for accuracy, security, and speed will eventually fall to AI as well. “Over time, I do have the expectation that large language models will start kind of recursively applying themselves to the code outputs. So there’s already been research done from Google Brain showing that you can kind of recursively apply LLMs such that if there’s generated code, you say, “Hey, make sure that there aren’t any bugs. Make sure that it’s performant, make sure that it’s fast, and then give me that code,” and then that’s what’s finally displayed to the user. So hopefully this will improve over time.”

What are people building and experimenting with today?

Google is already using this technology to help speed up the process of resolving code review comments. The authors of a recent paper on this approach write that, “As of today, code-change authors at Google address a substantial amount of reviewer comments by applying an ML-suggested edit. We expect that to reduce time spent on code reviews by hundreds of thousands of hours annually at Google scale. Unsolicited, very positive feedback highlights that the impact of ML-suggested code edits increases Googlers’ productivity and allows them to focus on more creative and complex tasks.”

“In many cases when you go through a code review process, your reviewer may say, please fix this, or please refactor this for readability,” says Marcos Grappeggia, the PM on Google’s Duet coding assistant. He thinks of an AI agent that can respond to this as a sort of advanced linter for vetting comments. “That’s something we saw as being promising in terms of reducing the time for this fix getting done.” The suggested fix doesn’t replace a person, “but it helps, it gives kind of say a starting point for you to think from.”

Recently, we’ve seen some intriguing experiments that apply this review capability to code you’re trying to deploy. Say a code push triggers an alert on a build failure in your CI pipeline. A plugin triggers a GitHub action that automatically send the code to a sandbox where an AI can review the code and the error, then commit a fix. That new code is run through the pipeline again, and if it passes the test, is moved to deploy. 

“We made several improvements in the mechanism for the retry loop so you don’t end up in a weird scenario, but that’s the essential mechanics of it,” explains Calvin Hoenes, who created the plugin. To make the agent more accurate, he added documentation about his code into a vector database he spun up with Pinecone. This allows it to learn things the base model might not have access to and to be regularly updated as needed. 

Right now his work happens in the CI/CD pipeline, but he dreams of a world where these kind of agents can help fix errors that arise from code that’s already live in the world. “What’s very fascinating is when you actually have in production code running and producing an error, could it heal itself on the fly?” asks Hoenes. “So you have your Kubernetes cluster. If one part detects a failure, it runs into a healing motion.” 

One pod is removed for repairs, another takes its place, and when the original pod is ready, it’s put back into action. For now, says Hoenes, we need humans in the loop. Will there come a time when computer programs are expected to autonomously heal themselves as they are crafted and grown? “I mean, if you have  great test coverage, right, if you have a hundred percent test coverage, you have a very clean, clean codebase, I can see that happening. For the medium, foreseeable future, we probably better off with the humans in the loop.”

Pay it forward: linters, maintainers, and the never ending battle with technical debt

Finding things during CI/CD or addressing bugs as they arise is great, but let’s take things a step further. You work at a company with a large, ever-growing code base. It’s fair to assume you’ve got some level of technical debt. What if you had an AI agent that reviewed old code and suggested changes it thinks will make your code run more efficiently. It might alert you to fresh updates in a library that will benefit your architecture. Or it might have read about some new tricks for improving certain functions in a recent blog or documentation release. The AI’s advice arrives each morning as pull requests for a human to review. 

Itamar Friedman, CEO of CodiumAI, currently approaches the problem while code is being written. His company has an AI bot that works as a pair programmer alongside developers, prompting them with tests that fail, pointing out edge cases, and generally poking holes in their code as they write, aiming to ensure that the finished product is as bug free as possible. He says a lot of tools for measuring code quality focus on aspects like performance, readability, and avoiding repetition. 

Codium works on tools that allow for testing of the underlying logic, what Friedman sees as a narrower definition of functional code quality. With that approach, he believes automated improvement of code is now possible, and will soon be fairly ubiquitous. “If you’re able to verify code logic, then probably you can also help, for example, with automation of pull requests and verifying that these are done according to best practices.”

Itamar, who has contributed to AutoGPT and has given talks with its creator, sees a future in which humans guide AI, and vice versa.  “A machine would go over your  entire repository and tell you all of the best (and so-so) practices that it identified. Then a few tech leads can go over this and say, oh my gosh, this is how we wanted to do it, or didn’t want to do it. This is our best practice for testing, this is our best practice for calling APIs, this is how we like to do the queuing, this is how we like to do caching, etc. It’ll be configurable. Like the rules will actually be a mix of AI suggestion and human definition that will then be used by an AI bot to assist developers. That’s the amazing thing.”

How is Stack Overflow experimenting with GenAI? 

As our CEO recently announced, Stack Overflow now has an internal team dedicated to exploring how AI, both the latest wave of generative AI and the field more broadly,  can improve our platforms and products. We’re aiming to build in public so we can bring feedback into our process. In the spirit, we shared an experiment that helped users to craft a good title for their question. The goal here is to make life easier for both the question asker and the reviewers, encouraging everyone to participate in the exchange of knowledge that happens on our public site.

It’s easy to imagine a more iterative process that would tap in the power of multi-step prompting and chain of thought reasoning, techniques that research has shown can vastly improve the quality and accuracy of an LLM’s output.

An AI system might review a question, suggest tweaks to the title for legibility, and offer ideas for how to better format code in the body of the question, plus a few extra tags at the end to improve categorization. Another system, the reviewer, would take a look at the updated question and assign it a score. If it passes a certain threshold, it can be returned to the user for review. If it doesn’t, the system takes another pass, improving on its earlier suggestions and then resubmitting its output for approval.

We are lucky to be able to work with colleagues at Prosus, many of whom have decades of experience in the field of machine learning. I chatted recently with Zulkuf Genc, Head of Data Science at Prosus AI. He has focused on Natural Language Processing (NLP) in the past, co-developing an LLM-based model to analyze financial sentiment, FinBert, that remains one of the most popular models at HuggingFace in its category. 

“I had tried using autonomous agents in the past for my academic research, but they never worked very well, and had to be guided by more rules based heuristics, so not truly autonomous,” he told me in an interview this month. The latest LLMs have changed all that. We are at the point now, he explained, where you can ask agents to perform autonomously and get good results, especially if the task is specified well. “In the case of Stack Overflow, there is an excellent guide to what quality output should look like, because there are clear definitions of what makes a good question or answer.”

What about you? 

Developers are right to wonder, and worry, about the impact this kind of automation will have on the industry. For now, however, these tools augment and enhance existing skills, but fall far short of replacing actual humans. It appears some of bots have already learned to automate themselves into a loop and out of a job. Tireless agents that are always working to keep your code clean. I guess we’re lucky that so far they seem to be as easily distracted by time consuming detours as the average human developer? 

Technology marches on, but procrastination remains unbeaten. 

We are compiling the results from our Developer Survey and have tons of fascinating data to share on how developers view these tools and the degree to which they are already adopting them into their workflows.

If you’ve been playing around with ideas like this, from self-healing code to Roboblogs, leave us a comment and we’ll try and work your experience into our next post. And if you want to learn more about what Stack Overflow is doing with AI, check out some of the experiments we’ve shared on Meta.

The post Self-healing code is the future of software development appeared first on Stack Overflow Blog.

Ben and Ryan talk with Jonathan Frankle and Abhinav Venigalla of MosaicML, a startup trying to make artificial intelligence efficient and accessible for everyone by lowering the cost, time, and complexity it takes to train a powerful AI model.

Episode notes:

MosaicML is a platform for training and deploying large AI models at scale. Explore their docs, check out their blog, and keep an eye on their open roles.

Jonathan Frankle is the Chief Scientist at MosaicML and an incoming Assistant Professor of Computer Science at Harvard.

Abhinav Venigalla is the NLP Architect at MosaicML.

Today’s Lifeboat badge winner is singmotor for rescuing How to remove columns with too many missing values in Python from the dustbin of history.

TRANSCRIPT

The post MosaicML: Deep learning models for sale, all shapes and sizes (Ep. 577) appeared first on Stack Overflow Blog.

A few months ago, we wrote about the overlap between people with ADHD (attention-deficit/hyperactivity disorder) and people who code for a living. We noted the plethora of online advice by and for programmers with ADHD and the rise in ADHD diagnoses for both kids and adults. And we wondered whether there’s anything to the fairly widespread idea that coding is a particularly good career fit for a person with ADHD. (For our purposes, we’ll use “developer” and “programmer” more or less interchangeably to refer to people whose jobs involve a lot of coding.) 

“Coding can give ADHD brains exactly the kind of stimulation they crave,” writes one full-stack developer. “Not only is coding a creative endeavor that involves constantly learning new things, but also once one problem is solved, there’s always a brand new one to try.”

Of course, when you’re talking about two things as complex as 1) the human brain and 2) computer programming, generalizations like “people with ADHD make great programmers” can only take you so far. Takes like that risk collapsing the experiences of people with ADHD, skimming over individual variations and nuances in favor of an appealing soundbite. 

For this follow up post, we spoke with two Stack Overflow software engineers with ADHD about their experiences being diagnosed as adults, taking medication, and communicating about their ADHD at work. Here’s what developers with ADHD want you to understand.

It’s less superpower, more invisible disability

It can be frustrating for people with ADHD to hear a symptom like hyperfocus referred to as a “superpower,” when in reality hyperfocus has downsides—plus it exists in conjunction with other symptoms that can be much less empowering, like executive dysfunction. 

As someone with an OCD (obsessive-compulsive disorder) diagnosis, I’ve heard similarly frustrating takes: I wish I had OCD so my house could be as clean as yours! (You do not wish this.) Oh, I’m super-OCD too; I color-code my bookshelves. (Not the same!)

In fact, ADHD is an invisible disability, which is exactly what it sounds like: “a physical, mental or neurological condition that is not visible from the outside, yet can limit or challenge a person’s movements, senses, or activities” (Invisible Disabilities Association). Plenty of forms of neurodivergence, including autism spectrum disorder, depression, anxiety, OCD, PTSD (post-traumatic stress disorder), and learning differences can be considered invisible disabilities. 

Sure, developers with conditions like ADHD might occasionally find that an output of their condition gives them an edge. In part one of this series, we recognized that the hyperfocus associated with ADHD—“a state of laser-like concentration in which distractions and even a sense of passing time seem to fade away,” as one developer put it—can help programmers access the sought-after flow state. 

Other developers with ADHD say their thinking style lends itself to creative problem-solving. “One positive aspect of being a dev with ADHD,” explained one engineer we talked to, “is that my brain zooming around different ideas can help with inventiveness and creativity, and seeing things in a different light can really help with solving more difficult problems.” Intersectional thinking FTW.

Still, many developers want to be clear that it’s not all upside. “You get into flow, and you’re being really, really productive,” one software engineer explained, “but on the opposite end of that, time goes by really quickly, and you realize, ‘Oh, crap, I had three other things I promised somebody today, but I just lost a few hours.’” The engineer also pointed out that developers who progress past the senior level or switch tracks into management are no longer responsible for their individual productivity alone; their role is to multiply the productivity of their team. “That’s where executive dysfunction holds me back a lot,” they said.

It’s not the coding; it’s the accommodations

What if it’s not that people with ADHD make good developers; it’s that developers are more likely to have access to the accommodations that make ADHD manageable?

Companies that employ developers, particularly tech companies with flexible and hybrid schedules and robust healthcare coverage, are in a better position to accommodate people with ADHD (and other invisible disabilities) than employers in other industries. 

For instance, when it comes to managing their ADHD at work, one of our engineers stressed the freedom of a job that can be largely asynchronous and remote: “It helps a lot that I have a job that supports flexible hours and isn’t babysitting me all day.” In tech and developer circles, the unfair stigma associated with ADHD and other forms of neurodivergence is beginning to dissipate, as we discussed on the Stack Overflow podcast last year. “I’ve been open about my diagnosis mostly,” said one interviewee. “I might not always refer to it by name, but I definitely bring up things that are relevant when I need to,” such as a need to establish a firm deadline to stay focused.

So a better way of putting the relationship between coding and ADHD might be that (some) coding jobs are likely to give (some) people with ADHD what they need to thrive professionally.

It’s also reasonable to assume that people with reliable, affordable healthcare are more likely to seek out and receive an ADHD diagnosis and the accommodations, including access to medication and therapy, that come with that diagnosis. That’s another reason why it might seem like there’s an overlap between people who code and people with ADHD—US-based developers tend to have good healthcare coverage through their employers.

A diagnosis might be life changing

Both software engineers we interviewed were diagnosed as adults, in both cases in their late 20s after they’d already embarked on their careers. “I was talking to a friend who mentioned she went to a doctor and was surprised to find that she had ADHD,” one of the engineers said. “She talked about the symptoms and I thought, ‘Hmm, that sounds familiar.’”

For both engineers, being diagnosed as adults cast their lifelong experiences in a new light. “I always just thought that I was lazy and had a tendency towards procrastination,” said one engineer. “But once I embraced [my diagnosis] and realized that a lot of stuff I thought was an ‘everyone problem’ was not actually a problem for neurotypical folks, I felt a lot better about myself and about the strategies I needed to cope.” 

Being diagnosed as an adult, said the other interviewee, “is really interesting, because you all of a sudden understand where a lot of your weird traits come from. You realize, ‘OK, that’s why this is hard for me; that’s why I struggle with this or that.”

One interviewee called their ADHD medication “a life-changer.” The other called it “a complete game-changer for me in terms of focus and ability to get things done.” An official diagnosis is generally a necessary prerequisite for ADHD medication, so for many folks, getting a diagnosis is the first big step toward effectively managing their ADHD.

A diagnosis can also give people with ADHD the confidence to ask for accommodations at work or school—and even the awareness to know what kinds of accommodations are available and would benefit them. “A diagnosis definitely helped me at work,” said one engineer. “I haven’t ever asked for formal accommodations, but knowing more about how I personally work—for example, if I don’t have a deadline, it’s basically impossible for me to get it done—has helped me a lot in advocating for myself and my own working style.”

(Neuro)diversity is strength

As we said in part one, dispelling the stigma around neurodiversity requires an open dialogue about ADHD and other forms of neurodiversity or invisible disability. At Stack Overflow, we think everyone benefits when work and the hiring process are inclusive of neurodiverse people. An estimated 15-20% of the population is considered neurodiverse; that’s a lot of talent employers can miss out on if they’re not willing or able to offer certain accommodations. And you never know—the next person on your team to receive an ADHD diagnosis might be you.

The post What developers with ADHD want you to know appeared first on Stack Overflow Blog.

From the blog

How to use marketing techniques to build a better resume stackoverflow.blog
If you want to get the attention of a employer, marketing has the techniques to get you there.

Modern work requires attention. Constant alerts steal it stackoverflow.blog
Attention—the time and freedom to focus—is your team’s most valuable resource.

For those who just don’t Git it (Ep. 573) stackoverflow.blog
Pierre-Étienne Meunier, creator and lead developer of open-source version control system Pijul, joins the home team to talk about version control, functional programming, and why OCaml is a source of French national pride.

How the creator of Angular is dehydrating the web (Ep. 574) stackoverflow.blog
Miško Hevery, creator of Angular and longtime Googler, tells Ben about building the future of web applications in his new role as CTO of Builder.io.

Gamification is a secret weapon when developing APIs promotion
The only constant is change – a company that built a global network by integrating into financial institutions, even before the world wide web was invented, shares how they’re rallying their development teams around an API first approach.

Interesting questions

How to convince management that not all software tools should be internally made? workplace.stackexchange.com
Do you want to be a tools company or is there some other product you’d like to ship?

How do we know the expansion of the universe is not centered around our position? astronomy.stackexchange.com
Discouraging main character syndrome on an astronomical scale.

References on how to interpret significant but dubious results (i.e. small numbers, plus borderline p-value) stats.stackexchange.com
Neither significant nor not significant but a secret third thing.

Can you DDOS a human brain? worldbuilding.stackexchange.com
Five people talking at once in a meeting should do it.

Links from around the web

How companies use dark patterns to keep you subscribed pudding.cool
Sometimes services make it difficult to unsubscribe using less than user-friendly UI techniques.

Eight annoying A/B testing mistakes every engineer should know posthog.com
A/B testing and feature flags are great for determining which features you’re going to release (and how)…if you do them right!

Partnering for a stable web youtu.be
The great browsers of today are working together to establish if a given API is safe to use on your website.

How not to add AI to your product www.fillout.com
AI is incredibly cool…but make sure it actually adds value to your product.

Spending hours searching for answers at work? Find them faster in Stack Overflow for Teams. Get it free!

The post The Overflow #180: The battle for your attention at work appeared first on Stack Overflow Blog.

Cameron Wolfe, Director of AI at Rebuy and deep learning researcher, joins Ben for a conversation about generative AI, autonomous agents, and balancing a PhD program with a tech career. 

Episode notes:

Rebuy is an AI-powered personalization platform. Check out their developer hub, explore case studies, or keep up with their blog.

Cameron is a PhD student in computer science and member of the OptimaLab at Rice University. 

Autonomous agents are AI-powered programs that can create tasks for themselves in response to a given objective. They “can create tasks for themselves, complete tasks, create new tasks, reprioritize their task list, complete the new top task, and loop until their objective is reached,” according to one beginner’s guide to autonomous agents.

Follow Cameron’s work on Twitter or Substack, or his website. Read his publications here.

This week’s Lifeboat badge honoree is Mark Setchell for sharing their knowledge with the world: I need to convert a fixed-width file to ‘comma-delimited’ in Unix.

TRANSCRIPT

The post Balancing a PhD program with a startup career (Ep. 576) appeared first on Stack Overflow Blog.

Before jumping into the details, I first want to thank everyone who worked to come up with our updated Code of Conduct. I appreciate the amazing efforts of our staff, led by our Trust and Safety Manager, Cesar, and Senior Community Manager, Bella_Blue, who steered this effort. I particularly want to recognize the collaboration from the Stack Exchange moderators and community members who provided their feedback over the last few months. 

While we are confident that the updates to the Code of Conduct are a step in the right direction, we also acknowledge that it is not a magical solution that will instantly enhance the quality of discourse across the network. We understand that conflicts and disputes may still arise, and trolls will continue to exist. However, the Code of Conduct will equip us with the necessary tools to remind each other to treat one another with respect and clearly outline our expectations, expressing our vision for a respectful and healthy community.

While we encourage everyone to review the entire Code of Conduct, below are some background and key highlights: 

Dedication to constant improvement

We last updated our Code of Conduct in 2019, and since then, the world has shifted dramatically. Our updated Code of Conduct provides specific guidelines on things like dangerous iconography and harmful political speech, as well as helps ensure conversations around things like public health remain evidence-based. We firmly believe that growth and progress go hand in hand. As we evolve and adapt to the ever-changing landscape, ensuring that our Code of Conduct remains relevant and applicable to the community is a top priority. 

In addition to this commitment to constantly improve the applicability of the Code, we are tracking upcoming regulatory pressures globally (notably from Brazil and the EU), and it is imperative that we reflect those potential requirements in our Code of Conduct.

What to expect from our updated Code of Conduct

Our updated Code of Conduct includes our mission statement, details our expectations for users, and provides details into what is unacceptable behavior as well as instructions on how to report such behavior. You can expect links to a comprehensive set of guidelines that reflect our core values and address the evolving needs of our community. We have thoroughly reviewed and refined the document to ensure it provides clear and actionable guidance for all users.

Enhancing user experience and safety

The Code of Conduct strives to enhance the user experience and ensure the safety of every individual who engages with our platform. Our Code of Conduct includes measures to combat harassment, hate speech, and other forms of inappropriate content, empowering us to create an environment that fosters respect and inclusivity. 

A collaborative effort

A Code of Conduct is a handshake agreement between users and the company and is a collaborative effort that involves the invaluable insights of the community. We have actively engaged with moderators and the community, seeking their perspectives and expertise. Their contributions have been instrumental in shaping this update, ensuring that it reflects the diverse needs and voices of the community.

Thank you for being an integral part of our journey as we continue to evolve, improve, and uphold our shared values. Stay tuned for more updates and announcements as we work together to create a world-class experience for everyone in the Stack Overflow community.

The post Building a safer community: Announcing our new Code of Conduct appeared first on Stack Overflow Blog.

In the last quarter of our fiscal year, which ended on March 31, that meant announcing the availability of Stack Overflow for Teams in the Microsoft Azure marketplace while launching Topic Collectives and Staging Ground Beta 2 on our public platform. But most significantly, we accelerated our AI efforts internally and look forward to sharing more this summer. I’m excited to see how we leverage our domain focus and special community-driven blend of trust, recognition, and accuracy to GenAI.

Profitable growth is the new mantra 

Stack Overflow, and Stack Overflow for Teams, in particular, is well-suited to the industry-wide shift from “growth-at-all-costs” to profitable, sustainable expansion I mention above. 

We continue to evolve as an organization, focusing on a path to profitability in addition to navigating a dynamic external market. Part of this evolution led us to make the difficult decision to reduce our headcount by 10% last month. Through these changes, I remain grateful for our community, which is the basis of everything we do, and for the many Stackers who demonstrate great resilience and live our mission and values each day. 

Every organization is incentivized to add new products and revenue streams using incremental capital. This is a rational approach when top line growth is all that matters and additional investment is widely available. However, in the new world of profitable growth, incremental resources are no longer cheap and accessible. As a result, productivity and efficiency are critical. To continue growing, every company needs to do more with the resources it has, and every employee (not just those in Sales) must understand that their actions impact revenue. 

This is especially important for developers. Often, a new feature or product is the difference between closing a new customer/growing an existing one and seeing deals slip to the next quarter or fall out of the pipeline entirely. In fact, research from McKinsey shows that companies who innovate through crises not only outperform the market by 10% during the crisis but also realize a 30% average long-term gain. 

A company whose innovation strategy I’ve long admired is NI (National Instruments). The company has been developing cutting edge technologies and products since it was founded in the mid 1970s. Today, given the pace of change, that means taking a technology they’ve been developing for a number of years and bringing it to a new tech stack—whether third party or open source—to enable their product development goals.

Since the company adopted Stack Overflow for Teams, as showcased in the video case study below, technologists within NI spend less time waiting for answers and guidance and now have a channel for the “cultural value of collaboration.”

“They are creating this culture on Stack Overflow where it’s become a really safe place to ask a question, a safe place to provide an answer, and try to get people closer to their solution, and I think that’s part of what’s made it really successful and where we found a lot of value.”

In a dynamic world, innovation is a powerful way to grow, yet it has to happen via an increase in productivity, not an increase in spending overall. That makes Stack Overflow for Teams a critical tool for all organizations; we know it accelerates innovation by increasing developer productivity and overall engineering capacity. 

Looking forward to growth and the impact of community on AI

When I think about Stack Overflow’s future, what makes me most excited is how we are innovating, and that’s largely based around the work that we’re doing to incorporate GenAI into our products. 

Part of innovation is exposure to how things could be done differently. If there’s no exposure to how it could be done differently, there’s no learning/experiencing alternative techniques, there’s no innovation. As with the rise of remote and hybrid work at the beginning of the pandemic, those companies who embrace opportunities to leverage generative AI and automation in their everyday work flows in intentional ways that assist the productivity of their workers will be the most successful in this next phase of the modern workplace. Our vision for community and AI coming together means the rise of GenAI is a big opportunity for Stack. Approximately 10% of our company is working on features and applications leveraging GenAI that have the potential to increase engagement within our public community and add value to customers of our SaaS product, Stack Overflow for Teams.  We believe that the developer community can play a crucial role in how AI accelerates, ultimately helping with the quality coming out of GenAI offerings—and in that, further improving the modern workplace as we know it. 

Stack Overflow for Teams is uniquely positioned for this moment. But beyond this clear value prop, what really sets us apart is the strength of the community. The community is often our biggest champion in the enterprise; its members want to use a tool they know and trust to manage their proprietary information and collaborate with peers who are likely familiar with Stack Overflow as well. Community is our competitive advantage and a key reason we remain insulated from the worst of the business cycle’s ups-and-downs. 

We believe GenAI can be a similar competitive advantage for Stack Overflow. We have the domain focus and community trust to responsibly deploy generative AI to improve our existing suite of products and lead to new solutions and revenue streams. An example of where we have already begin to experiment in order to improve the platform is our generative AI tool to suggest better question titles. As our VP of Community points out, the this tool serves three purposes. First, question askers spend less time crafting the perfect title for their questions, and instead can focus on the content of the question. Second, question reviewers are able to better understand the content of the question, making it easier to suggest edits or improve the post. Finally, end users of Stack Overflow can more easily understand if the question is relevant to their needs. This tool is one of many that we are launching in coming weeks.

Our community has given us feedback through the evolution of this tool, and their feedback is critical to how it scales. As the AI landscape continues to evolve, the need for communities that can nurture, inform, and challenge these technologies becomes paramount. These platforms will not only offer the necessary guidance to refine AI algorithms and models but also serve as a space for healthy debate and exchange of ideas, fostering the spirit of innovation and pushing the boundaries of what AI can accomplish.

We want to be able to continue to invest back into our community, and that’s why we’re also exploring what data monetization looks like in the future. LLMs are trained off Stack Overflow data, which our massive community has contributed to for nearly 15 years. We should be compensated for that data so we can continue to invest back in our community. This also boils down to proper attribution. Our data represents significant effort and hard work stored across our site and LLMs are taking those insights and not attributing to the source of that knowledge.  This is about protecting the interest in the content that our users have created as much as it is the fight for data quality and AI advancement. 

Our thesis on community as the center of a safe, productive, and open future for AI also offers some exciting prospects for our business. Stack Overflow for Teams, our enterprise, private version of Stack Overflow, helps to power a community-driven knowledge base inside of 15K+ organizations like Box, Microsoft, and Liberty Mutual. Decades of institutional knowledge, shaped and curated by subject matter experts and experienced teams, allows the employees at these organizations to more easily collaborate, improving productivity and trust.

There is no doubt that code will be created more quickly and the volume is likely to explode with code completion tools and the need for trust will increase. Stack Overflow for Teams is essential for keeping up with the pace of change. It allows SMEs to review complex code, warn of risks and cascade and ensure adherence to company standards and policies. With the community as our foundation, Stack Overflow for Teams as our growth engine, and GenAI as our accelerator of the future, we are well-positioned to grow no matter the environment around us. 

Stack Overflow for Teams now available in the Microsoft Azure Marketplace

Despite our focus on the future, we accomplished a lot over the last several months. High on that list of accomplishments is our partnership with Microsoft, which is making our SaaS solution more easily accessible than ever before. The addition of Stack Overflow for Teams in the Azure Marketplace is the latest expansion of our relationship with Microsoft and follows the launch of the Microsoft Azure Collective on Stack Overflow. 

With Stack Overflow for Teams in the Azure Marketplace, Stack Overflow customers can now take advantage of the scalability, high availability, and security of Azure while streamlining deployment and management. That means developers and technologists can access the institutional knowledge they need while having the ability and digital space to collaborate and build innovative features quickly—rather than wasting countless hours searching for an answer to or expert on a problem that was seconds away from their fingertips.

After the launch of the Azure Collective on Stack Overflow and the existing integration between Microsoft Teams and Stack Overflow for Teams, our availability in the Azure Marketplace was an exciting and logical next step.

Staging Ground Beta 2 and finding your sub-community

In addition to making it easier for customers to deploy Stack Overflow for Teams, we’re also working to make it easier for individuals to join the Stack Overflow community and find their place within it. 

Staging Ground is a key part of this effort, and I discussed it briefly in my last blog post. Since then, this new public platform feature, which allows new askers to receive guidance from more experienced community members before posting their first questions publicly, has completed Beta 1 and entered Beta 2. 

Beta 2 expands on the success of Beta 1 with a wider release, comment templates and guidelines for reviewers, and a new UI, among other improvements. We hope to confirm our findings from Beta 1, which found—among other things—that questions approved in Staging Ground had an 85% greater success rate than their non-Staging Ground counterparts. 

Perhaps most importantly, we hope that Staging Ground can help us welcome and grow the next-generation of technologists by exposing them to mentorship from more experienced users and moderators. One community member summed up our ambitions nicely when they said, “I found it surprisingly satisfying to help a new asker learn how to turn a poorly-asked question into a well-asked one.” 

I’m excited for Staging Ground Beta 2 to continue our progress making it simple and efficient to access the wealth of knowledge and experience the Stack Overflow community contains. 

The launch of Topic Collectives: R and CI/CD

Topic Collectives also seek to make knowledge and expertise more easily accessible. They build on the success of Company Collectives and have a similar goal: to serve as a dedicated space where developers and technologists can find content organized around a specific area of interest. 

In my January post, I highlighted Collectives for each of the big three cloud providers—AWS, Microsoft Azure, and Google Cloud. Now, I’m excited to announce our first two Topic Collectives: R and CI/CD. As we expand the number of Collectives on Stack Overflow, our belief is they will serve as a vehicle through which every member of the larger community can find smaller sub-communities best suited to their needs and interests. 

A healthy community is essential to our company mission and higher purpose of empowering the world to develop technology through collective knowledge. We will never lose sight of how important, impactful, and unique it is. The trust of our community is as essential as the trust in the data it produces. Whether it is the shared passion for a given topic or the shared knowledge of a given specialty, Stack Overflow remains a destination for developers and technologists to solve problems. The problems we solved back in 2008 are not the ones we solve in 2023. Our evolution in offerings is what keeps our users coming back—and keeps us a go-to resource. I continue to be excited about our future and what we’ll share with you in the coming months.  Until then, I continue to be thankful for our customers and community members that help us in our mission to empower the world to develop technology through collective knowledge.

The post CEO Update: Paving the road forward with AI and community at the center appeared first on Stack Overflow Blog.

Today’s guest is Ilit Raz, founder and CEO of Joonko, which aims to build a more equitable workplace by automating the recruitment of diverse talent from underrepresented communities.

Episode notes:

Joonko is an automated diversity recruiting layer named for Japanese mountain climber ​​Junko Tabei, the first woman to reach the summit of Mt. Everest. You can learn about their talent pool, keep up with their blog, or check out their open positions.

ICYMI, read our blog post about how the recent tech layoffs have had a disproportionate impact on women, people of color, and immigrants.

Connect with Ilit on LinkedIn.

This week’s Lifeboat badge is awarded to pppery for their answer to Why use positional-only parameters in Python 3.8+?.

TRANSCRIPT

The post This product could help build a more equitable workplace (Ep. 575) appeared first on Stack Overflow Blog.

Every day Stack Overflow helps all types of developers learn new skills by answering their questions or helping them discover new solutions and approaches. We also know that learning is hard. Oftentimes, users don’t know what questions to ask – they don’t know what they don’t know. That’s why earlier this year, we were excited to announce more ways to learn and grow your skills with our online course recommendations. This new native advertising product recommended online courses that were selected based on the content a user viewed or is currently viewing and provided them with a structured learning path that was relevant to what they wanted to learn.

The following post dives deep into how we designed and built the recommendation system and how it has laid the foundation for other AI/ML initiatives at Stack Overflow. 

The idea

Recommending external content is nothing new to Stack Overflow. As part of our current Ads business, we offer a content/question-matching product called Direct-to-Developer. What was new about our online course recommendation system is that while developing it, we were simultaneously launching a new, modern data platform for Stack Overflow. This gave us fresh infrastructure, unrestricted tech stack options, and the opportunity to use state-of-the-art machine learning techniques.

Building upon a clean slate allowed us to hyper-focus on making the learning process easier and more efficient by bringing relevant and trusted courses to developers and technologists. We also wanted to run highly configurable experiments throughout the pilot—bonus points if we could reuse components for other initiatives. 

This lead us to build a cloud-first content-based recommendation system that recommends content that is similar to the posts you have or currently are interacting with. This system would need to account for three types of recommendations; post-to-content, user-to-content, and a fallback of the most popular. Each addressed a specific use case to ensure a relevant course could always be served while respecting user preferences. 

Our approach

Post-to-content 

At the core of a content-based recommendation system is how similarity is defined. At Stack Overflow, we have a lot of text and the catalog of courses to recommend also includes text. So we needed a way to measure the similarity between two pieces of text; a Stack Overflow post and an online course. If you are familiar with NLP (natural language processing), you know there are dozens of ways to approach this problem. Recently, there has been one approach that does extremely well: semantic similarity using embeddings from a pre-trained transformer model.

In our approach, we used a pre-trained BERT model from the `SentenceTransformers` library to generate an embedding for all 23 million Stack Overflow questions and a separate embedding for every course in the catalog. These embeddings allowed us to calculate cosine distance to determine how similar two pieces of text are. We only had a couple thousand courses, so we were able to load all the course embeddings into a nearest-neighbor model and perform a brute-force search to match courses to all questions. The output of this model is our post-to-content recommendation. 

In our prototyping phase, this approach performed extremely well! Not only was it able to find the most relevant courses, but by using the BERT model it already had foundational knowledge like “Node is related to JavaScript” and “Swift is related to Apple”. It allowed for offline evaluation and helped us identify which popular technologies on Stack Overflow were missing from the course catalog. 

User-to-content

Our post-to-content recommendations ensured that every Stack Overflow question had a list of relevant courses for an ad to be served. This provides an alternative just-in-time learning opportunity for all visitors. But for the users that opted-in to targeted ads, we wanted to provide a personalized recommendation that leveraged our first-party data.

To make a recommendation to a user we needed a way to represent the sum of the content that they have viewed. To do this we took all the posts they viewed within a certain lookback window and averaged them into one embedding. For example, if a user viewed ten posts, we took those ten post embeddings described above and averaged them element-wise into one embedding. This is commonly referred to as mean pooling. With this one embedding, we can use the same nearest-neighbor model and perform find the most similar course to what the user viewed to produce a user-to-content recommendation.

This approach also performed extremely well when we evaluated our own interactions with questions. Yes, Stack Overflow employees also use Stack Overflow! This personalized recommendation consistently outperformed post-to-content in clickthrough rate once we launched.

Top content

The last type of recommendation was to randomly select from a list of top courses, mostly JavaScript or Python, and was used purely as a fallback scenario. Either if there was no recommendation available or if something upstream failed. Regardless top was only served a fraction of the time as priority was set to serve user-to-content and then post-to-content.

How we built it 

With any project, especially a machine learning one, the hardest part is often moving it into production. Throw in simultaneously building a brand-new cloud data platform and a non-existent machine learning platform, we had our work cut out for us. Early on we decided not to rebuild the wheel and to empower “full-stack data science” work. This allowed our data scientist (myself) to have almost complete ownership of the entire project. This blessing and curse made it clear that leveraging one platform for as much as possible would be wise, and our platform of choice was Azure Databricks. This allowed us to keep all data processing, feature engineering, model versioning, serving, and orchestration all in one place.

Recommender systems are inherently complex because of all the separate components. So we designed our system to be as modular as possible. This allows us to control dependencies and experiment with different model parameters and techniques. The crux of our system is an offline-batch recommender system, meaning all recommendations would be pre-computed offline and stored somewhere ready to be served when needed. While there are many intricacies, think of our system as being broken down into three core components: generating embeddings, making recommendations, and serving recommendations.

Generating embeddings

As mentioned earlier, the core of a content recommendation system is how similarity is defined. For us, it was computing sentence embeddings and performing a nearest neighbor search. Doing this for 23 million posts and millions of users each run is no small task. Because Databricks is built on PySpark, naturally we leaned heavily into the PySpark ecosystem, which allowed us to rapidly prototype on “small” amounts of data and scale with no code changes. 

For the one-time job of generating post embeddings, we wrapped the BERT model in a PySpark Pandas UDF that ran on a GPU cluster. Then on a regular cadence, we computed new and edited question embeddings. Each time the post text, embedding, and other meta-data were written to a feature store. This was the same approach we took to generate the course embeddings. 

The user embeddings had to be refreshed each time we wanted to make new recommendations to account for the most recent user activity. We set a minimum number of questions a user had to view within the lookup window, if they met the threshold, then they were eligible for a recommendation to be made. For eligible users, we pulled the post embeddings from the post feature store table, pooled them, and wrote them to a separate user feature store table. For pooling, we also leveraged a Pandas UDF as there were other pooling methods we wanted to try, like linear or exponential weighting. 

Making recommendations

With only a couple thousand courses, we loaded all the embeddings into a modified nearest neighbor model, which allowed us to log it directly to the MLflow Model Registry and track lineage to the content feature store. We only had to retrain this model if we added or removed courses to the catalog. Logging the model to the registry also meant there was a clear path to going real-time if we so chose, as we could deploy the model as a serverless API.

Whenever making the recommendations, the logged model was then pulled from the registry and predictions were made directly on a Spark DataFrame. The data was then written to an intermediary Delta table. 

For those familiar with recommender systems, you may notice that this is a retrieval-only system, and you are correct. The initial release of the system did not include a ranker model as we needed to collect labels to train a model to re-rank results based on predicted clickthrough rate or other business-driven metrics, not just similarity. 

Serving recommendations

Once all recommendations were computed and a series of quality checks were passed, the final results were then written to an Azure SQL Server database. This database served as a low enough latency database for our internal ad-serving platform to select from when it needs to serve a course recommendation.

Once our internal ad server was told to serve an online course ad, it first looked to see if the user was opted-in to targeted ads. If so, it would then check to see if a user-to-content recommendation was available. If not, it would use post-to-content, and if there was a failure or the ad was being served on a non-question page, then a top content recommendation was served. This logic can be seen in the below flowchart.

Deployment and experiment 

Each of the above three core components had various parameters that could be changed and configured. Each potentially affecting the final recommendation and the execution time significantly. What embedding model, lookback window, or pooling method was used? What cluster configuration, execution schedule, and batch size were used? To address this, we used Databricks’ CI/CD tool dbx to parametrize the workflows and configurations, then had GitHub actions execute the builds. This allowed us to easily move from our development workspace to our production workspace and version changes, while always knowing how a recommendation was computed. 

Looking forward

We achieved a lot during the course (no pun intended) of building our online course recommendation system. We went from having no data platform to having a feature-reach machine learning platform that has been handling millions of recommendations every week. It was a learning experience for everyone involved but, most of all, an exciting milestone for Stack Overflow’s AI/ML initiatives. We have already re-purposed some of the work to improve our Related Questions section, which saw a 155% increase in the clickthrough rate (look for a future blog post on this). We have a lot of other ideas and experiments we’re working on for other applications of AI/ML to improve our platforms.

The post More on our AI future: building course recommendations and a new data platform appeared first on Stack Overflow Blog.

From the blog

Keep ‘em separated: Get better maintainability in web projects using the model-view-controller pattern stackoverflow.blog
MVC is an old pattern, but it’s still relevant to web apps.

Stung by OWASP? Chatting with the creator of the most popular web app scanner (Ep. 570) stackoverflow.blog
Simon Bennetts, founder and project lead of OWASP ZAP, joins the home team to talk about how he came to create the world’s most-used web app scanner, why open-source projects need long-term contributors, and how recent AI advancements could introduce new security vulnerabilities.

Great code isn’t enough. Developers need to brag about it (Ep. 571) stackoverflow.blog
On this episode we chat with Dagna Bieda, a career coach who specializes in helping developers and engineers level up their careers. She shares why developers should promote the value of their contributions, how soft skills can make or break a coding career, and why a moment of burnout inspired her to start coaching.

Automate your pre-merge workflow for dev efficiency promotion
Are your pull requests getting stuck in review? This workshop will help you create organization-wide code review automation with programmable workflows and policy as code to unblock the merge process and improve development efficiency, quality, and security. Register now!

Interesting questions

Apollo: what was the big deal? space.stackexchange.com
Pfft, first man in space. My kid could do that.

Does a rock falling down a hill perform computation? philosophy.stackexchange.com
And it can run Doom, too.

Why is my dryer radioactive? physics.stackexchange.com
Time to find out what the half life of socks is.

What is the ideal apocalypse for raising well adjusted children? worldbuilding.stackexchange.com
Parenting books have gotten out of hand these days.

Links from around the web

How to debug browser redirects dodov.dev
Redirects are tough to discover and debug because they’re subtle and instantaneous. Here are some good methods for working with them!

The 11ty Bundle 11tybundle.dev
If you’re looking to try out the 11ty web framework, this massive collection of resources makes it easier for you to get started!

Design and navigation considerations when building multi-platform applications  platform.uno
If you’re building for more than one platform, you have to consider how your applications will look across every screen your users see.

jQuery 3.7.0 released: Staying in order  blog.jquery.com
Believe it or not, jQuery still lives on, is updated, and remains one of the most popular libraries to this day.

Spending hours searching for answers at work? Find them faster in Stack Overflow for Teams. Get it free!

The post The Overflow #179: Brag about your code appeared first on Stack Overflow Blog.

Miško Hevery, creator of Angular and longtime Googler, tells Ben about building the future of web applications in his new role as CTO of Builder.io. 

Episode notes:

Angular is an open-source web framework used by millions of developers. Explore the Angular community. 

Miško is currently CTO at Builder, an API-driven, drag-and-drop headless CMS with a visual editor. Explore their docs or see what they’re up to on their blog.

Builder’s full-stack web framework is Qwik, which just reached 1.0.

Let Miško walk you through why Hydration is Pure Overhead.

ICYMI, listen to our episode with Builder CEO Steve Stewell.

Connect with Miško on LinkedIn, Twitter, or GitHub. You can also check out his website.

This week’s Lifeboat badge is awarded to ORION for their answer to Unicode symbol that represents “download”.

TRANSCRIPT

The post How the creator of Angular is dehydrating the web (Ep. 574) appeared first on Stack Overflow Blog.

We recently hosted a webinar about searching for jobs with several experts from Indeed. A big part of this discussion (and of the questions asked afterwards) was about resumes. That’s no surprise—resumes are the first contact you have with any prospective employer. Just sending the same resume to every job opening may eventually land you a job, but it’s not going to be the fastest and most productive method. 

When a company is looking for someone to fill an open role, they want to shop around and find the best fit. It’s similar to a person looking to make a big purchase. They want to see a quick overview of the specs when evaluating the field, then hop on a sales call with the best options. This article will talk about how you can make that resume you apply with more likely to lead to a sales call—that is, an interview. 

Think like a marketer

I know plenty of you cringed when you saw the word “marketing.” A lot of engineers are allergic to marketing, especially when it comes to dev tools. But marketing is all about communicating an idea in a way that’s easy to understand and compelling to a person. It’s about putting yourself in another person’s shoes and talking about your products and services in a way that matches their interests and pain points. Obviously, the end result is sales, but hopefully you are selling something that the buyer actually needs and appreciates. 

When we’re planning a campaign to increase sales, we start with trying to understand who our potential buyers are. To this end, we sketch out general personas: what they like, what they do, what their pain points are. It doesn’t have to be completely detailed, but the exercise helps understand who we think will buy our products or services. 

From there, we can create a one-pager that covers the basic features and benefits that would appeal to a specific persona. Sometimes detailed feature specs can interest someone in a product or service. But you’re asking them to do a little work to connect the dots between what you’re offering and what they need. In marketing, we try to connect as many of those dots as possible in our one pager. The end goal is to get them interested so we can discuss their particular needs and explore how our solutions solve them. This process is known as the buyer’s journey. 

When applying for jobs, you can map your application process to the buyer’s journey, placing the hiring organization as the buyer. For jobs with a posting somewhere, creating the persona is pretty easy—they tell you exactly what they need—but if you’re applying to lots of jobs, you may want to group some applications together. The one pager is your resume, full of the features and benefits of you as an employee. If you can get their attention and spark their interest, you’ll proceed to the next step.

Let’s take a look at what we can do to make our resume convert our leads into sales calls—I mean, interviews. 

First, start with the fundamentals

Your resume is made from the raw material of your everyday work performance, so it’s important to collect that raw material. Save performance reviews, evaluations, positive comments and emails, quantifiable data, and anything else that speaks to your performance in a role. You can use these materials to produce a base resume that has everything about your jobs. Because we tend to have a better memory of more recent events, update your resume every six months or so. You might not be looking for a job now, but it’ll be worth it once you are. 

There are some basic things that work across resumes. The first filter for applications comes from an applicant tracking system (ATS), software that weeds out applicant resumes that don’t have the keywords they are looking for. 99% of Fortune 500 companies use an ATS, so ensuring that your resume can easily be read by an ATS is key. That means clean formatting, no charts, no pictures, no vital information in headers or footers as all of these may not be parsed by the ATS system.

At this stage, you’ll want to build a base resume that contains all of the material that will be used to create targeted resumes. Add all of your education, experience, and skills to this document, regardless of how small. You may find they are useful for specific applications or application types. While you won’t likely send this base resume out in applications, it can form the basis of your LinkedIn profile, which serves as the homepage of your professional brand, plus additional context that won’t be on your resume. Most recruiters and hiring managers look at LinkedIn profiles as part of their hiring process. If you don’t have a LinkedIn profile yet, set one up so they can find you.

When putting together this base resume, note a couple of things. First, technical roles rely heavily on your technical skills, so lead with those. Include proficiency levels with these. It can be tempting to only list skills in which you are proficient, but low proficiency skills can highlight your ambition to learn new languages or technology outside of your current role. If you’ve been working in roles that use C#, Java, and Python but list a low proficiency in Rust, a prospective employer may see that as a way to onboard a passionate advocate of a language they are migrating to. 

Second, use the experiences sections to focus on the impact of your work and the soft skills that you used to achieve them. What did you do, how did you do it, but most importantly what was the outcome. Try and use hard numbers—migrated X user records, handled X logins per day, generated X dollars in revenue—if the hiring manager can understand your impact, they can more easily apply that impact to their own business. 

Additionally, if you have side projects or certifications, find a place to include those. The programming hobbies that you have can showcase your skills as well as jobs. Even better, you can include links to code repositories so that potential employers can actually see the work you’ve done. 

Create resumes that tell your stories

Ok, you’ve put together good base material to build some targeted resumes from. Remember, marketing tells a story about the product, which in this case is your services as an employee in a specific role. A resume here needs to quickly tell the hiring manager why you’re a good fit for this role. You may think that your general purpose resume is doing that, but unless it tells a story understandable to the reader, you might be missing the “quickly” part of that directive. 

While creating a completely different resume for every job is a pretty good recipe for job hunting burnout, grouping those jobs into broader types and creating resumes for those types will help get your resume in front of the right people. For example, if you are applying to a full-stack developer position at a small tech start-up and a cloud infrastructure engineer position at a global manufacturing company, your story will be a bit different. It might even be different if you’re applying to two different cloud engineer positions, one at a large company and one at a startup, as they may require different skill sets. 

Exactly what to write on each resume is up to you—you are the “content writer” here, so you make the editorial decisions based on what you think the job posting is asking for. However, if they’re asking for a specific skill, make sure that it’s listed somewhere on the resume. I’ve known recruiters who ask candidates that they’re representing to include specific skill keywords on their resume just so they can get past that first round of ATS processing. 

As for the rest of it, as the cohost of our podcast said, “It depends.” How you structure your resume and describe your experiences, skills, and projects will depend on the material on your master resume and the requirements of the role. For each resume, you can add a tl;dr—a professional summary of your career targeted towards the role you’re applying to. This serves as the “hook” to your resume, a little teaser to get them to read to the end. 

You may think that professional writing means fancy writing, but that’s not true. You want to get your story across as clearly and effectively as possible, which means using plain language and simple sentence construction. You’re not writing a resume to impress them with your verbiage or buffalo them with word counts. You want them to understand what you’re writing, first and foremost. 

While cover letters are not as important for technical roles, they can add a little extra context to a resume. You can use a cover letter to describe the impact you’ve made in previous roles and the impact that you can make for the potential employer. While a good resume can do the persuasive work of a cover letter, some applications require them. Use your judgment as to when to write one, but don’t burn yourself out on them. 

Conclusion

In marketing, we want to make sure we have materials that inform potential customers of how our software and services can help them. To make sure we’re telling the right story to the right people, we create multiple stories for each type of potential customer. 

When you’re looking for a job, your potential customer is the hiring manager. Your resume is often your first opportunity to impress a hiring manager, so the more thought you can put into it, the better. By creating multiple resumes tailored for the various positions, industries, and company sizes that you’re applying for, you’ll have a better chance to get a call back and an interview. Drop your resume writing questions or tips that have worked for you in the comments. 

For more tips on getting your next dream job, check out Indeed’s Career Guide, an online resource designed to help connect people with the information they need to get a job and develop a successful career.

—————–

The Stack Overflow blog aims to serve developers by providing articles that help our readers learn new skills, level up at their jobs, and explore changing technologies. Indeed is a strategic partner of Stack Overflow and this article was created in collaboration with them to assist developers looking to grow in their careers and explore new opportunities.

The post How to use marketing techniques to build a better resume appeared first on Stack Overflow Blog.

Pierre-Étienne Meunier, creator and lead developer of open-source version control system Pijul, joins the home team to talk about version control, functional programming, and why OCaml is a source of French national pride.

Episode notes:

Pierre-Étienne’s interest in computing began with the functional programming language OCaml, created by Xavier Leroy. Before OCaml, Pierre-Étienne explains, “everyone thought functional programming was doomed to be extremely slow.”

Pijul is a free, open-source distributed version control system. You can get started here. Want a GitHub-like interface? Find it here.

Read the article that led to this conversation: Beyond Git: The other version control systems developers use. 

Pierre-Étienne is currently working on a new project with the creators of the open-source game engine Godot. We hosted Godot cofounder and lead developer Juan Linietsky on the podcast a few months back; listen here.

Nix is a package management and system configuration tool. Learn how it works or explore the NixOS community. 

Connect with Pierre-Étienne on LinkedIn.

Congrats to Lifeboat badge winner Rachit for answering Passing objects between fragments.

TRANSCRIPT

The post For those who just don’t Git it (Ep. 573) appeared first on Stack Overflow Blog.

Productivity is definitely top of mind, but whether productivity can be measured is an open question. Many organizations, however, have been measuring how fast their teams ship fixes and features to your customer, which is usually called development velocity. Google devised the DORA metrics to put concrete numbers to this abstract concept. 

There are a lot of factors that affect development velocity: CI/CD pipelines, code quality, developer experience, and more. In this article, I want to discuss that last one, as real velocity means solving the problems that haven’t yet been solved. Hard problems need focused, sustained attention from developers. This attention—the time and freedom to focus—is your team’s most valuable resource.

We often describe working with focused attention as a flow state. As described in the book Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi, a flow state allows one to become fully engaged and focused on the task at hand. It leads to better results and greater happiness. But it can only happen when you have the attention to focus fully on whatever it is that lies before you. 

Why can’t we focus at work?

The contemporary workspace, whether in-person or remote, is full of demands on your attention. We have chat programs, email inboxes, and project management apps all throwing notifications our way. In offices, you have other people tapping you on the shoulder and creating general noise (and woe betide those in open offices). Working remotely avoids some of these, but places the entire communication burden on chat and email applications with their little red notifications. These apps promise asynchronous communications, but that doesn’t always happen in practice.

On top of that, we regularly juggle multiple tasks simultaneously. Our attention is pulled in multiple directions, regardless of whether you live an inbox zero life or not. Flow states require sustained attention over time, and our days get chopped into pieces by interruptions and meetings. Researchers at UC Irvine found that on average, office workers switched tasks or were interrupted about every three minutes. Recovering from those interruptions could take workers up to 20 minutes to get back to where they were. In fact, these interruptions could cost individuals up to six hours every day. 

When we have multiple demands on our attention, we try multitasking—splitting our spotlight or shifting it rapidly to focus on the many tasks that come our way. The truth is, we’re bad at multitasking. There’s a mental cost to switching tasks, and that cost translates to up to 40% more time to complete the tasks. Small errors of inattention slip in—typos, missed cues, and quickly forgotten details. Even trying to do only two things at once can mean you do both badly. 

All these interruptions can lead to greater stress and anxiety. Depending on the task, productivity may not suffer, but interruptions may cause us to work faster, which leads to greater time pressure, frustration, and stress. It takes more effort to complete the same amount of work with interruptions in the mix. In the longer-term, enduring regular interruptions—up to 85 per day—can cause decreased job satisfaction and burnout. 

Stress and anxiety form a feedback loop. Both can cause attentional problems, like difficulty concentrating. Without the ability to pay attention to what you’re working on, you may forget steps or not remember solutions that you’ve found. Anxiety has been linked to memory lapses, and if you are constantly forgetting information you’ve received from those chat messages that interrupt people, you may end up interrupting your coworkers over and over. 

It turns out that those coworkers you interrupt are usually the most senior employees at a company. They’ve been there the longest, they have the most historical knowledge about processes and tools. And they suffer the greatest number of interruptions from their coworkers. 

There are no notifications in heaven

Let’s back up. It’s pretty easy to complain about what’s terrible, but harder to imagine what the better world looks like. 

In Flow, Csikszentmihalyi talks about optimal experience as one in which the individual has control over their moment-to-moment experience, bringing their consciousness into a state of order. What makes us miserable about our current state of constant interruptions is that it destroys our control. Our attention is not under our command; instead, it ends up being at the mercy of notification on top of notification, multiple applications chiming for attention. Wrangling them under your control seems to be the root of the solution. 

To do good work during your day, you need some time where you aren’t doing work. Downtime is essential to reducing stress, avoiding burnout, and maintaining a healthy brain. But as we’re all working from home more, work creeps into our home life. Our phones are filled with the same notifications as our work computers except that they can reach us at any hour. You can—and probably should—mute and ignore these notifications after hours; some chat programs set working hours during which notifications will be sent. 

Our always-on work culture doesn’t always let us ignore notifications, even if it isn’t your turn to monitor incident alerts. Many governments have started passing right-to-disconnect legislation to allow employees to ignore any work-related communications that come after working hours. At the very least, we can have control over what we do in our free time. 

But what about within the workday? There are ways to recover some measure of control over the attention of your day. You can use “timeboxing,” where you place a meeting on your calendar that is just for you, a time where everyone understands that you will not respond to notifications. You can be disciplined about statuses and notification settings, indicating when you are available and when you are not. But these techniques only try to manage notifications; what if you could reduce them?

In the end, we may want to rethink why we have notifications in the first place, same as some companies are doing with meetings. Every email, every chat notification is an invitation to collaborate and share information. This is great! Collaboration is a force multiplier that increases employee effectiveness. But notifications are synchronous; they demand attention right now. Better collaboration lets all stakeholders come to the table when they are ready, either scheduled so they can plan around it or asynchronous so they can address it when they have the attention to give it. 

A quieter, more focused workspace

We needed to stay productive by working in the ways that add value instead of reacting to pings, dings, and shoulder taps. That’s mostly writing code, supporting infrastructure, collaborating on solutions, and sharing our hard-won knowledge. One of the reasons that chat apps (and email, to a lesser extent) drain so much of our attention in modern workplaces is that they have become the central application in our workflow, especially for those last two items. Chat apps are immediate; they want your attention right now.

Changing workflows is hard; I’ve seen how developers work in the absence of processes and  it’s all in the chat channels. Implementing a new process is hard; the chat workflow works, albeit in a way that isn’t great for some of our other work. We’ve seen the impact that the Stack Overflow community has had on programmers around the world, and have tried to replicate that for organizations with Stack Overflow for Teams. Of course, we have integrations with many of the major chat programs; think of it as using the Strangler Fig pattern to change workflows. 

There are plenty of other productivity applications that are looking to move the relevant workflows into spaces that are less attention hungry. They have integrations to your favorite chat app too. Of course, the risk here is that your app becomes absorbed in the chat app workflow instead of moving you away from it. 

Ultimately, the problems of attention drain have cultural solutions. You can get the right tools to support that culture, but there’s two questions that an organization needs to answer: (a) How do you collaborate? and (b) How do you share knowledge? So long as the answers to these involve some analogue or digital version of tapping a coworker on the shoulder to get their attention, we’ll remain distracted and constantly trying to get back to the context we had before our interruptions.

The post Modern work requires attention. Constant alerts steal it appeared first on Stack Overflow Blog.

From the blog

Stories from our survey: Salary in the time of pandemic stackoverflow.blog
Salaries for developers surged over the past few years, but those gains weren’t even distributed globally.

How do we get a tech team to make a big technical change? stackoverflow.blog
It takes more than technical chops to implement big changes.

Read the docs? We prefer to chat with them (Ep. 568) stackoverflow.blog
Cassidy and Ceora talk with Astro creator Fred K. Schott and Cloudflare’s Brendan Irvine-Broque and Michael Hart about the intersection of open source and AI.

A conversation with the folks building Google’s AI models and I/O releases stackoverflow.blog
Paige Bailey, lead product manager for generative models at Google, breaks down where the company’s AI is heading.

Expert support, on demand promotion
Imagine having a direct line to over 150 senior cloud architects for any cloud-related question or issue you encounter. With thousands of cloud questions and issues resolved, DoiT is your gateway to world-class cloud expertise.

Interesting questions

Why would lsof /dev/video0 be insufficient to check what processes are using the camera? unix.stackexchange.com
Only if you’re using the computer labeled “Abby Normal.”

Dropping malicious packets as close to the source as possible networkengineering.stackexchange.com
TIL the internet backbone exists in the same way that the public square does: conceptually, not actually.

What’s this dark pattern for placing an expensive product next to an even more expensive product to make it appear cheaper? ux.stackexchange.com
Get the silver widgets. They are way cheaper than the gold ones.

What is the theory behind using the 14th Amendment to ignore the debt ceiling? politics.stackexchange.com
Not since high school social studies classes have we Americans had to be familiar with so many amendments.

Links from around the web

Chromium blog: An update on the lock icon blog.chromium.org
The lock icon used to be necessary to show that a website was using a secure connection. Now that it’s the norm, is it time to change?

The intersectionality of web performance adactio.com
It’s not just business that is positively impacted by good web performance.

See this page fetch itself, byte by byte, over TLS subtls.pages.dev
This page looks simple, but it gives you an appreciation of the web’s history and the work that makes it possible.

A backup of historical proportions computerhistory.org
A deep dive into the history of archival anxiety.

Spending hours searching for answers at work? Find them faster in Stack Overflow for Teams. Get it free!

The post The Overflow #178: Chat with your documentation appeared first on Stack Overflow Blog.

On this episode of the podcast, we talk to Mauricio Linhares, senior software engineer at Stripe, about the pain of migrating monoliths to microservices, defining zero-tier systems, and why plugging all your servers into the same power supply is a bad idea. 

Episode notes: 

While Mauricio and team had to get back to bare metal, most programmers are headed in the opposite direction. It’s why MIT switched from Scheme to Python. 

At Stack Overflow, we’re familiar with what happens to websites during physical failures, like hurricanes. 

Connect with Mauricio on LinkedIn. 
Congrats to Lifeboat badge winner The Nail, who pinned a solid answer on the question, if->return vs. if->else efficiency.

TRANSCRIPT

The post Building zero tier systems on bare metal (Ep. 572) appeared first on Stack Overflow Blog.

Software engineers use a design pattern to build this separation of concerns into their software architecture. The model-view-controller (MVC) was created in the late 1970s by Trygve Reenskaug when working on Smalltalk. Though it is an older, pre-web design pattern, it is ubiquitous in modern applications. The pattern can be found on the web in both backend and frontend applications, on mobile, desktop, and more. 

The pattern’s name references models, views, and controllers. These are the core building blocks in MVC apps. Each of these components has a specific role and behavior. Let’s take a closer look at the use and implementation of this pattern.

The basics of the pattern

Models provide access and storage for the application data. Typically a model represents a database table. However, models can represent data in any form, they may represent data held in memory, cache, or even a third-party service. Models implement methods to access or modify the data, most commonly these are create, read, update, and delete (aka CRUD) operations.

Views transform the application data in memory to user interface elements. They may also just serialize the data or transform the data to other user interface representations like the native user interface in mobile apps.

Controllers are the glue of the pattern. They are the entry point of the pattern and make models and views work together. All operations are first handled by controllers. Controllers offer high-level actions with required data inputs. Upon an action call, they handle action on the data, pass the data to the models, and then pass the models or the data to views for rendering. All user actions in the application are passed through the controller. The controller decides what should happen next.

MVC on the web

In web applications, controllers handle HTTP requests and responses. They are responsible for pulling the right data from the requests, performing the business logic with error handling, and returning the correct HTTP status and data in the HTTP response. Controllers are typically stateless and own the stateful instances of the models and views. In web applications, controllers create model and view instances when a request comes in or when an action is called, but they don’t own or call other controllers.

Models are responsible for holding the state of the application. In other words this means models store and do low-level work with the data, it can be a class or an object with methods and members holding data or it can be a wrapper of a third-party API. Models frequently have an asynchronous API because they work with low-level asynchronous operations like working with the database, reading from a file, or communicating over a network. Models can work with other models, call them, and use their methods. One model may create composite and more complex operations based on the functionality of other low-level models. As an example, a model may pull some data using another model that wraps a third-party service and store that data into a database table using a model for that table. Models should not work on their own. They don’t call controllers or views or hold any references to them.

Views render the data in a web browser or mobile application. Web application views are stateless and they can be as simple as JSON serializers or as complex as HTML templating engines. Views take data in the form of model instances or custom objects and translate the data into the requested form. Sometimes web applications can support multiple forms of data representation driven by the HTTP Accept header. In MVC, this could just mean employing a different serializer for JSON or XML or a templating engine for the data. Views may call other views to render different types of objects or sub-objects. Views may receive model instances and work with model APIs. However, patterns where a view would directly manipulate data in the model is not recommended. It is always and only the responsibility of the controller to call functions on models that could manipulate the state of the application. Avoid the possibility of this pattern by creating a proxy object that holds the data ready to be rendered in the controller, initializing these objects with data from the models and passing this proxy object down to a view. This way, the controller stays in control of the view’s access patterns and data exposed to the view.

Interfaces

Each component of the MVC design pattern has an interface. This interface provides a way to interact with the objects. In an MVC application on the web, this interaction starts with the controllers. A web server typically interacts with a controller after it receives an HTTP request. The requests are first processed by lower levels of framework or web server logic. This processing handles parsing and deserializing the request and calling a method on the controller.

The web MVC controllers typically implement methods that represent operations provided by the HTTP protocol: GET, POST, PUT, and DELETE. But these HTTP methods don’t need to map to a single method on the controller. The mapping is controlled by routing logic that provides additional options to invoke the right controller method based on the paths or parameters provided in the request URL. In an app using a database, some controllers might implement methods like list or index to wrap model calls and display lists of records with their ids and then a get method to get a specific record based on its id.

For retrieving records, the call comes from controllers to models. In web application frameworks like Ruby on Rails or Django, you may find models providing or implementing several find methods. These methods accept a record id and or other parameters that are passed to queries to lookup specific records. To create records, the models implement create factory methods or allow instancing the model. The models are instanced via class constructor and their properties are set through the constructor parameters or through setter methods defined on the model. The models sometimes wrap specialized record creation into class or static factory methods. These factory methods can provide a nice interface allowing you to quickly understand how the model is instanced in the application code or in tests.

Implementation pitfalls

The most common pitfall when implementing new MVC apps is the lack of respect towards the separation of concerns presented and enforced by the pattern. Developers sometimes decide to cut corners and skip the separation of concerns in order to be quickly done with their changes.

Too smart views

The views in MVC web applications are responsible for translating internal data structures into presentable text format like XML or HTML. Some logic is necessary to do so. You can iterate over arrays of records using loops. You can switch between different types or sections of content for display using branching. Views by nature contain a large amount of markup code. When the markup code is mixed with looping and branching logic, it is much harder to make changes to it and visualize the results. Too much branching or conditions in the view also make the markup hard to read. Spaghetti only works as food, not code. There are two tools that help with this problem: helper functions and view file splitting.

Helper functions are a great way to isolate logic that may be called multiple times, shared, or re-used between views and let you follow DRY principles. Helpers can be as simple as providing an element class name based on some input or as complex as generating larger pieces of the markup.

File splitting is another powerful approach that can improve code readability and maintainability. Every time a view grows too large or too complex, you can break it down to smaller pieces where each piece does only a single thing. Just the right amount of view file splitting can make a big difference in organization of the project.

Overapplying helper functions or view file splitting can also lead to problems, so it is best to drive changes when there’s a reason—and that reason should be a too complex view.

Heavy controllers

Controllers are responsible for implementing actions coming from the frontend, the UI, or the API of the application. For many developers, it becomes tempting to implement data processing logic in the controllers. Sometimes you may see database queries built directly in the controllers and the results stitched together with other data in some complex logic and then the results returned to the views or serializers. Other instances of this problem look like third-party API calls made directly from controllers and the results adjusted or mixed with other data from the local models and returned back to the client. Both of these are cases of heavy controllers.

The controllers should be light on logic. They should process input parameters and pass the adjusted input down to the models. The controllers take the inputs, choose and call the right models and their methods, retrieve the results, and return the results in the right format back to the client. Heavy lifting with data shouldn’t be done directly in the controller methods to avoid code complexity problems and issues with testing.

Light models

Models are built to manage, hold and represent the application data. Every time the application needs to work with the data, it should reach into some model. Sometimes application developers decide to perform data manipulation in controllers, which makes the controller code more complex and creates code maintenance problems. Since models work with data, any incorrect logic on the models may corrupt the data. This is why the models should have the highest test coverage out of the entire app. Well-implemented models are very easy to unit test. 

Application logic that reads and writes data should be concentrated on the related models. For example, if the data queries are spread all over the controller code then it is harder to get good model test coverage. When the developers debug issues like slowness in the database, they may not see all queries performed against a table right away so it may take them longer to optimize the queries and implement better indexing.

Another example can be an interaction with third-party services. Applications frequently require communication with cloud and data providers and this is done through asynchronous calls and APIs. These methods return data that gets processed, altered and saved in the application. It is beneficial to treat these interactions with third-party APIs as model logic and place it on the respective model. This puts the third-party logic to a specific place in the app where it can be quickly covered with integration tests.

Conclusion

The MVC pattern was developed to separate concerns and to keep the application code highly organized. Frameworks like Ruby on Rails that are built on top of this pattern and reap the benefits of strict naming and placement. Closely following this pattern makes projects based on it easier to understand, maintain, and test. Correct usage of its rules reduces developers’ mental load and speeds up any bug fixing or new feature development. Long live the model-view-controller!

The post Keep ‘em separated: Get better maintainability in web projects using the model-view-controller pattern appeared first on Stack Overflow Blog.

Today’s guest is Dagna Bieda, a career coach who specializes in helping developers and engineers level up their careers. She shares why developers should promote the value of their contributions, how soft skills can make or break a coding career, and why a moment of burnout inspired her to start coaching.

Episode notes:

Visit Dagna’s website, theMindfulDev.com, to learn more about her coaching process, which is built around understanding what fulfillment looks like for each client. 

Dagna is on LinkedIn.

You can also connect with Ceora on Twitter or her website.

Ryan is also on Twitter, especially when there’s a good AI joke to be shared.

Gold star for Lifeboat badge winner JasonHorsleyTech for rescuing the question Installing PHP 7.3 on a new MacBook Pro with the new A1 chip (Apple silicon).

TRANSCRIPT

The post Great code isn’t enough. Developers need to brag about it (Ep. 571) appeared first on Stack Overflow Blog.

The Developer Survey asked respondents to supply country information so we can understand trends in salary roles while controlling for factors like experience and location. India and Brazil saw salary growth of 22.7% and 16.9% respectively across all tech roles, compared to 8% in the U.S. and 3.4% in Germany. India and Brazil’s large pool of educated and skilled workers may have been undervalued prior to the pandemic, and the increased demand for tech was good timing for these two countries in different ways. An increased willingness to hire remote for full-time roles in critical positions may also have driven this change.

The world had high demand for technology in 2022, and India was successfully positioned with the supply of talent to meet it. India’s revenue growth in the tech sector increased 10% year-over-year during the time our 2022 survey was collecting data, compared to 8.6% for the same year in the U.S. 

While Brazil doesn’t have the population that India does, it is certainly supplying an abundance of new talent: data from Brasscom posits that even with  ~250K new IT graduates per year and growing, the demand is still exceeding the supply of new talent available to work in a U.S. time zone. This new tech talent isn’t poised to reap the same salary benefits as experienced developers, but increasing demand and rising inflation  will help drive up their salaries. A lot of the growth is also local.  Venture capital investment into Brazilian companies in 2021 tripled from its pre-pandemic levels. Brazilian tech schools are growing to meet this demand. 

The three-year growth results also show the velocity in developer role value (in USD) and trends where specific technology specializations may start to become localized. Data scientists and machine learning specialists in India have seen about a 32% increase per year in median pay, the highest rate of growth among our top responding developer roles. 

Will data science/machine learning developers in India remain the top role for salary growth in 2023? Will we see continued improvement in prospects for back-end or embedded app developers in Brazil? Brazil and India’s competitive growth in developer salaries will certainly be a trend to look for in our 2023 survey findings. If you haven’t taken part yet, share your experience and add to this year’s Developer Survey.

The post Stories from our survey: Salary in the time of pandemic appeared first on Stack Overflow Blog.

From the blog

The 2023 Developer Survey is now live! stackoverflow.blog
We want to know about all the technology that makes you swoon and scoff.

AI isn’t the app, it’s the UI stackoverflow.blog
A realistic understanding of generative AI can guide us to its ideal use case: not a decision-maker or unsupervised agent tucked away from the end user, but an interface between humans and machines.

Don’t panic! A playbook for managing any production incident stackoverflow.blog
Knowing how to handle it when things break is more important, and practical, than trying to prevent things from ever breaking at all.

How to land a job in climate tech stackoverflow.blog
Climate tech is a niche industry and requires specific strategies to get a job in.

When AI meets IP: Can artists sue AI imitators? (Ep. 566) stackoverflow.blog
Ben and Ceora talk through some thorny issues around AI-generated music and art, explain why creators are suing AI companies for copyright infringement, and compare notes on the most amusing/alarming AI-generated content making the rounds (Pope coat, anyone?).

Train a music playlist recommendation engine promotion
A team of data scientists built a music recommendation engine that can scale to search over 4 billion user-created playlists. Read how they used MongoDB as part of a scalable ETL pipeline to train their deep learning model.

Interesting questions

Is it possible to have satellites (natural or not) orbit the same celestial object in different directions (clockwise, counterclockwise)? astronomy.stackexchange.com
Ah, the rebellious moons of Jupiter.

SQL Server with multiple databases (one per client) – what is the best security practice in terms of logins/users/permissions? dba.stackexchange.com
If one user can access all your separate databases, then they aren’t so separate, are they?

Would a satyr wear horseshoes? worldbuilding.stackexchange.com
Goat shoeing was originally the festival of Satyr-nail-ya.

What vulnerability is a math operation in an HTTP request trying to exploit? security.stackexchange.com
They’re trying to get your web server to do their homework.

Links from around the web

The web’s most important decision thehistoryoftheweb.com
Thirty years ago, the World Wide Web was made free for everyone, a decision that arguably changed…everything.

The interactive guide to rendering in React ui.dev
React’s rendering behavior is often misunderstood—on Stack Overflow, “why is React rendering?” yields over 8000 results. Here’s a deep dive to answer your questions!

Is perpetual motion possible at the quantum level? www.quantamagazine.org
Just what the MCU needed.

Wingspan design retrospective with designer Elizabeth Hargrave youtu.be
Wingspan is one of the most highly rated board games that’s come out in recent years. Come geek out about how it was made!

If you’re curious about our other products: How to get started with Stack Overflow for Teams.

The post The Overflow #177: The AI is the UI appeared first on Stack Overflow Blog.

Simon Bennetts, founder and project lead of OWASP ZAP, joins the home team to talk about how he came to create the world’s most-used web app scanner, why open-source projects need long-term contributors, and how recent AI advancements could introduce new security vulnerabilities.

Episode notes:

Simon is the founder and longtime project lead of OWASP ZAP, an integrated penetration testing tool that helps uncover vulnerabilities in web apps, including compromised authentication, sensitive data exposure, and SQL injection. ZAP is OWASP’s most active project and the world’s most popular web app scanner. 

Check out other OWASP projects here or explore ZAP’s docs.

Check out our blog post on how you can mitigate the ten most-found OWASP vulnerabilities in Stack Overflow C++ snippets.

Jit, where Simon is a distinguished engineer, is a DevSecOps platform that allows high-velocity engineering teams to embed security requirements throughout the DevOps workflow. You can explore Jit’s docs here.

Today we’re shouting out the question CSP Alerts by OWASP even though CSP header is added, definitively answered by one Simon Bennetts.

Simon is on LinkedIn and Twitter.

TRANSCRIPT

The post Stung by OWASP? Chatting with the creator of the most popular web app scanner (Ep. 570) appeared first on Stack Overflow Blog.

We sit down with Forrest Brazeal, head of developer media at Google Cloud, to discuss all the AI-powered goodies announced at today’s I/O event. Plus, a conversation with Paige Bailey, lead product manager for generative models at Google, who contributed to many of the projects that debuted today.

Learn more about Forrest on his website and check out his newsletter.

You can follow Paige on Twitter or her LinkedIn.

Get on the list to try out some of the new stuff released today here.

TRANSCRIPT

The post A conversation with the folks building Google’s AI models and I/O releases (Ep. 569) appeared first on Stack Overflow Blog.

First and foremost, I want to recognize the impact this decision has on employees who are directly affected. This is painful for them, and we are supporting those employees through this transition with severance packages, extensions of healthcare benefits, and outplacement services. As CEO I take full ownership of this decision and it weighs heavily on me. To those of you affected, I want to extend my deepest gratitude for your contributions to the company and for all of your hard work.

Our focus for this fiscal year is on profitability and that, along with macroeconomic pressures, led to today’s changes. They were also the result of taking a hard look at our strategic priorities for this fiscal year as well as our organizational structure as we invest in the continued growth of Stack Overflow for Teams and pursue agility and flexibility as we launch AI/ML-focused offerings in the months ahead. Our commitment is to continue to provide our customers with the level of service they expect and to the users of our public platform—the knowledge they’ve been seeking from Stack Overflow for nearly 15 years.

Next week I’ll share another blog post on the business looking at fiscal year Q4 in review and the road ahead. I appreciate your patience and kindness as we navigate through this difficult time.

The post A Message from Prashanth Chandrasekar, CEO Stack Overflow appeared first on Stack Overflow Blog.

So imagine you’ve gotten past all of those—secured time, obtained sanction from the business, investigated technical feasibility. Maybe you even have a working spike of your solution in a pull request. It feels like the hard part is over. With pride, you stand up in a full-team meeting and announce your brilliant solution…

…to crickets. Your team seems disinterested, or maybe avoidant, or maybe they even resist the idea.

After the meeting, you try to nail down individuals to get their opinions on your solution. Folks respond noncommittally. “Maybe later.” They want to get out of meeting with you. 

What happened? 

Two things happened. First, your solution probably threatens team context—or at least seems like it does. Second, you presented it in the format least amenable to letting the team express that.

Context is king

We reward developers for building new features; for delivering tickets and merging lines of code. But the lines of code themselves are not the currency of technical power. That currency is context—it’s knowledge about the system and how to change it. Who has context on the system is who has power on the team. And that drives more technical decisions than we’d like to admit.

Whole code bases get deprecated on a regular basis because the team considers them “legacy” and “unmaintainable.” Not because they don’t have features or they don’t work: they have features! They work fine! But the current tech team no longer understands them. I’ve seen a team deprecate a service because it was in Rust and rewrite it in a language they considered easier to find devs for: Python. I’ve seen a team rewrite a functioning mail service because the variables in the old one were named “b”, “u”, and “m”—by an architect who had retired. I’ve seen several teams rewrite a monolith as microservices, run into the authentication challenges of microservices, and promptly rewrite the whole thing again as a monolith—but newer this time. 

Just as often, some developer springs up a new service that they’re excited to use to add a new feature or replace an old one. The new service is in some completely different stack than the existing code base because the developer saw a YouTube video and got excited. The stack is Django and somebody went with Vue. The stack is RESTful and somebody went with GraphQL. The database is postgres and someone spun up Neo4j. The rest of the team groans. Why? The new service has features! It works fine! But it increases the amount of context that every team member needs—by an entire framework—to be able to move freely within the system for feature development and maintenance.

Those are extreme examples, but it reflects what’s happening any time you change a code base. Because when individual contributors understand how a system currently works, changes make some part of that understanding obsolete. And the obsolescence of that understanding means an initial investment in rebuilding the understanding to restore one’s ability to maintain the system. To restore one’s power on the team.

The bigger the change, the larger the amount of individual and team context you’re wiping out. Like chemotherapy—designed to attack fast-growing cells like cancer cells but also, sadly, hair follicles and wound-healing cells—large refactors make sweeping changes that wipe out swathes of context. Hopefully most of that lost context is a benefit:  frustration, regret, or concern about some aspect of the code base (I talk a lot about what sorts of changes those might be in this self paced course on technical debt). But in the process of improving the system, the change wipes out team context on the existing system and poses collateral damage to perfectly desirable feature development efforts. 

Context begets power to such a degree that an extreme enough change can upset the team power structure. I once worked on a team where an iOS developer unilaterally changed all navigation in the app from the standard default approach, segues, to a custom, functionally-oriented central navigation module. Not only did this completely change the backbone of the app; it changed it to a custom, un-Googleable approach. The whole team went immediately from being able to Google their questions about screen navigation to depending entirely on Jim. Without Jim, no one could create a new screen in the app. If Jim was out for the day, whole tickets became blocked. People left it that way because no one wanted to upset the now-most-powerful member of the team.

Then Jim got a new job. His last day was a Friday. The next Monday, the team got to work un-refactoring the app back to segues. It took five days. It was worth every expensive, profanity-filled minute to restore the team’s ability to work in its code base. 

Presentation matters

In the movies, failing companies experience their big turnaround after a lone genius stands up in a meeting, slams their fist on the table, and announces “Here’s what we’re gonna do!”

In addition to being dramatic and fulfilling, that mechanism for introducing changes feels efficient: tell everybody about it at once! The problem is, it doesn’t work in real life. When you announce a giant change that threatens teammates’ power in a joint setting where people aren’t expecting it, you set your team up to resist your idea. This is a big surprise to them, and announcing it in a big meeting makes it clear that you expect this change to go through—whether or not they agree with it or even understand it. 

Even if you say you are open to questions, the team at this juncture is completely unprepared to ask questions because you’ve sprung this change on them. They’re stuck operating from whatever context they walked into the meeting with. Since context is king and you’ve given them no opportunity to gain context on your change before you announced it, you’re not demonstrating to them that their precious context is safe with you. This isn’t a collaborative way to suggest a change.

A very real part of the work of making large changes is to socialize them. Tech heads don’t like it, but it’s true. And it makes the difference between the big changes that sail through with support and the ones that get stuck in the mud because the team dragged their feet or outright resisted them.

Socializing your change

What does the socialization process look like? First of all, it involves going to teammates one on one. That doesn’t feel efficient, but it creates an environment in which people are able to ask questions and express concerns. When you chat one on one with someone before announcing a big change, you indicate that their input matters to you. You care how this change is going to affect them. Their precious context is safe with you.

Second, start by talking to this person about the problem you’re trying to solve with your change rather than the change itself. What is the pain in the code base? Does your colleague also experience this pain? What does it look like to them? Establish that the problem you’re trying to solve is bad enough to merit a solution like yours. In the same way it doesn’t make sense to prescribe chemotherapy to someone who doesn’t have cancer (or who has a very localized cancer that can be surgically removed), it doesn’t make sense to propose a huge refactor to fix a problem that no one actually experiences or one person experiences rarely. 

Third, if the person you’re talking to does experience this pain, ask what obstacles they see for fixing it, and what solutions they might propose. Your colleagues have a different perspective on the system than you do; they might think of obstacles and solutions that had not occurred to you. Don’t refute these ideas in this meeting, even if you don’t like them or don’t think they’re worth considering. Your job, in these meetings, is to make colleagues feel heard, so that a) you can propose a solution that is most beneficial for the team and b) your audience will feel compelled to hear you out when it’s your turn.

Once you’ve talked to each of your teammates individually about the problem, take the time to revisit your solution and incorporate their input. If they brought up things you had not considered, think about how to address them. If they brought up solutions that look different from yours, consider the tradeoffs of each. 

Once you have done this, it’s time for another round of talking to teammates. Explain that you’ve been thinking about the problem, and ask what they think of the solution you’ve come up with at the end of your revisiting period. Here, because you requested their input and you’re talking to them one on one, they’ll be more likely to share their objections than they would be in a big meeting. These objections are gold to you: they are the reasons why your team might resist your solution, and you’ve given yourself the chance to address them up-front. To the extent that you can address them, you reduce resistance to the change. For those you cannot address, you have at least made your team feel heard. I offer more ideas about what to say in this meeting right here.

Once you’ve completed a second round of talking to your team, you have reached a more appropriate time to introduce your idea in a large meeting. This introduction, however, should include specific attention to the context problem: how are you going to restore the context that you’re about to destroy by making this change? What preventive and therapeutic treatments will you use to preserve all the context you can and heal all the context you can’t? Are you going to meet with the team to collectively design the solution? Will each pull request require some number of reviews from your team? Will your documentation strategy address any process changes you’re introducing, and will you specifically notify the individuals that the process changes affect?

Your context mitigation strategies will help you address even the hidden objections your colleagues may not have mentioned to you—their worries about their own context and their own power. Your change is not only more likely to get through; you’ll have also strengthened your trust relationships on your team.

These sorts of strategies can feel superfluous to the individual contributor who is accustomed to thinking of the code as the work. To this person, all of this talking and revisiting and reflecting and convincing feels, as Michael Feathers puts it in Working Effectively with Legacy Code, “suspiciously like not working.” But we’re knowledge workers in an environment where context is king. Building a shared understanding, more often than not, is the work. And the further we progress as engineers, and the larger the change we get to implement and oversee, the more critical it becomes for us to integrate this work into our daily habits. At scale, it’s exactly how we’ll get anything done.

The post How do we get a tech team to make a big technical change? appeared first on Stack Overflow Blog.

Cassidy and Ceora talk with Astro creator Fred K. Schott and Cloudflare’s Brendan Irvine-Broque and Michael Hart about the intersection of open source and AI. Plus: Cassidy’s impressive robot credentials.

Episode notes:

Cloudflare offers zero-trust security and performance tools for web and SaaS apps.

Cloudflare Workers allows devs to deploy serverless code globally to over 285 data centers around the world.

Astro is an open-source web framework built for speed. Houston is a bot that lets you chat with their docs.

Check out Confbrew, a conference session Q&A bot from Markprompt and Contenda (where Cassidy is CTO). 

Connect with Brendan on LinkedIn or follow him on Twitter.

Connect with Michael on Twitter.

Connect with Fred on LinkedIn.

While you’re at it, follow Ceora and Cassidy on Twitter. 

Shoutout to Lifeboat badge winner The Nail for saving if->return vs. if->else efficiency from oblivion.

TRANSCRIPT

The post Read the docs? We prefer to chat with them (Ep. 568) appeared first on Stack Overflow Blog.

Over the years, we’ve learned so much from this survey. The last three years have been pivotal in the tech sector, and the responses of the Stack Overflow community have uniquely told that story.  In 2020, before the pandemic truly began, the community told us that the SRE/DevOps contributors among you were the highest-paid developers, even before the internet was our sole source of comfort during lockdowns. In 2021, we saw fluctuations in the job status and more developers turning to school full-time, especially in India, where there was a nine percentage point increase from 2020. Last year, 46% of our respondents said they spend at least 30 minutes a day answering questions, quantifying with time the value our community takes pride in: knowledge-sharing!  

This year, we want to know how these things have changed and will be exploring further the shift towards artificial intelligence (AI) and machine learning (ML) in software development. We want to know how developers are using these technologies, what challenges they face, and what opportunities they see.

As always, we will be using Qualtrics as our survey platform. If you use a third-party ad-blocking plugin, you may see error messages during the survey period, so we ask that you specifically unblock Qualtrics in your plugins or pause the plugin while you take the survey.

Unfortunately, Qualtrics blocks certain countries from accessing their site and data, including Cuba, Iran, North Korea, Syria, and the Crimea region of Ukraine (including Sevastopol). We acknowledge that some users in China may have issues due to restrictions imposed by local internet service providers. 

As always, we need your help to make this survey representative. Share this far and wide! Drop it in company chat channels. Post it on LinkedIn and other social networks. Do a dance about it on TikTok. 

We are grateful to those who take the time to participate and share their feedback on the tools and trends that are shaping software development. Your contributions allow us to help everyone understand how the industry is changing and make everyone feel like a community here at Stack Overflow.

Special thank you to all the folks on Meta who helped with the tech lists this year—from new suggestions to capitalization/name corrections—you were instrumental in crafting the most robust technology lists we’ve had in years.

Take the survey now.

The post The 2023 Developer Survey is now live! appeared first on Stack Overflow Blog.

From the blog

Instantly verify your customers online with Open Banking APIs stackoverflow.blog
Want to make sure you’re not taking money from criminals? There’s an API for that.

The worst coder in the world tries an AI sidekick stackoverflow.blog
Look out, world! The worst coder is back and ready to create code he doesn’t understand.

Looking for job perks? How about saving the world? stackoverflow.blog
If you find yourself on the receiving end of a layoff—or feeling existential dread more generally—the timing might be right for a major life change.

Is this the AI renaissance? stackoverflow.blog
Paul van der Boor, Senior Director of Data Science at Prosus, talks about the world of generative AI, the power of collective discovery, and the gap between a shiny proof of concept and a product that people will actually use.

Get compliant without spreadsheets for SOC 2, GDPR, and more promotion
Compliance shouldn’t require countless hours and manual tasks. With 75+ integrations, Drata connects your tech stack to your framework controls—automating evidence collection and risk assessments. Request a demo and receive a special offer here.

Interesting questions

Two EXACTLY the same .jpg images with one image more than twice the file size of the other – Why? (PART 2) photo.stackexchange.com
When your metadata is as large as your data.

PhD advisor with apparent mental deterioration academia.stackexchange.com
In delicate situations that will affect your career greatly, ask for guidance from a higher power. Like the dean.

Is it possible to generate a file with a given sha256sum checksum? security.stackexchange.com
Sure, if you want to use the computing power of the whole world over the entire lifetime of the universe to reverse engineer it.

What dice do I need to display every integer up to X? codegolf.stackexchange.com
For folks who really like their six-sided dice.

Links from around the web

Container query units and fluid typography moderncss.dev
Fluid typography is when your font sizes are responsive to your screen size. This has historically been tough to achieve, but not anymore with modern CSS!

A completely non-technical explanation of AI and deep learning www.parand.com
If you’ve ever struggled to explain AI to your non-technical friends and family, here’s a great story-based approach.

The potentially dangerous non-accessibility of cookie notices www.smashingmagazine.com
Chances are you’ve seen a cookie consent banner somewhere on the internet. If you have to implement them yourself, keep in mind some of these tips to keep your sites accessible.

Five topics you should touch on during the recruitment process dev.to
Job hunting can be daunting, and sometimes you draw a blank when they ask if you have questions. Here are some topics to keep in your back pocket.

If you’re curious about our other products: How to get started with Stack Overflow for Teams.

The post The Overflow #176: Jobs that save the world  appeared first on Stack Overflow Blog.

The home team talks with Luca Galante of Humanitec about how platform engineering is more art than science, how self-service platforms empower developers with “golden paths,” and why he’s excited, not anxious, about AI tools (at least for now).

Episode notes:

Luca currently heads up product at Humanitec, a platform orchestrator that provides self-service “golden paths” for developers.

Get up to speed (or refresh your memory) on what platform engineering involves and what an internal developer platform is.

Dynamic configuration management (DCM) is a methodology for configuring compute workloads.

Stop by the Platform Engineering Slack channel.

Hear from top DevOps and platform engineering leaders at PlatformCon 2023, a virtual event held June 8-9.

Find Luca on LinkedIn and Twitter.

Cheers to Lifeboat badge winner Devart for rescuing How can I show the table structure in SQL Server query? from the dustbin of history.

TRANSCRIPT

The post Building golden paths for developers (Ep. 567) appeared first on Stack Overflow Blog.

It’s unlikely that the perfect role is going to come to you; however. You’re going to need to put in the time and effort — which is understandably tough for people with busy schedules. 

We put together this collection of tips to help you stay focused and execute. 

1. Stop making excuses for why you can’t do it 

What if you have no previous experience in climate tech? What if you haven’t taken a single environmental science class? Don’t rule yourself out. Your skills could be the perfect fit for the right role.

Instead of worrying about why you can’t make a transition into climate tech, shift your attitude to finding an employer who will support your transition. 

“Since so many of us in climate have come from tech (myself included), there has been tremendous support from all corners of the climate community to welcome and assist tech workers interested in making the leap,” explains Jonathan Strauss, CEO and co-founder at Climate Draft, a coalition of climate tech companies and VCs, in an article for Business Insider.

2. Don’t expect recruiters to find you

Unlike larger companies with in-house and external recruiting forces (i.e. budget) to deploy campaigns on LinkedIn and other employer branding platforms, climate tech startups may be a bit more behind the scenes.

 Just because you’re not receiving an influx of messages on LinkedIn doesn’t mean the jobs aren’t out there. But you’ll need to look beyond your inbox. 

At the time of writing this article, there were 5,205 jobs posted on the Climate Draft job board. Remember that your objective is to find just one job, in an ocean of many, that’s right for you.

3. Explore climate-tech focused job boards

Climate Draft isn’t the only resource to help job seekers find careers in climate tech. 

As the industry continues to heat up (bad pun), so will the economic movement that ensures continuity of life on our beautiful planet. Unsurprisingly, indie platforms are emerging to help people apply for jobs—and why not? Recently, on the Stack Overflow Podcast, we interviewed one entrepreneur who bootstrapped his niche job board business to $60,000 per month.

Looking for a great job board? Here are some options to help you get started:

• Climate People
• Climatebase
• Climate Jobs List
• Wellfound (formerly AngelList Talent)

Keep your eyes open for more job boards and communities to spring up. As interest in climate tech grows, so will ancillary organizations. If you don’t have time to spend searching on Google, you can try ChatGPT or follow people talking about climate tech jobs on LinkedIn (like this awesome VC, Taj Ahmad Eldridge, who regularly shares insights about sustainability investment trends).

4. Follow the financing

You can streamline your job search by going directly to VC firms. Many will feature their portfolio companies and open roles. 

When browsing through VC firms, it’s helpful to know what stage of company you’re targeting. You may also want to dig deep into your VC’s values and reputation to see if they align with the purpose that you’re seeking out.

Climate Tech VC is a helpful resource where you can browse investors and access a range of educational resources about the market. Crunchbase is another platform to learn about investors and their portfolio companies.

As you research venture financing and deal flow, keep your eyes open for VCs who demonstrate a clear commitment to protecting the environment. If you find investors or firms that interest you, you can consider signing up for their email list 

5. Join a cohort-based community

Especially if you’re working at a job that makes you feel unhappy—or you’re recovering from the emotional setback of getting laid off—it’s a great change of pace to step outside of your comfort bubble. Peer-based learning experiences can help you gather new perspectives.

One helpful resource is Terra.do, which is a global professional network. There are a range of online courses for building new skills, in addition to forming a new professional network. Terra regularly hosts virtual career fairs where job seekers can meet employers.

Independent communities seem to be popping up everywhere, which makes sense given the passion people feel for protecting the environment. Check out The Impactful, which recently launched this Climate Career Toolkit.

6. Create your own job by building direct relationships with employers.

Climate tech is, to some extent, a nascent ecosystem—a new economic movement that people are building from the ground up. The foundational objective is, at its core, to make the planet safely inhabitable for more people, for more time.

As with any new movement, people are figuring their stuff out. Founders, especially, may not be aware of the roles for which it makes sense to hire. If you’re a particularly talented tech-human, there’s nothing stopping you from reaching out to the founding team, saying hello, introducing yourself, and sharing the skills that you bring to the table.

You may find that newer company cultures, especially at the early startup stages, are open to hearing from prospective talent — especially since they don’t have recruiting budgets. You’re actually saving them time by proactively reaching out.

Stay focused on the big picture

The Intergovernmental Panel on Climate Change (IPCC), made up of the world’s leading climate scientists, recently published the sixth and final part of its report. The message is simple, direct, and clear.

“This report is a clarion call to massively fast-track climate efforts by every country and every sector and on every timeframe,” said António Guterres, United Nations Secretary General. Our world needs climate action on all fronts: everything, everywhere, all at once.”

The IPCC is also optimistic that a warming limit of 1.5 degrees is entirely possible by means of focused, collective action. 

How’s that for motivation?

If you end up pursuing a new role at a climate tech startup, you’ll likely need knowledge-sharing infrastructure at your company to make fast engineering decisions.  Learn how Stack Overflow for Teams can help.

The post How to land a job in climate tech appeared first on Stack Overflow Blog.

The nature of these challenges evolve as time goes on, but some things stay consistent in how you view the challenges and how folks can work to make sure that you get back to good reliably. And to be clear, we aren’t talking about run of the mill production bugs, we are talking about issues that are large and sweeping but at the same time delicate and brittle. 

Having done more than my share of organizing and solving some of the big challenges organizations face when these events happen, I have a high-level playbook that I try to make sure my team follows when things fall apart. A lot of these expectations started to take shape during my first big outage as a developer. This helped me understand what people should do as developers, SREs, managers, and everything in between. And the cause of this first big outage: a brand new checkout process on an ecommerce site. All of these takeaways are applicable for folks at all levels, and hopefully can give some insights into what folks in other roles go through.

Step 1. Don’t panic and identify your problem.

My very first “outage” came when I was a developer working on an application that had a new checkout process. It was nothing fancy, but like all applications at one point or another, this key piece of functionality stopped working with our newest launch. As if people not being able to check out and complete sales wasn’t bad enough, shopping carts lost items and product descriptions were showing up blank. Pieces that weren’t within scope or crossed our mind to test stopped working. We immediately grabbed folks into a room to get to work and figure it out. 

Our first instinct right away was “Quick, roll it back!” This was an understandable feeling to have, we introduced problems, and naturally you want to take the problems away. But with quick actions come quick mistakes, and a seasoned senior developer stopped everyone from scrambling to ask the pertinent question: “Well, why isn’t it working?” In my mind I was screaming “Who cares! Our embarrassing mistake is out there for the whole world to see!” But the calm nature and analytical demeanor of this senior developer settled us down and assured us that what we were doing right now in that room was the right thing to do: ask questions and investigate. 

Step 2. Diagnosis and understand the source(s) of your problem

This sounds like an obvious thing, but with concern and panic overtaking the team, not enough folks asked us why things were breaking. The senior engineer left the problem out in the wild for a full 30 minutes after we found it to make sure we knew why it wasn’t working. We checked and double checked exception logs, we did a few different checks with separate workflows, and even checked if there was anything odd at a systems level. After all, we had good development environments setup to replicate production, and things were breaking so double and triple checking ourselves became important. Retracing these steps with new context from the errors we were seeing helped us go through all of these steps in a new light. After we had enough to know what we did wrong, and gathered enough confidence for next time we release, we then started our rollback. It is a delicate balance, but I learned to always take all the opportunities you can before a rollback before you lose your best source of information to find the root of your problem: the actual problem in the wild.

The same senior dev who was tempering our poorer instincts was the one who took “point” or tech lead during this time, while relying on our director to be the incident leader. You will hear many names for these roles, but they are someone who is technical and can help coordinate those efforts (usually a more senior developer) and someone who is responsible for communicating around it and giving air cover for those who may want to take time away from the fixes (usually a director or engineering manager). This is to protect the most valuable resource during a crisis: The time and focus of those who can actually implement the plan to fix.

The more technical person will be there to help set milestones and delegate or divvy up the work that needs to be done. The incident leader, as they are often ironically named, are there to facilitate and not to dictate. I remember hearing from my mentor at the time that the best incident leaders asked two questions: “Where are we at?” and “What do you need?” The first so they could keep people off our back, and the second so the last thing our engineers had to worry about was resources, including time. 

Step 3. Remediation: let’s start working on the problem.

We know we have a problem, we know the source of the problem, now let’s make a plan and fix it. We all love to jump to this step, go right into fixing it. And sometimes we have that luxury for simple issues where the problem is so apparent that confirming and understanding the source of the problem, or problems, are very quick steps, but most times if the problem has made it this far and is this impactful, we need to be more deliberate. Much like how we were potentially shooting ourselves in the foot by instinctually rolling things back too quickly, the same instinct to just fix it can come up, 

This point person is going to help prioritize the work to do, find out where the biggest mitigation steps are, and make sure that other stakeholders have clear expectations of the impact. As a developer working on an issue, you also have a responsibility to hold this person accountable, make sure they give you the resources you need to help figure out the issue. This can be time, access, or other people who have answers you don’t. And this is an important theme throughout this phase: Give the engineers what they need to fix things. Arguably this should be a theme for all of engineering leadership, but nothing more pronounced than when things have gone down and vital workflows have gone silent.  

When we were working on the checkout bug, the biggest piece missing was not information or other developers to help, but focus. This may sound odd, but I am willing to bet it is a familiar feeling to any who have been in the boat with leaders who are panicky or never understood the fallacies of the mythical man month. The leaders were eager for progress updates, and what better way to get those updates than to get everyone in a meeting together four times a day to tell us how things progressed. That means every two hours we lost 30 minutes, had to context switch, and update tracking sheets.When I told my tech lead about this, he immediately had the meeting moved down to once a day for developers, and optional at that. The speed gains from this alone were huge; being able to focus and remove distractions was the bigger factor for remediating the problem. 

Step 4. Verification and learnings

If all goes well, tests are confirmed, and all the valuable information you got from steps 1 and 2 have led to confidence in your new test plans, you can move the fix out to production. Once it is out live, lean on your teammates in all departments to confirm and explore. Interestingly, I have found time and again that if patience and freedom are given to the engineers at the beginning of these incidents, there is a correlated confidence and calmness to the subsequent release and fix. 

However, once the fix is out live and everyone feels strongly about the current state, your work is only half done. Now you need to make sure that expensive, hard earned lessons from this problem grow your whole organization. People often take the measure of a good retrospective from big events like this as problems never happening again, but that is plainly unreasonable to any reasonable person. Often I have found the best learning is how we can DEAL with problems better, not pretend like we can make them go away.

In the end for our checkout issue, it all came down to a missed release step by our deployment team. An honest mistake that can happen to anyone. This doesn’t mean we ignore the issue: we thought of adding redundancy or perhaps trying to automate certain bits more, but that wasn’t the best bit that we learned. Our tech lead was far more focused not on preventing errors, but sharpening our ability to deal with them. Though they wanted to prevent future errors, they saw a lot more room to improve in how we respond to the error. What did we learn about engineer focus time? Where were we able to investigate quickly? Slowly? And even good questions outside of engineering such as who was best at handling comms and what was the info they needed?

There have been shades of this outage throughout almost two decades of my career, and I have no doubt the days of having to deal with things like it are coming to a comfortable middle. But the themes of how to approach it, process it, and most importantly enable my team to tack it tend to be the same. 

The post Don’t panic! A playbook for managing any production incident appeared first on Stack Overflow Blog.

Ben and Ceora talk through some thorny issues around AI-generated music and art, explain why creators are suing AI companies for copyright infringement, and compare notes on the most amusing/alarming AI-generated content making the rounds (Pope coat, anyone?).

Episode notes:

Getty Images is suing the company behind AI art generator Stable Diffusion for copyright infringement, accusing the company of copying 12 million images without permission or compensation to train its AI model.

Meanwhile, a group of artists is suing the companies behind Midjourney, DreamUp, and Stable Diffusion for “scraping and collaging” their work to train AI models. 

One of those artists, Sarah Anderson, wrote an op-ed in The New York Times about seeing her comics gobbled up by AI models and regurgitated as far-right memes.

Speaking of copyright violations, did Vanilla Ice really steal that hook from David Bowie and Freddie Mercury? (Yes.)

Check out the AI model trained on Kanye’s voice that sounds almost indistinguishable from Ye himself.

Read The Verge’s deep dive into the intersection of AI-generated music and IP/copyright laws.

Watch the AI-generated video of Will Smith eating spaghetti that’s been called “the natural end point for AI development.”

ICYMI: The Pope coat was real in our hearts.

Columbia University’s Data Science Institute recently wrote about how blockchain can give creators more control over their IP, now that AI-generated art is clearly here to stay.

Congrats to today’s Lifeboat badge winner, herohuyongtao, for answering How can I add a prebuilt static library in a project using CMake?.

TRANSCRIPT

The post When AI meets IP: Can artists sue AI imitators? (Ep. 566) appeared first on Stack Overflow Blog.