Stack Overflow Blog: Recent Episodes
None
Ryan is joined by Coder’s Rob Whiteley to chat about why tokenmaxxing isn’t proving real value and just triggering Goodhart’s Law, how release speed and PR merges can help you measure agentic outcomes with or without a human-in-the-loop, and what the democratization of skills means for junior developers and the talent pipeline.
Ryan welcomes McLaren Stanley, Senior Principal Engineer for Amazon Stores, to discuss what it actually takes to make teams AI native, why agentic engineering is shifting code bottlenecks downstream to testing and deployment, and why robust validation is essential to build trust and enable “fearless commits.”
The “find the special ones and promote their traits” approach isn’t the best or only way to drive AI adoption and productivity on an engineering team.
Ryan welcomes Anurag Goel, CEO and co-founder of Render, to discuss why most startups shouldn’t start by managing their Kubernetes and cloud infrastructure.
Your semantic layer is a risk mitigation strategy. Not risk in the abstract, compliance-framework sense, but the practical, operational risk that quietly drains organizations every day.
Ryan welcomes WPEngine CTO Ramadass Prabakar to the show to chat about what happens—and what we should do—when agents start acting like humans online, how our internet is evolving to serve both human and agentic experiences from the same interface, and what we can do to differentiate and protect human actions online from malicious bot activity.
Introducing new Stack Internal capabilities as part of our upcoming platform experience. Our latest release turns your existing foundation of knowledge into enterprise memory that your people, teams, and AI agents can act on. Learn how we’re building the trust layer for enterprise AI.
The tools themselves are new and their capabilities are in constant flux. If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in. But it also points to a flaw in how you use that tool, the process around it, and the way the tool reinforces the process.
Ryan is joined by Asaf Savich, Komodor’s AI Engineering Group Manager, to discuss why modern reliability work requires navigating massive cross-service context, what good context engineering actually likes when AI is integrated into site reliability, and how the work of human SREs is shifting towards strategy and AI agent management.
In this No Dumb Questions, Stack's Director of Data Science Michael Foree teaches Phoebe about AI context, context engineering, and what she can do to become a better context engineer.
Ryan welcomes VoidZero’s Evan You and Cloudflare’s Dane Knecht back to the show to discuss Cloudflare’s recent acquisition of VoidZero and what it means for JavaScript development, how partnerships like theirs can help open-source projects stay maintained and sustainably monetized, and how Cloudflare’s distributed systems are helping to improve developer experience in Vite and beyond.
Live from Snowflake Summit, Ryan talks with Snowflake’s Head of Developer Experience Umesh Unnikrishnan about the industry-wide shift from “vibe coding” for quick prototypes to agentic engineering for enterprise-ready software, how enterprises can scale governance with guardrails like human-in-the-loop approval and control layers that go beyond the underlying LLM, and why Umesh predicts all developers will become someday become full-stack builders.
At MS Build, Ryan is joined by Cassidy Williams, Senior Director of Developer Advocacy at GitHub and former Stack Overflow Podcast host, to discuss how agentic coding is shifting dev work towards higher-level strategy while increasing decision fatigue; why human taste, community feedback, and mentorship are becoming more essential than ever for developer careers; and the new GitHub Copilot announcements coming out of Microsoft, including the new GitHub Copilot app.
Recorded at Microsoft Build, Ryan welcomes Sarah Bird, Microsoft’s Chief Product Officer for Responsible AI, about how we can build and use AI responsibly with the NIST approach, why most irresponsible AI comes from experimentation without thought of impact, and how Microsoft is researching thoughtful human/AI workflow design to reduce unnecessary escalation.
Live from Microsoft Build, Ryan is joined by Jay Parikh, Microsoft’s VP of AI Core, for a conversation on what enterprises need to build, deploy, and run AI agents at scale with demonstrable ROI; how Microsoft built an end-to-end agent development system that goes past just the harness; and how you can evaluate for reliability and correctness in models that get more intelligent and autonomous everyday.
Ryan is joined by Rosemary Wang, Developer Advocate at IBM, to explore what infrastructure-as-code looks like once AI starts writing and deploying it.
Ryan welcomes Saahil Jain, CTO of You.com, to discuss why building agents with a 2024 mindset is a mistake as modern models improve at long-horizon tasks, why heavy orchestration layers can hurt model performance more than help it, and why the 2026 competitive edge actually comes from information retrieval and unique data paired with end-to-end evaluation.
Signature-based detection has always known what it was looking for. Machine learning and autonomous agents are changing the question entirely, shifting from "does this match a known pattern?" to "does this actually make sense in context?"
Ryan welcomes Benny Chen, co-founder of Fireworks AI, to the show to explore what actually makes an AI application good or not, how to balance qualitative signals with quantitative metrics when evaluating AI, and how open-source eval protocols and community efforts are setting the standard for AI evaluation.
Vivek Raghunathan, SVP of engineering at Snowflake, joins Leaders of Code at Snowflake Summit to break down the five-stage framework his org used to go from "let chaos reign" to a repeatable, org-wide system for AI-assisted engineering.
Ryan sits down with Frank Portman, CTO at Yobi, to talk about why next-token prediction, though great for language, isn’t the right inductive bias for forecasting human behavior. They discuss how Yobi builds a “foundation model of behavior” using transformers and graph neural networks instead of chat-style LLMs, and what it takes to run millions of personalization decisions per second while keeping consumer data private.
If you want your values to spread throughout the industry, the best thing you can possibly do is succeed and make others want to imitate you.
Ryan sits down with Anish Agarwal, CEO and co-founder of Traversal, to chat about why AI coding agents have made writing code easier but running it safely in production harder, why production failures are really caused by interactions between systems and not just the code itself, and how teams can troubleshoot more effectively when traditional observability tools are not enough for agentic AI workflows.
Once again, we're asking for your help to take the temperature of software development.
Ryan is joined by Jeffrey Hightower, VP of Places Data at Microsoft, and Amy Rose, CTO of the Overture Maps Foundation, to chat about their partnership in bringing spatial data to the next generation of Microsoft tools; how Overture’s 50 organization members are creating open, standardized, and interoperable global spatial data sets; and their solutions to the innate challenges of trying to digitally map the world.
Designing contract-bound AI agents for high-stakes execution.
Ryan welcomes Cricket Liu, DNS expert and Chief Evangelist at Infoblox, to the show to talk all things DNS. They cover the evolution of one of the oldest DNS server implementations, BIND, and what the future holds for protected DNS configurations; the realities of security threats like DDoS and DNS spoofing; and why outages often trace back to a lack of understanding of DNS’s fundamental role.
Engineering teams have upgraded their tools. Have they upgraded how they work?
How attackers took twenty thousand Instagram accounts by asking Meta's AI politely, and why that failure is about to become common.
Recorded live at the AI Agent Conference, Ryan sits down with Apollo GraphQL CEO Matt DeBergalis to discuss how enterprises can leverage GraphQL and MCP as a structured semantic architecture to feed clean data to autonomous agents, safeguard internal microservices against unprecedented "east-west" data exfiltration risks, and rein in skyrocketing token spend by explicitly querying only the exact context required.
Capacity is one of the hardest problems because it sits at the knotty, gnarled-up intersection of so many other hard problems.
Ryan welcomes Trisha Gee, a Java champion and developer productivity advocate, to explore how AI is transforming the role of IDEs and the broader developer experience; the relevance of traditional tools, muscle memory, the risks of hype; and how to adapt workflows for AI-driven development.
On this episode of Leaders of Code, Eric Anderson, director of engineering at Intuit, joins Stack Overflow engineering director Ben Matthews to talk about what happens to software teams when AI makes code generation seemingly free.
If your coding agent has questions, Stack Overflow for Agents has answers, now in beta.
Ryan welcomes Bryan Clark, director of product for Lakebase at Databricks, to discuss what happens when AI agents become the primary creators and users of databases; why agents are “sloppy” about cleaning up infrastructure; and how database branching, scale-to-zero, and centralized access control can help teams keep up with agent-driven development.
AI reliability issues stem from three separate architectural challenges that keep getting lumped into the same category. Prompt engineering alone can't fix them. But the sourcing and verification frameworks media organizations have used for centuries translate into clear engineering solutions developers can implement today.
Ryan welcomes back Tanya Janca, now part of the OWASP Top 10 team, to discuss what changed in the latest OWASP Top 10 release, how the list shifted from “outdated components” to a broader software supply chain focus, and why they added memory safety and vibe-coding as awareness items.
From the floor of HumanX, Ryan welcomes Songyee Yoon, managing partner at Principal Venture Partners (PVP), to chat about AI development outside the US, from the need to adapt models to local languages and culture to the challenges of the global supply-chain for things like semiconductors to how venture capital is looking at international AI companies.
In this special episode, Ryan is joined by our Senior VP of Community, Philippe Beaudette, and the Trust and Safety team at Stack Overflow to discuss maintaining platform integrity and managing user safety, handling complex issues like harassment, and how their team balances transparency and privacy online.
In this episode of Leaders of Code, Jody Bailey, Chief Product and Technology Officer at Stack Overflow, sits down with Dane Knecht, the newly appointed Chief Technology Officer at Cloudflare.
As a generation characterized as "digital natives," the way Gen Z interacts with and consumes knowledge is rooted in their desire for instant gratification and personalization. How will this affect the future of knowledge management and the technologies of tomorrow?
It’s Java’s 30th anniversary! Ryan welcomes back Georges Saab, Senior VP of Development for the Java Platform Group and Chair of the OpenJDK Governing Board, to reflect on Java’s changes over the last five years.
Ryan Donovan and Ben Popper sit down with Jamie de Guerre, SVP of Product at Together AI, to discuss the evolving landscape of AI and open-source models. They explore the significance of infrastructure in AI, the differences between open-source and closed-source models, and the ethical considerations surrounding AI technology. Jamie emphasized the importance of leveraging internal data for model training and the need for transparency in AI practices.
Diverse, high-quality data is a prerequisite for reliable, effective, and ethical AI solutions.
Ryan and Ben welcome Tulsee Doshi and Logan Kilpatrick from Google's DeepMind to discuss the advanced capabilities of the new Gemini 2.5.
Kathleen Vignos, VP of Software Engineering at Capital One, sits down with Ryan to explore shifting to 100% serverless architecture in enterprise, deploying talent for better customer experience, and fostering AI innovation and tech advancements in a regulated banking environment.
Ryan is joined by Jan Seredynski, Mobile Security Researcher and Pentester at Guardsquare, to talk about how you protect your app when the attackers control the code and the device it runs on.
Snowflake customers can now easily enrich their AI applications and agentic systems with some of the most trusted, highest-quality data available while respecting our community members who provide this content with proper attribution.
Will Wilson, CEO and co-founder of Antithesis, joins Ryan and Stack Overflow senior director of engineering Ben Matthews on the podcast to discuss deterministic simulation testing, the pitfalls of chaos testing in an AI-driven world, and how testing can help developers deal with technical debt.
Positioned at the intersection of automation, decision intelligence, and data orchestration, AI agents are quickly emerging as essential tools for aligning business outcomes with technical workflows.
Ryan welcomes Glen Coates, VP of Product at Shopify, to dive into the intricacies of managing a developer-focused product, the challenges of backwards compatibility, and the implications of AI and LLMs in Shopify's development environment.
This year, we're not just collecting data; we're reflecting on the last year of questions, answers, hallucinations, job changes, tech stacks, memory allocations, models, systems and agents—together.
What challenges do organizations face when adopting AI, and why is understanding its limitations key to success?
We’re always trying to make it easy for users to pick out the information they need and gain insights into their processes, so a natural language interface seemed like a dream.
The 2025.4 Stack Overflow for Teams Enterprise (SOE) release is all about helping teams work more seamlessly across tools, departments, and knowledge silos.
Douwe Kiela, CEO and cofounder of Contextual AI, joins Ryan and Ben to explore the intricacies of retrieval-augmented generation (RAG). They discuss the early research Douwe did at Meta that jump started the whole thing, the challenges of hallucinations, and the significance of context windows in AI applications.
Kyle is joined by his former colleague Tyler McEntee, now a senior software engineer at Jona, to talk about doing everything all at once at a startup.
Matthew McCullough, VP of Product for Android Developer Experience, sits down with Ryan to talk advancements in Android development, enhancing developer efficiency and reducing routine toil, and the application of Gemini AI models to improve software toolchains.
As we envision what the ideal future version of Stack Overflow looks like, we’re committed to engaging with our community.
Ryan is joined by Jeremy Edberg, CEO of DBOS, and Qian Li, co-founder of DBOS, to discuss durable execution and its use cases, its implementation using technologies like PostgreSQL, and its applications in machine learning pipelines and AI systems for reliability, debugging, and observability.
An update to the research that the User Experience team is running over the next quarter.
Christophe Coenraets, SVP of Developer Relations at Salesforce, tells Eira and Ben about building the new Salesforce Developer Edition, which includes access to the company’s agentic AI platform, Agentforce. Christophe explains how they solicited and incorporated feedback from the developer community in building the developer edition, what types of AI agents people are building, and the critical importance of guardrails and prompt engineering.
Maryam Ashoori, Head of Product for watsonx.ai at IBM, joins Ryan and Eira to talk about the complexity of enterprise AI, the role of governance, the AI skill gap among developers, how AI coding tools impact developer productivity, what chain-of-thought reasoning entails, and what observability and monitoring look like for AI.
On this episode, Ryan chats with Henrik Rexed, Cloud Native Advocate at Dynatrace, about debugging cloud-based applications like you would a local app.
If velocity is just a tool and not a goal, how do you measure real success for engineering teams?
Ben Popper chats with CTO Abby Kearns about how Alembic is using composite AI and lessons learned from contract tracing and epidemiology to help companies map customer journeys and understand the ROI of their marketing spend. Ben and Abby also talk about where open-source models have the edge and the challenges startups face in building trust with big companies and securing the resources they need to grow.
This post explores crucial lessons learned in the trenches of data licensing, drawing insights from Stack Overflow and the growing importance of socially responsible data practices in a changing internet landscape.
The world has changed a lot since Stack Overflow started. It's time for our brand to change with it.
How can engineering teams move beyond traditional metrics like velocity to create real business impact?
Community “management” at its core is supporting and enabling communities to manage themselves.
Ryan welcomes Jeu George, cofounder and CEO of Orkes, to the show for a conversation about microservices orchestration. They talk through the evolution of microservices, the role of orchestration tools, and the importance of reliability in distributed systems. Their discussion also touches on the transition from open-source solutions to managed services, integration opportunities for AI agents, and the future of microservices in cloud computing.
You might already be familiar with the programming language best suited to building on blockchains.
At HumanX 2025, Ryan chatted with Rodrigo Liang, cofounder and CEO of SambaNova, about reimagining 30-year-old hardware architecture for the AI era.
Avoiding bad data is just as important in AI; it can open you to fines, lawsuits, and lost customers.
Ryan talks with Greg Fallon, CEO of Geminus, about the intersection of AI and physical infrastructure, the evolution of simulation technology, the role of synthetic data in machine learning, and the importance of building trust in AI systems. Their conversation also touches on automation, security concerns inherent in AI-driven infrastructure, and AI’s potential to revolutionize how complex infrastructure systems are managed.
Financial institutions face a balancing act between tech innovation and strict regulations. As customer expectations for improved user experience and demands from those tasked with enhancing features keep rising, engineering teams need to find a harmonious middle ground.
On today’s episode we chat with Crystal Xu, chief of staff at FSH Tech. She explains how she learned to build and deploy apps and services inside her company using Python and Java, without ever getting a traditional computer science education or training to write code. Instead, Xu works with GenAI systems like ChatGPT, Cursor, and Replit to build software through prompt engineering.
We explore how our platform is evolving to support a new framework and business model, knowledge-as-a-service, and how we will incorporate this with our ongoing investment in our community.
On today’s episode we chat with David Mytton, CEO of Arcjet and co-founder of Console.dev. We discuss his early work in cloud monitoring, his passion for the environment, and his love for sharing great developer tools.
The internet is changing once again: it is becoming more fragmented as the separation between sources of knowledge and how users interact with that knowledge grows.
If you’re weary of reading about the latest chatbot innovations and the nine ways AI will change your daily life next year, this series of posts may be for you.
We chat with Deedy Das, a Principal at Menlo Ventures, who began his career as a software engineer at Facebook and Google. He then dipped a toe in the startup world, spending time at the company now know as Glean. More recently he started a career as a venture capitalist, investing in AI and Infra out of the Anthology Fund, a partnership between Menlo Ventures and Anthropic.
Masked self-attention is the key building block that allows LLMs to learn rich relationships and patterns between the words of a sentence. Let’s build it together from scratch.
How are developers actually using GenAI-powered coding tools now that some of the initial hype has faded?
Founder and entrepreneur Jyoti Bansal tells Ben, Cassidy, and Eira about the developer challenges he aims to solve with his new venture, Harness, an AI-driven software development platform meant to take the pain out of DevOps. Jyoti shares his journey as a founder, his perspective on the venture capital landscape, and his reasons behind his decision to raise debt capital for Harness.
Ben chats with Gias Uddin, an assistant professor at York University in Toronto, where he teaches software engineering, data science, and machine learning. His research focuses on designing intelligent tools for testing, debugging, and summarizing software and AI systems. He recently published a paper about detecting errors in code generated by LLMs. Gias and Ben discuss the concept of hallucinations in AI-generated code, the need for tools to detect and correct those hallucinations, and the potential for AI-powered tools to generate QA tests.
Today, we're excited to share details about our latest experiment that aims to make your search results in Stack Overflow for Teams Enterprise even more relevant and useful.
Ryan chats with Russ d’Sa, cofounder and CEO of LiveKit, about multimodal AI and the technology that makes it possible. They talk through the tech stack required, including the use of WebRTC and UDP protocols for real-time audio and video streaming. They also explore the big challenges involved in ensuring privacy and security in streaming data, namely end-to-end encryption and obfuscation.
Ben and Ryan talk to Scott McCarty, Global Senior Principal Product Manager for Red Hat Enterprise Linux, about the intersection between LLMs (large language models) and open source. They discuss the challenges and benefits of open-source LLMs, the importance of attribution and transparency, and the revolutionary potential for LLM-driven applications. They also explore the role of LLMs in code generation, testing, and documentation.
This release includes updates that improve subject matter expert (SME) visibility and engagement in Stack Overflow for Teams. It's also now easier to capture and discover SME knowledge in Microsoft Teams and Slack with the Auto-Answer App.
On today’s episode we chat with Mrinalini Sugosh, Dev Rel Manager CKEditor. She discusses how modern fullstack developers have to master both front and backend skills, stitch the two together, and master adjacent skills like data analysis and security compliance.
On today’s episode we speak with Kohsuke Kawaguchi, who won the Google-O’Reilly Open Source award for his work on the Hudson/Jenkins project. Kohsuke began his career at Sun Microsystems. He shares insights on the balance between community-driven open source and the need to monetize through enterprise services.
It’s tempting to push projects out the door to woo and impress colleagues and supervisors, but the stark truth is that even the smallest projects should have proper review periods.
In today's data-driven world, Apache Kafka has emerged as a cornerstone of modern data streaming, particularly with the rise of AI and the immense volumes of data it generates.
On today’s episode we chat with Pradeep Vincent, Senior Vice President and Chief Technical Architect for Oracle Cloud Infrastructure, or OCI for short. He shares experiences from his time as an engineer at IBM and what it was like to be a senior engineer working on AWS during the early years of its development as a commercial product.
Today we chat with Austin Emmons, an iOS developer at Embrace, where he spent time rebuilding their SDK to work with OpenTelemetry. He discusses the challenge of tracking performance and watching for edge cases when your app is deployed across dozens of devices with enormous variability in their hardware, software, and network capabilities.
Today we chat with Avthar Sewrathan, AI Lead at Timescale, about adapting developers’ favorite database management system, Postgres, to support a range of new technologies involved in the GenAI ecosystem, especially vector databases. Avthar details his long history with Postgres and how clients are weighing the build vs. buy question when it comes to choosing a database to support their newly minted GenAI initiatives.
On today’s episode, we chat with a listener, Geshan Manandhar, who has been working in the world of software engineering for two decades. He started programming in Kathmandu during the days of dial-up. Since then he’s worked across three continents and today is a senior software engineer at Simply Wall Street. He gives his advice on how developers can change with the times and what it’s like to move into the era of serverless containers.
The decoder-only transformer architecture is one of the most fundamental ideas in AI research.
On today’s episode, we chat with Ryan Dahl, creator of Node.js and Deno. He explains why he feels the first version of Deno has reached certain limits and what he and his team are doing with Deno 2.0 to scale up the module system and ensure it's a great tool for the modern web.
On today's episode we chat with Ilya Grigorik, a Distinguished Engineer and Technical Advisor to the CEO at Shopify. From battling hordes of bots trying to scalp seats before humans can get their hands on concert tickets, to automatically handling relevant tax codes and regulations across countries and states so small merchants can focus on their business, Ilya shares some of the projects he enjoys most and the challenges that make e-commerce interesting for software developers.
Retrieval-augmented generation (RAG) is one of the best (and easiest) ways to specialize an LLM over your own data, but successfully applying RAG in practice involves more than just stitching together pretrained models.
On this episode, Ryan and Cassidy talk to Satish Jayanthi, CTO and co-founder of Coalesce, about the growth of metadata and how you can manage it, especially in systems using generative AI. They explore the importance in providing context and transparency to data, how metadata can be generated automatically, and the future of metadata including knowledge graphs.
Ryan and Eira talk with Stack Overflow senior research analyst Erin Yepis about the results of our 2024 Developer Survey, which polled more than 65,000 developers about the tools they use, the technologies they want to learn, their experiences at work, and much more. Erin highlights what the survey reveals about devs’ favorite programming languages (JavaScript, HTML, Python), the rise of Rust, the popularity of embedded technologies (Raspberry Pi, Arduino), developer sentiment around AI, and why tech debt tops the list of developer frustrations.
Ben and Ryan are joined by Cortex cofounders Anish Dhar, CEO, and Ganesh Datta, CTO. Cortex offers an internal developer portal that helps devs document and reinforce organizational best practices and improve developer productivity. The portal includes features like scorecards that incentivize developers to improve their work and AI-powered search to make finding information easier.
An update to the research that the User Experience team is running over the next quarter.
The latest Stack Overflow for Teams release makes it easier to encourage and grow contributions to your community through the use of flexible bounties, more user search options, Slack thread summarization, and more.
Josh Zhang, a staff site reliability engineer at Stack Overflow, tells Ryan and Eira how the Stack Exchange network defends against scraping bots. They also cover the emergence of human botnets, why DDoS attacks have spiked in the last couple of years, and the constant balancing act of protecting sites from attack without inhibiting legitimate users.
In this episode, Ben interviews Jannis Kallinikos, a professor at Luiss University in Rome, Italy about his new book Data Rules: Reinventing the Market Economy, coauthored with Cristina Alaimo. They discuss the social impact of data, explore the idea that data filters how we see the world and interact with each other, and highlight the need for social accountability in data tracking and surveillance.
This year, technologies such as JavaScript and PostgreSQL remain most popular, Rust and Markdown remain most admired, developers are most frustrated by technical debt at work, and they don’t see AI as a threat to their jobs.
Ryan chats with Jon Bevan, a software engineer currently building the cloud version of Scriptrunner, an Atlassian app, about the concept of tech debt. They explore how tech debt can arise from outdated technology choices, shortcuts, and the need for maintenance work. They also delve into the challenges of upgrading dependencies and the potential scope creep of requirements and features over time.
Ben and Ryan chat with listener, professional pilot, and Java enthusiast Lenny Primak about what he finds exciting about Java in 2024.
You’re familiar with older web and pre-web languages like JavaScript and Java. Did you know that you can use these well-known languages with Web3 technologies?
A two-part episode: In part one, Ben chats with friend of the show and senior software engineer Kyle Mitofsky about Staging Ground, a private space within Stack Overflow where new users can receive guidance from experienced users before their question is posted. In part two, Ben talks to Stack Overflow moderator Spevacus, who participated in the beta of Staging Ground. They talk about why we wanted to build a safer asking experience for new users, the positive feedback we’ve gotten from the community so far, and the challenges of building Staging Ground within the existing Stack Overflow architecture.
With the ever-increasing importance of data, we’re always looking for expert voices that can expand our view of what data and our reliance on data means for software development and society as a whole. More and more of our lives are becoming data-driven. Is that a good thing?
In this episode, Ben chats with Elastic software engineering director Paul Oremland along with Stack Overflow staff software engineer Steffi Grewenig and senior software developer Gregor Časar about vector databases and semantic search from both the vendor and customer perspectives. They talk about the impact of GenAI on productivity and the search experience, the value of structured data for LLMs, and the potential for knowledge extraction and sharing.
For this episode, we spoke with Carol Lee, PhD, principal research scientist in the Developer Success Lab at Pluralsight, about her research into code review anxiety, how developers are coping, and how a workbook can help.
The home team welcomes developer and software consultant Ben Borra to the show for a wide-ranging conversation about developer productivity, the value of positive feedback and identifying quick wins, the impact of code assistants on devs’ everyday work, and the challenges of system rewrites.
Today we chat with Reshma Khilnani, co-founder and CEO of Medplum, an open-source platform enabling companies to build healthcare applications like EHRs and patient portals. She discusses how to iterate rapidly in an industry where SOC2 compliance is just the beginning (one of the compliance tests is named after Dante’s epic poem depicting the nine circles of hell, if that gives you an idea).
In 2019, as the original co-founders and hosts moved on, the Stack Overflow podcast was rebooted with a new cast of hosts. On today’s episode Ben Popper, Cassidy Williams, and Ryan Donovan sit down to discuss how much has changed in the five years they have been collaborating on Stack Overflow’s blog, newsletter, and podcast. If you you are sick of AI talk today, remember how bad the crypto craze was just two years ago!
On today’s episode we chat with Kirimgeray Kirimli, a director at Flatiron Software and CEO of Snapshot Reviews, a tool that measure developer productivity based on activity from Github, Jira, standups, and more. Kirimli explains how Snapshot Reviews tries to measure a developer's true impact, not just the volume of their activity. He also speaks to the growing power of AI coding assistants and suggests "junior engineer" is not likely to be a job available to humans for much longer.
In the latest Stack Overflow for Teams Enterprise release, you'll see reporting capabilities and insights that help demonstrate community impact. Microsoft customers can also rejoice: OverflowAI now includes an Auto-Answer App for Microsoft Teams.
Single individuals make less of a difference to the success or failure of a technology project than you might think (and that’s a good thing).
On today’s episode we chat with Cassandra Shum, VP of Field Engineering at RelationalAI, about her company’s efforts to create what it calls the industry’s first coprocessor for data clouds and language models. The goal is to allow companies to keep all their data where it is today while still tapping into the capabilities of the latest generation of AI tools.
On today’s episode we chat with Jared Palmer, VP of AI at Vercel, who says the company has three key goals. First, support AI native web apps like ChatGPT and Claude. Second, use GenAI to make it easier to build. Third, provide an SDK so that developers have the tools they need to easily add GenAI to their websites.
In this episode, Alexa Montelibano and Tiago Torre, sales engineers at Stack Overflow, take you behind the scenes to show how customer feedback shapes our products, including OverflowAI. Alexa and Tiago have been working with clients to explore the three features of OverflowAI—Enhanced Search, an Auto-answer App for Slack and Microsoft Teams, and an IDE extension.
In this episode we chat with Saumil Patel, co-founder and CEO of Squire AI. The company uses an agentic workflow to automatically review your code, write your pull requests, and even review and provide opinions on other people’s PRs. Different AI systems with specific capabilities work together as a mixture of experts, following a chain of thought approach to provide recommendations on security, code quality, error handling, performance, scalability, and more.
A look at some of the current thinking around chunking data for retrieval-augmented generation (RAG) systems.
Learn about the workflow designed to help new askers improve their questions on Stack Overflow.
This week we chat with Kamakshi Narayan, Director of Product Management at SnapLogic, who is focused on how APIs can apply fine-grained controls for privacy and governance to the LLM-powered AI apps vacuuming up our data.
Today's episode is a chat with Benjamin Shestakofsky, an assistant professor of sociology at the University of Pennsylvania with a focus on the ways in which digital technologies are affecting work and employment, organizations, and economic exchange. We discuss research from his new book which dives into the venture capital business and explores the cooperative model that some software startups are taking instead.
We also asked when and how often CodeGen tools fall short, what challenges developers face with these tools, and what they are doing with all of the free time these tools purport to offer.
Temporal is an open-source project focused on durable execution and workflow orchestration. Cofounder and CTO Maxim Fateev tells Ben and Ryan about the challenges of building a cloud service based on an open-source project and how Temporal is helping teams simplify their code and build more features more quickly.
Ben and Ryan are joined by Robin Gupta for a conversation about benchmarking and testing AI systems. They talk through the lack of trust and confidence in AI, the inherent challenges of nondeterministic systems, the role of human verification, and whether we can (or should) expect an AI to be reliable.
A developer’s journal is a place to define the problem you’re solving and record what you tried and what worked.
Ben and Ryan talk with Vikram Chatterji, founder and CEO of Galileo, a company focused on building and evaluating generative AI apps. They discuss the challenges of benchmarking and evaluating GenAI models, the importance of data quality in AI systems, and the trade-offs between using pre-trained models and fine-tuning models with custom data.
This year we are asking familiar questions about your experience, but also have some new questions about what embedded programming technology you are using and what AI ethical responsibilities are most important to you.
Product manager Ash Zade joins the home team to talk about the journey to OverflowAI, a GenAI-powered add-on for Stack Overflow for Teams that’s available now. Ash describes how his team built Enhanced Search, the problems they set out to solve, how they ensured data quality and accuracy, the role of metadata and prompt engineering, and the feedback they’ve gotten from users so far.
We're excited to announce the general availability of OverflowAI to Stack Overflow for Teams! OverflowAI represents a big step forward in our vision of integrating GenAI offerings within knowledge communities.
On this episode: Al Sweigart is a software developer, developer advocate, and author of ten Python books. He tells Ben and Ryan why he’s such a fan of the language, why it’s a great programming language for beginners, and how it became the default for so many data science and backend AI projects.
Only about 5% of GenAI projects lead to significant monetization of new product offerings.
Eira and Ryan talk with Chris Ferdinandi, a front-end developer and ADHD advocate, about his diagnosis experience, the importance of accommodations for neurodivergent folks, and some advice for devs looking for the best tools and tactics for managing ADHD at work.
Marco Palladino, CTO and cofounder of cloud-native API gateway Kong, talks with Ryan about the complexities of multi-cloud Kubernetes architecture, how AI has the potential to improve infrastructure management, and how Kong’s large action model will reshape the future of API platforms.
Ben and Ryan are joined by software developer and listener Patrick Carlile for a conversation about how the job market for software engineers has changed since the dot-com days, navigating boom-and-bust hiring cycles, and the developers finding work at Walmart and In-N-Out. Plus: “Party in the front, business in the back” isn’t just for haircuts anymore.
All about the research that the User Experience team will be focused on over the next quarter and how you can help.
In the latest Stack Overflow for Teams Enterprise release, you'll see updates that make collaboration smarter and knowledge discovery easier. This release also includes OverflowAI, a GenAI-powered paid add-on to Enterprise subscriptions.
On this episode: The FTC bans most noncompete agreements, the implications of the TikTok “ban,” why a 2017 law is hitting startups with huge tax bills seven years later, and the return of net neutrality. Plus: the wunderkind hacker who ransomed Finland’s anxieties and secrets.
Dr. Richard Hipp, creator of SQLite, shares how he taught himself to program, the challenges he faced in creating SQLite, and the importance of testing and maintaining the software for long-term support.
The home team talks about the current state of the software job market, the changing sentiments around AI job opportunities, the impact of big players like Facebook and OpenAI on the space, and the challenges for startups. Plus: The philosophical implications of LLMs and the friendship potential of corvids.
Ben and Ryan explore why configuration is so complicated, the right to repair, the best programming languages for beginners, how AI is grading exams in Texas, Automattic’s $125M acquisition of Beeper, and why a major US city’s train system still relies on floppy disks. Plus: The unique challenge of keeping up with a field that’s changing as rapidly as GenAI.
Ben talks with Shane McAllister, lead developer advocate at MongoDB, Stanimira Vlaeva, senior developer advocate at MongoDB, and Miku Jha, director, AI/ML and generative AI at Google Cloud, about the challenges and opportunities of operationalizing and scaling generative AI models in enterprise organizations.
On this episode: Stack Overflow senior data scientist Michael Geden tells Ryan and Ben about how data scientists evaluate large language models (LLMs) and their output. They cover the challenges involved in evaluating LLMs, how LLMs are being used to evaluate other LLMs, the importance of data validating, the need for human raters, and more needs and tradeoffs involved in selecting and fine-tuning LLMs.
In the wake of the XZ backdoor, Ben and Ryan unpack the security implications of relying on open-source software projects maintained by small teams. They also discuss the open-source nature of Linux, the high cost of education in the US, the value of open-source contributions for job seekers, and what Apple is up to AI-wise.
In this sponsored episode, Ben and Ryan are joined by Ria Cheruvu, an AI evangelist at Intel, to discuss the different approaches to incorporating AI models into organizations.
The home team convenes to discuss the XZ backdoor attack, what great software engineers have in common, how GenAI is changing the face of drug development, and the rise of managed service providers for AI.
We sit down with Jessica Clark, a senior data scientist at Stack Overflow, to discuss how our company approaches generative AI and data quality.
This new LLM technique has started improving the results of models without additional training.
The home team is joined by Michael Foree, Stack Overflow’s director of data science and data platform, and occasional cohost Cassidy Williams, CTO at Contenda, for a conversation about long context windows, retrieval-augmented generation, and how Databricks’ new open LLM could change the game for developers. Plus: How will FTX co-founder Sam Bankman-Fried’s sentence of 25 years in prison reverberate in the blockchain and crypto spaces?
Ben and Ryan talk about how tiny nations are making huge money from their domain names, the US government’s antitrust case against Apple, the implications of a four-day work week, Reddit’s IPO, and more.
In this episode, Ben and Ryan are joined by Joshua Fox, a senior cloud architect at DoiT, to discuss cloud cost optimization. They explore the importance of controlling and understanding cloud costs, the role of good architecture in cost optimization, and strategies for dealing with surprise costs.
This past year, we’ve explored and learned how AI can support the community on Stack Overflow and across the Stack Exchange network. Read more to see our reflections and learn more about the initiatives our product team is prioritizing this year.
Ben and Ryan are joined by Nick Heudecker, Senior Director of Market Strategy and Competitive Intelligence at Cribl, to discuss the state of data and analytics. They cover GenAI, the role of incumbents vs. startups, challenges of data storage and security, data quality and ETL pipelines, measures of data quality for GenAI, and Cribl’s role in the data and observability space.
Ben and Ryan are joined by Bill Harding, CEO of GitClear, for a discussion of AI-generated code quality and its impact on productivity. GitClear’s research has highlighted the fact that while AI can suggest valid code, it can’t necessarily reuse and modify existing code—a recipe for long-term challenges in maintainability and test coverage if devs are too dependent on AI code-gen tools.
Ryan Dahl, creator of Node.js and Deno, tells us about his journey into software development and the creation of Node.js. He explains why he started Deno, a new JavaScript runtime. Ryan also introduces JSR, an alternative to NPM, and emphasizes the importance of security in the JavaScript ecosystem. Plus: Thoughts on the future of JavaScript, including the role of TypeScript and bridging the gap between server-side and browser JavaScript.
Users have been sharing the spark that started them on their journey as computer programmers. From IRC to Minecraft, users found a passion that became a career.
The home team discusses the challenges (hardware and otherwise) of building AI models at scale, why major players like Meta are open-sourcing their AI projects, what Apple’s recent changes mean for developers in the EU, and Perplexity AI’s new approach to search.
Ben talks with Ryan Polk, Chief Product Officer at Stack Overflow, about our strategic partnership with Google Cloud, the importance of collaboration between AI companies and the Stack Overflow community, and why Stack Overflow’s Q&A format is so suitable for training AI models.
Machine learning scientist, author, and LLM developer Maxime Labonne talks with Ben and Ryan about his role as lead machine learning scientist, his contributions to the open-source community, the value of retrieval-augmented generation (RAG), and the process of fine-tuning and unfreezing layers in LLMs. The team talks through various challenges and considerations in implementing GenAI, from data quality to integration.
In the latest Stack Overflow for Teams Enterprise release, you'll see updates that make collaboration more intuitive and meaningful at several different touch points in the user journey, including a reimagined homepage.
Ryan and Ben chat with Shivang Shah, Chief Architect, and Jon Fasoli, Chief Design & Product Officer, both of Intuit Mailchimp, about implementing GenAI and how all the pieces came together to make a better end user experience.
This is part two of our conversation with Roie Schwaber-Cohen, Staff Developer Advocate at Pinecone, about retrieval-augmented generation (RAG) and why it’s crucial for the success of your AI initiatives.
On this episode: Roie Schwaber-Cohen, Staff Developer Advocate at Pinecone, joins Ben and Ryan to break down what retrieval-augmented generation (RAG) is and why the concept is central to the AI conversation. This is part one of our conversation, so tune in next time for the thrilling conclusion.
Stack Overflow is on a journey to build a new era in the practice of AI: the era of social responsibility. All products based on models that consume public Stack Overflow data are required to provide attribution back to the highest relevance posts that influenced the summary given by the model.
Ryan and Ben chat with Raymond Lo, AI software evangelist at Intel, about the AI PC, the software that powers AI breakthroughs, and optimizing hardware and software in unison to improve generative AI performance.
On this episode: Matt Van Itallie, Founder and CEO at Sema, a company that assesses code to improve outcomes for users, companies, and developers. Plus, friend of the show and erstwhile cohost Cassidy Williams joins the conversation.
If you’re building experimental GenAI features that haven’t proven their product market fit, you don’t want to commit to a model that runs up costs without a return on that investment.
On this home team episode: Discussions on Stack Overflow is a new feature that allows users to engage in open-ended conversations outside the site’s primary Q&A structure. The team explores deep-cut Stack Exchange questions about the nature of consciousness and the availability of corrective lenses for medieval knights. Plus: The psychology of downvoting and a recent FCC ruling on AI-generated robocalls.
We chat with Andrew Boyagi, Atlassian's Senior Developer Evangelist, about bringing great developer experience to teams and platforms with thousands of engineers. When the software sprawl gets so big you spend more time looking for answers than solving problems, it might be time to try something new.
On this episode: Eitan Worcel, CEO and cofounder of Mobb, a company that uses AI to automate security vulnerability remediation, talks about how AI can help reduce security backlogs and free up developers’ time, what security risks emerge with GenAI, and why we still need a human in the loop.
On this sponsored episode of the podcast, Ben and Ryan chat with Maya Sellon, inclusive design and digital accessibility principal at Shell, about how she’s scaling accessibility and inclusive design practice across an organization the size of Shell. They talk about how knowing the accessibility issues is half the battle, how people are the key to scale, and what video games teach us about inclusive design.
The home team chats with William Falcon, an AI researcher and creator of PyTorch Lightning, about developing tooling for the AI ecosystem, open-source contributions, what happens when widely hyped technology needs to scale, and why he’s bullish on experienced developers using AI but not so bullish on new devs doing the same.
On this home team episode: Massachusetts makes a welcome shift toward skills-based hiring, AI-generated content robs us of our appetite for mac and cheese, and large-scale crypto mining operations account for more than 2% of the US’s electricity generation. Plus: A PDF quite a bit bigger than Germany.
How does our emphasis on imposter syndrome keep us from having bigger, harder conversations about how to improve life for developers?
Ben talks with startup founder and advisor Elizabeth Zalman about what makes the founder-investor relationship unique in the world of capital, what changes with technical founders, and what VCs are really looking for.
A series of amazing breakthroughs are allowing paralyzed people to speak and emote. With each passing month, we get closer to a brain-computer interface that might unlock some of the deepest mysteries of our grey matter.
We needed to remove the dependency on the Sites database and contain all Teams infrastructure and data within the TFZ which is all part of Phase II.
Ben and friend of the show Kyle Mitofsky sit down with Reid Robinson, lead product manager for AI at Zapier, for a conversation about AI and automation. Plus: NFTs and the dog behind the doge.
We're updating things to highlight community contributions, make it easier to keep tabs on our latest releases, and connect your Stack Overflow account to the discussion happening on the blog.
Stack Overflow’s Employee Resource Groups (ERGs) are a cornerstone of our efforts to create a diverse, inclusive, and equitable workplace.
The post What it’s like being a professional workplace bestie (Ep. 603) appeared first on Stack Overflow Blog.
Predictable event architecture, vector DBs, and alt text
The post The Overflow #192: Ask your data better questions appeared first on Stack Overflow Blog.
Louis Brandy, VP of Engineering at Rockset, joins us for a deep dive into the architectural similarities across AI, vector search, and real-time analytics, and how they’re all at play in shaping the infrastructure to fight spam.
The post Fighting comment spam at Facebook scale (Ep. 602) appeared first on Stack Overflow Blog.
If you want the tech debt metaphor to really shine, get some numbers behind it.
The post If you want to address tech debt, quantify it first appeared first on Stack Overflow Blog.
A Qualcomm expert breaks down some of the tools and techniques they use to fit GenAI models on a smartphone.
The post Fitting AI models in your pocket with quantization appeared first on Stack Overflow Blog.
On today’s episode we chat with CEO Dipanwita Das and CTO Hellmut Adolphs of Sorcero, which uses AI and large language models to make medical texts more discoverable and readable, helping knowledge to more easily spread, increasing the changes doctors and patients will find the solutions they need.
The post Medical research made understandable with AI (ep. 601) appeared first on Stack Overflow Blog.
Understanding SRE, LLM courtesy, and AI drift.
The post The Overflow #191: Between product and engineering appeared first on Stack Overflow Blog.
Ben and senior software engineer Kyle Mitofsky are joined by two people who worked on the launch of Overflow AI: director of data science and data platform Michael Foree and senior software developer Alex Warren. They talk about how and why Stack Overflow launched semantic search, how to ensure a knowledge base is trustworthy, and why user prompts can make LLMs vulnerable to exploits.
The post Semantic search without the napalm grandma exploit (Ep. 600) appeared first on Stack Overflow Blog.
SPONSORED BY DISCOVER FINANCIAL On this sponsored episode of the podcast, Ben and Ryan chat with Paul Manning and Emanuele Pugliese of Discover Financial about the tech that goes into payments and the way they approach developer experience and architecture. They talk about domain-driven design, event-driven architecture, Kafka Streams, and how they leverage all that…
The post Making event-driven development predictable with Discover appeared first on Stack Overflow Blog.
Tim Tutt, CEO and cofounder of Night Shift Development, tells the home team about his work in deploying large-scale search and discovery analytics, why he’s working to help nontechnical users understand and utilize their business data, and how GenAI is teaching people to ask better questions.
The post Want better answers from your data? Ask better questions appeared first on Stack Overflow Blog.
Building AI at SO, lambdas in C++, and language translation
The post The Overflow #190: Long live the new search! appeared first on Stack Overflow Blog.
Laura Bell Main, founder and CEO of SafeStack, on why everyone should be an AppSec specialist and what she’s doing to make that happen.
The post Why everyone should be an AppSec specialist (Ep. 598) appeared first on Stack Overflow Blog.
Measure whether your organization is successfully breaking down knowledge silos.
The post Visualize knowledge flows with Connectivity appeared first on Stack Overflow Blog.
We're setting the record straight.
The post Insights into Stack Overflow’s traffic appeared first on Stack Overflow Blog.
Vladyslav Ukis, Head of R&D at Siemens Healthineers and an expert in site reliability engineering (SRE), joins Ben and Ryan to talk about the relationship between SRE and DevOps, balancing SRE principles with organizational structure, and how he thinks GenAI will impact his field.
The post Understanding SRE (Ep. 597) appeared first on Stack Overflow Blog.
If edge functions were an onion, most of the layers would be caching.
The post Speeding up the I/O-heavy app: Q&A with Malte Ubl of Vercel appeared first on Stack Overflow Blog.
Life on the Python Steering Council, early meetings, and boring architecture
The post The Overflow #189: OverflowAI! appeared first on Stack Overflow Blog.
Kathryn Murphy, SVP of Product and Design at Twilio, chats with Stack Overflow CTO Jody Bailey about walking the line between product design and engineering early in their careers, lessons learned at tech juggernauts like Salesforce and Amazon, and their respective roadmaps for integrating generative AI into their products.
The post The fine line between product and engineering (Ep. 596) appeared first on Stack Overflow Blog.
On this sponsored episode of the podcast, Ben talks with Amber Webb, Principal Engineer at Shell, and Naresh Kumar, Senior Principal Engineer at Shell, about their hyper automation initiative, which locates organization-level bottlenecks and removes them.
The post How engineering teams at a large org can move at startup speed appeared first on Stack Overflow Blog.
Ben and Cassidy talk with programmer and developer advocate Sean Falconer, Head of Developer Relations and Marketing at Skyflow, ex-Googler, and host of the podcasts Partially Redacted and Software Engineering Daily.
The post From startup to Google and back again (Ep. 595) appeared first on Stack Overflow Blog.
Semantic search allows users to search using natural language instead of a rigid syntax of keyword manipulation.
The post Ask like a human: Implementing semantic search on Stack Overflow appeared first on Stack Overflow Blog.
Time to first byte, Lisp and AI, and mocking in unit tests.
The post The Overflow #188: Recognition for individual contributors appeared first on Stack Overflow Blog.
To evolve our company, we had to change the way we work.
The post Behind the scenes with the folks building OverflowAI (Ep. 594) appeared first on Stack Overflow Blog.
Let’s highlight the new features and products we announced today from the stage of WeAreDevelopers.
The post Announcing OverflowAI appeared first on Stack Overflow Blog.
DevOps has helped lots of organizations improve their processes, but others have only seen frustration and burnout.
The post Platform engineering is just DevOps with a product mindset appeared first on Stack Overflow Blog.
In part two of their conversation, Ben and Kyle chat with Python core developer and Steering Council member Pablo Galindo Salgado about balancing consistency and new features in language design, the importance of gathering community feedback on new iterations, and why he’s focused on making Python faster.
The post How the Python team is adapting the language for an AI future (Ep. 593) appeared first on Stack Overflow Blog.
Ben and senior software engineer Kyle Mitofsky talk with Pablo Galindo Salgado, a Python core developer and Python Steering Council member, about how he infiltrated software development from the world of physics, the journey from fixing typos to updating core, and the time he broke GitHub (an important developer milestone!).
The post What it’s like to be on the Python Steering Council (Ep. 592) appeared first on Stack Overflow Blog.
Faster websites through piggybacking on existing network architecture.
The post Improving time to first byte: Q&A with Dana Lawson of Netlify appeared first on Stack Overflow Blog.
We sit down with Sascha Heyer, Senior ML specialist at DoIT, to learn how organizations can leverage the power of GenAI while avoiding the downsides.
The post How AI can help your business, without the hallucinations appeared first on Stack Overflow Blog.
Dr. Cat Hicks, Director of Pluralsight Flow’s Developer Success Lab, joins Ben and Eira to talk about why ICs deserve recognition for their contributions to big projects (and how they can get it).
The post How ICs can get recognition for their work on big projects (Ep. 590) appeared first on Stack Overflow Blog.
Knowledge management and AI, VPN security, and an SVG deep dive.
The post The Overflow #186: Do large language models know what they’re talking about? appeared first on Stack Overflow Blog.
Connell, a UK-based .NET developer and senior software engineer at Stack Overflow, tells the home team about his path to software development via text-based RPGs, his work on Stack Overflow’s Community Enablement team, why Agile gets so much hate, and what he’s learned giving conference talks to developers.
The post How terrifying is giving a conference talk? (Ep. 589) appeared first on Stack Overflow Blog.
Dana Lawson, Senior VP of Engineering at Netlify, joins Ben and Ryan to talk about her path from the military to tech, how three years at GitHub continues to shape her perspective, and how composable architecture is turning web development into something resembling LEGOsⓇ (in a good way).
The post Jamstack is evolving toward a composable web (Ep. 588) appeared first on Stack Overflow Blog.
Syndicating code globally to be deployed locally allows just-in-time modifications to customize web apps.
The post Exploring the infrastructure and code behind modern edge functions appeared first on Stack Overflow Blog.
DevX in energy sectors, fox talk, and Elixir loops and lists.
The post The Overflow #185: The hardest part of software is requirements appeared first on Stack Overflow Blog.
VerseProp founder and CEO Joel Coren and founding partner and COO William Polisano join Ben to talk about digital real estate’s gaming roots, where the value of virtual properties comes from, and why they think digital real estate is on the cusp of a supercycle.
The post From Sims to supercycle? (Ep. 587) appeared first on Stack Overflow Blog.
Providing the right context to AI can improve accuracy and reduce hallucinations.
The post Why knowledge management is foundational to AI success appeared first on Stack Overflow Blog.
The home team shares what our Developer Survey respondents said about AI, spicy opinions about recent Apple unveilings, and an update on crypto regulation.
The post Developers use AI tools, they just don’t trust them (Ep. 586) appeared first on Stack Overflow Blog.
Large language models seem to possess the ability to reason intelligently, but does that mean they actually know things?
The post Do large language models know what they are talking about? appeared first on Stack Overflow Blog.
Vertical farming, pure math for dummies, and git for solo devs.
The post The Overflow #184: Stress test your code appeared first on Stack Overflow Blog.
On this episode of the podcast, Ben and Ryan chat with Martial Hebert, dean of the School of Computer Science at Ryan’s alma mater, Carnegie Mellon University.
The post Making computer science more humane at Carnegie Mellon (ep. 585) appeared first on Stack Overflow Blog.
Thousands of the company’s engineers, data scientists, designers, and developers have asked and answered questions about how things work inside their organization.
The post How Bloomberg’s engineers built a culture of knowledge sharing appeared first on Stack Overflow Blog.
And how software underlies the second-largest electric vehicle charging network.
The post Improving the developer experience in the energy sector appeared first on Stack Overflow Blog.
Chef cofounder Adam Jacob joins the home team to discuss the problems with the current state of cloud infrastructure, what engineers need but aren’t getting, and why he’s focused on creating a new and improved approach to infrastructure automation.
The post The cofounder of Chef is cooking up a less painful DevOps (Ep. 584) appeared first on Stack Overflow Blog.
Why replacing programmers with AI won’t be so easy.
The post The hardest part of building software is not coding, it’s requirements appeared first on Stack Overflow Blog.
The birth of Agile, taking notes in an interview, and CSS nesting
The post The Overflow #183: Dev Survey on AI: Hype or not? appeared first on Stack Overflow Blog.
Syed Hamid, founder and CEO of no-code test automation platform Sofy, joins Ben and Ryan to talk about scriptless automation, why his platform targets mobile app developers, and what he learned in nearly two decades at Microsoft.
The post Throwing away the script on testing (Ep. 583) appeared first on Stack Overflow Blog.
What's the tech stack for kale?
The post Part man. Part machine. All farmer. appeared first on Stack Overflow Blog.
It’s easy to ask for, and even want, feedback in a sort of theoretical sense. But soliciting and responding to feedback are, themselves skills.
The post To improve as an engineer, get better at requesting (and receiving) feedback appeared first on Stack Overflow Blog.
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.
The post Stress test your code as you write it (Ep. 581) appeared first on Stack Overflow Blog.
Coding with ADHD, false proofs, and tech debt.
The post The Overflow #182: Self-healing code appeared first on Stack Overflow Blog.
We sit down the PM behind Google Duet to discuss how it was made and how it aims to help, but not replace, developers.
The post Pair programing? We peek under the hood of Duet, Google’s coding assistant. (Ep. 580) appeared first on Stack Overflow Blog.
For this year’s developer survey, we added new questions to gain insight into the real sentiments behind this year’s surge in AI popularity. Is AI making a real impact in the way developers work or is it all hype? This article will recap some of the top insights, but check out Stack Overflow Labs for…
The post Hype or not? AI’s benefits for developers explored in the 2023 Developer Survey appeared first on Stack Overflow Blog.
The tech that's hot or not, and how work is changing.
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.”
The post The meeting that changed how we build software (Ep. 579) appeared first on Stack Overflow Blog.
Our new Code of Conduct, lie or fired, and email is not forever.
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.
The post Chatting with Apple at WWDC: Macros in Swift and the new visionOS appeared first on Stack Overflow 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.
The post How to keep your new tool from gathering dust appeared first on Stack Overflow Blog.
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.
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.
Note: For this article, we spoke with two Stack Overflow software engineers who have been diagnosed with ADHD but who wish to remain anonymous.
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. (Quick note: 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 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. Here’s what developers with ADHD want you to understand.
It’s less superpower, more invisible disabilityIt 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 become managers are no longer responsible for their individual productivity; 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 accommodationsWhat 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 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 changingBoth 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 strengthAs 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.
Dehydrating the web, DDOSing a brain, and A/B testing mistakes
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.
Throughout Stack Overflow’s 15-year journey, we have always prioritized the well-being and safety of the community. This is actually one of the things that most attracted me to this community: for years when I worked in other places, I watched to see how Stack Overflow and Stack Exchange worked to protect users. I’ve learned that as culture shifts and new threat types emerge, our guidelines must mature and flex to meet new challenges. On May 31st, we rolled out an updated Code of Conduct to help reflect our commitment to the safety of everyone who visits our sites.
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 improvementWe 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 ConductOur 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 safetyThe 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 effortA 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.
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.
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 Joonku, which aims to build a more equitable workplace by automating the recruitment of diverse talent from underrepresented communities.
Episode notes:
Joonku 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.
In April, we shared how Stack Overflow is approaching the future of AI/ML and our products. But you might not realize that we’ve already used AI/ML to build or improve Stack Overflow’s products and features.
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 ideaRecommending 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 approachPost-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-contentOur 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 contentThe 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.
The post More on our AI future: building course recommendations and a new data platform appeared first on Stack Overflow Blog.
Welcome to ISSUE #179 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: chatting about OWASP ZAP, computing with rolling stones, and jQuery lives.
From the blogKeep ‘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 questionsApollo: 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 webHow 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.
Between the Great Resignation and the recent spate of layoffs, you may be thinking about your resume a bit more than usual in the last few months. Even if it’s been spruced up and you’re following the best advice out there, you might get more out of your resume by treating it as a marketing document instead of just an information dump.
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 marketerI 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 fundamentalsYour 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 storiesOk, 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.
ConclusionIn 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.
In tough economic times, everyone looks for ways to lower costs without impacting productivity (heck, if we’re doing wish lists, let’s improve productivity, too). And this is one of those times, with many companies making the hard decision to lay off workers and worrying about the impact of new AI technologies.
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 heavenLet’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 workspaceWe 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.
Welcome to ISSUE #178 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: getting your tech team to make big changes, dark e-commerce patterns, and the page that fetches itself.
From the blogStories 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 questionsWhy 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 webChromium 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.
From a user’s perspective, a software application, whether it’s mobile, desktop, or web based, is something that you interact with and it does stuff. But from a developer’s perspective, there’s a lot of separate actions that occur: the user interacts with a UI, the program takes that input and performs some tasks on the data, and the data feeds back into the user interface. That’s the technical version of doing stuff.
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 patternModels 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 webIn 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.
InterfacesEach 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 pitfallsThe 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 viewsThe 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 controllersControllers 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 modelsModels 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.
ConclusionThe 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.
Salary growth in the tech world surged during the pandemic. From the three surveys conducted from 2020-2022, we collected developer responses on their roles and salaries at the time. 2020’s survey was conducted right before the pandemic took hold worldwide and 2022’s survey was conducted as the world was settling into remote, hybrid, or return to office (RTO) initiatives. There was a lot of change during those three years, including big pay bumps in Brazil and India, two of our top 10 respondent countries. In those countries, data scientists, back-end developers, and embedded application/device developers all successfully negotiated higher wages.
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.
Welcome to ISSUE #177 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: how to handle any failure in production, why hackers are trying to trick your webserver into doing math, and what makes perpetual motion potentially possible at a quantum level.
From the blogThe 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 questionsIs 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 webThe 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.
cracks knuckles
and thus, we begin the "PaLM v2" drinking game (but with coffee, tea, or your favorite caffeinated beverage of choice, as it's early! )#GoogleIO2023 #GoogleIO https://t.co/HbhcmhF6XK
— Paige Bailey (@DynamicWebPaige) May 10, 2023
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.
I’m writing today to share that I’ve made the very difficult decision to reduce our workforce by about 10%, or 58 employees.
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.
The bigger the change we’re making to a code base, the more obstacles we have to overcome. No time before the deadline. Business won’t cooperate. Intractable technical constraints.
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 kingWe 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 mattersIn 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 changeWhat 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.
It’s that time of year again where we come to the community to say, “It’s that time of year again,” again! (That recursive joke was for the 1.31% of you who use LISP.) Our 2023 Developer Survey is officially live and we are excited to hear from everyone in the developer community again, as we have for the past 12 years.
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.
Welcome to ISSUE #176 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: a terrible coder gets an AI assist, when your advisor starts declining mentally, and five topics to keep in mind when job hunting.
From the blogInstantly 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 questionsTwo 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 webContainer 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.
Last week, we outlined some reasons why a role in climate tech is a smart move for engineers seeking more meaning and purpose at work.
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 youUnlike 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 boardsClimate 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 financingYou 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 communityEspecially 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 pictureThe 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.
No matter how strong your organization is, how detailed their planning, how deliberate their deployments…things will break and emergencies will send your teams scrambling. Systems will go down, key functionality will stop working, and at some point in everyone’s career as a developer, an issue will call for all hands on deck.
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 problemThis 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 learningsIf 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 Timesabout 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.
Large language models (LLMs) feel like magic. For the first time ever, we can converse with a computer program in natural language and get a coherent, personalized response. Likewise with generative art models such as Stable Diffusion, which can create believable art from the simplest of prompts. Computers are starting to behave less like tools and more like peers.
The excitement around these advancements has been intense. We should give the skeptics their due, though: human beings are easily swept up in science fiction. We’ve believed that flying cars, teleportation, and robot butlers were on the horizon for decades now, and we’re hardly discouraged by the laws of physics. It’s no surprise that people are framing generative AI as the beginning of a glorious sci-fi future, making human labor obsolete and taking us into the Star Trek era.
In some ways, the fervor around AI is reminiscent of blockchain hype, which has steadily cooled since its 2021 peak. In almost all cases, blockchain technology serves no purpose but to make software slower, more difficult to fix, and a bigger target for scammers. AI isn’t nearly as frivolous—it has several novel use cases—but many are rightly wary of the resemblance. And there are concerns to be had; AI bears the deceptive appearance of a free lunch and, predictably, has non-obvious downsides that some founders and VCs will insist on learning the hard way.
Putting aside science fiction and speculation about the next generation of LLMs, 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—a mechanism for delivering our intentions to traditional, algorithmic APIs.
AI is a pattern printerAI in its current state is very, very good at one thing: modeling and imitating a stochastic system. Stochastic refers to something that’s random in a way we can describe but not predict. Human language is moderately stochastic. When we speak or write, we’re not truly choosing words at random—there is a method to it, and sometimes we can finish each other’s sentences. But on the whole, it’s not possible to accurately predict what someone will say next.
So even though an LLM uses similar technology to the “suggestion strip” above your smartphone keyboard and is often described as a predictive engine, that’s not the most useful terminology. It captures more of its essence to say it’s an imitation engine. Having scanned billions of pages of text written by humans, it knows what things a human being is likely to say in response to something. Even if it’s never seen an exact combination of words before, it knows some words are more or less likely to appear near each other, and certain words in a sentence are easily substituted with others. It’s a massive statistical model of linguistic habits.
This understanding of generative AI explains why it struggles to solve basic math problems, tries to add horseradish to brownies, and is easily baited into arguments about the current date. There’s no thought or understanding under the hood, just our own babbling mirrored back to us—the famous Chinese Room Argument is correct here.
If LLMs were better at citing their sources, we could trace each of their little faux pas back to a thousand hauntingly similar lines in online math courses, recipe blogs, or shouting matches on Reddit. They’re pattern printers. And yet, somehow, their model of language is good enough to give us what we want most of the time. As a replacement for human beings, they fall short. But as a replacement for, say, a command-line interface? They’re a massive improvement. Humans don’t naturally communicate by typing commands from a predetermined list. The thing nearest our desires and intentions is speech, and AI has learned the structure of speech.
Art, too, is moderately stochastic. Some art is truly random, but most of it follows a recognizable grammar of lines and colors. If something can be reduced to patterns, however elaborate they may be, AI can probably mimic it. That’s what AI does. That’s the whole story.
This means AI, though not quite the cure-all it’s been marketed as, is far from useless. It would be inconceivably difficult to imitate a system as complex as language or art using standard algorithmic programming. The resulting application would likely be slower, too, and even less coherent in unfamiliar situations. In the races AI can win, there is no second place.
Learning to identify these races is becoming an essential technical skill, and it’s harder than it looks. An off-the-shelf AI model can do a wide range of tasks more quickly than a human can. But if it’s used to solve the wrong problems, its solutions will quickly prove fragile and even dangerous.
AI can’t follow rulesThe entirety of human achievement in computer science has been thanks to two technological marvels: predictability and scale. Computers do not surprise us. (Sometimes we surprise ourselves when we program them, but that’s our own fault.) They do the same thing over and over again, billions of times a second, without ever changing their minds. And anything predictable and repeatable, even something as small as current running through a transistor, can be stacked up and built into a complex system.
The one major constraint of computers is that they’re operated by people. We’re not predictable and we certainly don’t scale. It takes substantial effort to transform our intentions into something safe, constrained, and predictable.
AI has an entirely different set of problems that are often trickier to solve. It scales, but it isn’t predictable. The ability to imitate an unpredictable system is its whole value proposition, remember?
If you need a traditional computer program to follow a rule, such as a privacy or security regulation, you can write code with strict guarantees and then prove (sometimes even with formal logic) that the rule won’t be violated. Though human programmers are imperfect, they can conceive of perfect adherence to a rule and use various tools to implement it with a high success rate.
AI offers no such option. Constraints can only be applied to it in one of two ways: with another layer of AI (which amounts to little more than a suggestion) or by running the output through algorithmic code, which by nature is insufficient to the variety of outputs the AI can produce. Either way, the AI’s stochastic model guarantees a non-zero probability of breaking the rule. AI is a mirror; the only thing it can’t do is something it’s never seen.
Most of our time as programmers is spent on human problems. We work under the assumption that computers don’t make mistakes. This expectation isn’t theoretically sound—a cosmic ray can technically cause a malfunction with no human source—but on the scale of a single team working on a single app, it’s effectively always correct. We fix bugs by finding the mistakes we made along the way. Programming is an exercise in self-correction.
So what do we do when an AI has a bug?
That’s a tough question. “Bug” probably isn’t the right term for a misbehavior, like trying to break up a customer’s marriage or blackmail them. A bug is an inaccuracy written in code. An AI misbehavior, more often than not, is a perfectly accurate reflection of its training set. As much as we want to blame the AI or the company that made it, the fault is in the data—in the case of LLMs, data produced by billions of human beings and shared publicly on the internet. It does the things we do. It’s easily taken in by misinformation because so are we; loves to get into arguments because so do we; and makes outrageous threats because so do we. It’s been tuned and re-tuned to emulate our best behavior, but its data set is enormous and there are more than a few skeletons in the closet. And every attempt to force it into a small, socially-acceptable box seems to strive against its innate usefulness. We’re unable to decide if we want it to behave like a human or not.
In any case, fixing “bugs” in AI is uncertain business. You can tweak the parameters of the statistical model, add or remove training data, or label certain outputs as “good” or “bad” and run them back through the model. But you can never say “here’s the problem and here’s the fix” with any certainty. There’s no proof in the pudding. All you can do is test the model and hope it behaves the same way in front of customers.
The unconstrainability of AI is a fundamental principle for judging the boundary between good and bad use cases. When we consider applying an AI model of any kind to a problem, we should ask: are there any non-negotiable rules or regulations that must be followed? Is it unacceptable for the model to occasionally do the opposite of what we expect? Is the model operating at a layer where it would be hard for a human to check its output? If the answer to any of these is “yes,” AI is a high risk.
The sweet spot for AI is a context where its choices are limited, transparent, and safe. We should be giving it an API, not an output box. At first glance, this isn’t as exciting as the “robot virtual assistant” or “zero-cost customer service agent” applications many have imagined. But it’s powerful in another way—one that could revolutionize the most fundamental interactions between humans and computers.
A time and place for AIEven if it always behaved itself, AI wouldn’t be a good fit for everything. Most of the things we want computers to do can be represented as a collection of rules. For example, I don’t want any probability modeling or stochastic noise between my keyboard and my word processor. I want to be certain that typing a “K” will always produce a “K” on the screen. And if it doesn’t, I want to know someone can write a software update that will fix it deterministically, not just probably.
Actually, it’s hard to imagine a case where we want our software to behave unpredictably. We’re at ease having computers in our pockets and under the hoods of our cars because we believe (sometimes falsely) that they only do what we tell them to. We have very narrow expectations of what will happen when we tap and scroll. Even when interacting with an AI model, we like to be fooled into thinking its output is predictable; AI is at its best when it has the appearance of an algorithm. Good speech-to-text models have this trait, along with language translation programs and on-screen swipe keyboards. In each of these cases we want to be understood, not surprised. AI, therefore, makes the most sense as a translation layer between humans, who are incurably chaotic, and traditional software, which is deterministic.
Brand and legal consequences have followed and will continue to follow for companies who are too hasty in shipping AI products to customers. Bad actors, internet-enabled PR catastrophes, and stringent regulations are unavoidable parts of the corporate landscape, and AI is poorly equipped to handle any of these. It’s a wild card many companies will learn they can’t afford to work with.
We shouldn’t be surprised by this. All technologies have tradeoffs.
The typical response to criticisms of AI is “but what about a few years from now?” There’s a widespread assumption that AI’s current flaws, like software bugs, are mere programming slip-ups that can be solved by a software update. But its biggest limitations are intrinsic. AI’s strength is also its weakness. Its constraints are few and its capabilities are many—for better and for worse.
The startups that come out on top of the AI hype wave will be those that understand generative AI’s place in the world: not just catnip for venture capitalists and early adopters, not a cheap full-service replacement for human writers and artists, and certainly not a shortcut to mission-critical code, but something even more interesting: an adaptive interface between chaotic real-world problems and secure, well-architected technical solutions. AI may not truly understand us, but it can deliver our intentions to an API with reasonable accuracy and describe the results in a way we understand.
It’s a new kind of UI.
There are pros and cons to this UI, as with any other. Some applications will always be better off with buttons and forms, for which daily users can develop muscle memory and interact at high speeds. But for early-stage startups, occasional-use apps, and highly complex business tools, AI can enable us to ship sooner, iterate faster, and handle more varied customer needs.
We can’t ever fully trust AI—a lesson we’ll learn again and again in the years ahead—but we can certainly put it to good use. More and more often, we’ll find it playing middleman between the rigidity of a computer system and the anarchy of an organic one. If that means we can welcome computers further into our lives without giving up the things that make us human, so much the better.
The post AI isn’t the app, it’s the UI appeared first on Stack Overflow Blog.
Welcome to ISSUE #175 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: Stack Overflow embraces the power of AI, why Delaware is the hottest state for corporate lawsuits, and online playgrounds let you write code without downloading anything.
From the blogIntroducing Communities on Teams: where domain, practice, and community come together with purpose stackoverflow.blog
Communities on Teams is a new way to bring people and knowledge together within a specific topic or focus to share valuable resources and collaborate in meaningful ways.
Community is the future of AI stackoverflow.blog
To keep knowledge open and accessible to all, we must come together to build the future of AI.
We bought a university: how one coding school doubled down on brick and mortar (Ep. 561) stackoverflow.blog
Paulo and Guilherme Silveira, brothers and cofounders of edtech platform Alura, join the home team for a conversation about polyglot programming, edtech, and the role of generative AI.
Ops teams are pets, not cattle (Ep. 562) stackoverflow.blog
Ops folks with knowledge are irreplaceable. Treat them like you need them.
Build an app capable of monitoring rocket launch data promotion
Even if you’re not launching space rockets, collecting and analyzing real-time data is essential to building smarter apps. Watch on-demand how MongoDB Atlas combines multiple capabilities into a single platform to analyze one million metrics per second.
Interesting questionsI am reviewing a very bad paper—do I have to be nice? academia.stackexchange.com
Professionalism and niceness are not the same thing.
If energy is relative, then how it can remain conserved? physics.stackexchange.com
Conserved and invariant aren’t the same thing.
Why was the Dominion v. Fox case tried in Delaware? law.stackexchange.com
“Fun fact: There are literally more corporations in Delaware than there are people.”
What are famous examples of “serendipity” in 20th century mathematics? mathoverflow.net
Right place, right time…right answer?
Links from around the webTo understand AI sentience, first understand it in animals aeon.co
Does AI have feelings or is it just gaming us?
A visual introduction to machine learning www.r2d3.us
If you want to learn more about machine learning and artificial intelligence, this beautiful visual intro is for you.
Node.js 20 is now available! nodejs.org
Time flies when you’re writing code. Node v20 was just released!
A list of programming playgrounds jvns.ca
This is a very handy list of places for you to code online without having to install anything on your machine.
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #175: The coding school that bought a university appeared first on Stack Overflow Blog.
The home team welcomes a student and a professor from engineering powerhouse Olin College for a discussion of computer science education and how Olin prepares its students to hit the ground running as software engineers.
Episode notes:
Olin College of Engineering has one of the top-ranked undergrad engineering programs in the US. Its computing curriculum is a concentration within the engineering major, not a standalone major. The upshot is a liberal arts-informed course of study with fewer math and theory requirements than a typical CS degree and a greater emphasis on practical, job-ready skills like code quality, testing, and documentation. To learn more about how software design is taught at Olin, explore the course.
Andrew Mascillaro is a senior at Olin majoring in electrical and computer engineering. He’s currently a software engineering intern at Tableau. You can find him on LinkedIn.
Steve Matsumoto is an assistant professor of computer science and engineering at Olin; his academic interests include crypto and cybersecurity. You can find him on GitHub or through his website.
TRANSCRIPT
The post How a top-ranked engineering school reimagined CS curriculum (Ep. 565) appeared first on Stack Overflow Blog.
Thanks to the persistent vortex of doomsday narratives in the media, it’s understandable that many talented engineers are feeling uneasy about life at work (and life on earth more generally).
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.
Remember that for centuries, in times good and bad, philosophers have provided humanity comforting wisdom that even though it’s impossible to control the external world, you can control your own thoughts, intentions, and actions. As a technologist with agency, it’s well-within your control to seek out a job that is personally fulfilling and makes a positive impact in the world.
If you’re stuck in a job that lacks purpose, maybe now’s a good time to start thinking about switching up your career to one with more potential for good. How about climate tech?
So what could a career in climate tech look like?The answer to this question is pretty straightforward. It’s a lot like the job that you already have, even if you do not have a background in sustainability, environmental science, or an adjacent field. Your skills are more transferable than you may realize.
Consider the experience of Kevin Cianfarini, a 27-year-old senior Android developer at Octopus Energy, a renewable-energy supplier.
- He did have to take a pay cut
- He received multiple offers with higher salaries compared to his prior role at a fintech company
- It was a sense of meaning and purpose that inspired him to join Octopus—something that he did not experience at the fintech company where he previously worked
- At Octopus, he earns $185,000 a year plus a $40,000 stock option grant that vests over four years
As another example, Cassandra Xia left her software engineering job at Google where she worked on projects related to click-through rate predictions, according to an article in protocol. A year after leaving her position, she joined Evergrow, a climate fintech startup, as the head of engineering. What energizes her about the position is that climate “is a problem that’s not figured out, and there isn’t really an interactive solution,” in contrast to Google where “the problems have already been picked over.”
Cianfarini and Xia aren’t alone. According to Justin Hardin, co-founder and CTO at the job board Climatebase, more than 500,000 people have used the platform to seek out and apply for a climate tech job.
You won’t know what interesting opportunities are out there unless you look.
A climate tech economy is starting to take shapeIt turns out that the foundations of a climate tech economy are starting to form, thanks to investors who are realizing the importance of committing capital to the problem—despite the overarching trend of a venture funding downturn.
“Climate tech funding in 2022 represented more than a quarter of every venture dollar invested in 2022, even though the market is not yet efficient at meeting climate objectives,” explains PwC.
“This represents aggregate funds raised for climate tech since the start of 2018 of US$260 billion, over which more than US$50 billion has come in 2022,” explains the report.
Specifically, PwC observes increased investment in carbon capture, removal, utilization, and storage.
Catherine Boudreau, a writer at Business Insider, interviewed several VCs who explained that “a new era is underway because of the passage last year of the Inflation Reduction Act, which includes some $370 billion in federal subsidies over a decade aimed at expanding renewable energy and boosting manufacturing in the US.”
“Climate is like the internet in that it’s going to disrupt every corner of the global economy,” explained Andrew Beebe in Bourdreau’s article, the managing director of Obvious Ventures, which has more than $1 billion in assets under management. “It might be like a dirty little secret in Silicon Valley that some of the best targets for venture capital are where governments will regulate the fastest.”
Where there’s growth, there is a likelihood of new opportunities emerging.
Focus on signals—ignore noise
You might also be hearing contradictory perspectives about a downturn in VC climate tech funding.
Remember that stories like these are created by humans (and sometimes AI). One explanation for these varying perspectives is that reporters may be analyzing data over different time horizons. There may also be differences across data sources that analysts are using. We may never know the reason, as financial paper trails are ultimately in the decision-making hands of VCs choosing to fund companies. All we know is what we can see and what we are told. TLDR: Who knows what’s up, really?
No matter what macroeconomic data you’re examining, whether positive or negative, it’s a good idea to look beneath the surface —to discover signals in the midst of noise, overall. Even in areas where funding may be stagnating or slowing down, you can still find data points that are relevant to your job search.
“Funding for climate tech was relatively flat from 2021 to 2022, compared with investment slowdowns in other sectors, but a more granular look at the data suggests that resources have begun to shift away from previously dominant segments like transportation toward emerging technologies, according to Climate Tech VC (CTVC),” explains one article in Tech Brew.
Despite these macro trends, remember that your goal is to simply finda job. So make your own judgment calls.
Final words of empowerment
The economy feels larger than life sometimes. That’s because it is. After all, there are eight billion people in the world—and a large number are transacting with each other in some way on a regular basis. Yes it’s true, according to the United Nations, that “that climate change is a grave and mounting threat to our wellbeing and a healthy planet.”
Despite how massive (and out of control) problems seem sometimes, remember that your mind has the power to shape reality. Brain formation travels at 268 miles per hour, according to researchers, with a storage capacity that’s unlimited. Imagine the power of putting that intellect to work to solve the climate crisis.
After all, the IPCC says that despite the potential for doomsday scenarios, the 1.5°C warming limit is still attainable.
As Yoda would say, “Do or do not do. There is no try.”
Maybe with enough brain power from the tech sector, humanity can achieve this goal.
Next week, we’ll publish a part two in this series, sharing practical, tactical tips to help you find a role that’s right for you.
Climate tech is a new industry, which means that you’ll be responsible for building technical architecture from the ground up. Learn how Stack Overflow for Teams can help support problem-solving at your organization.
The post Looking for job perks? How about saving the world? appeared first on Stack Overflow Blog.
The grand irony of my role here at Stack Overflow is that I work to create great content for developers, but am absolutely hopeless when it comes to programming on my own. Over my four years here, I’ve gained a pretty good understanding of software at the macro level. I can have an intelligent discussion about the value of microservices vs monoliths, strongly typed languages, cloud vs on-prem, or large language models. But asking me to whip up a simple CRUD app is a recipe for disappointment.
[Note to readers: before leaving a comment about someone with no skills wasting your time, refer back to the title and remember that you can’t insult a person who has already completed a perfect self-own.]
Anyway, over the last month, I decided to try diving back in, inspired by a steady stream of posts I saw on social media that showed people writing natural language instructions that today’s AI assistants can transform into working code. Maybe, I thought, my basic understanding of how a web app gets built will allow me to engineer the right prompts, and the AI can handle writing and debugging the actual code.
The app I had in mind is fairly simple: people can list let others know when they are going to be at the local dog park. After some discussion, I found that this is a basic CRUD app:
- Create: a web form where users can input the name of their dog and the time they plan to arrive at the park.
- Read: Other users can see who is planning to visit and what time they’ll be there.
- Update: I’m not even trying to get this fancy! Also, no take-backsies!
- Delete: At the end of each day, the database deletes all entries so the slate is blank for the following morning.
Normally, to get started, I would brush up on my paltry HTML skills and prepare a sacrifice to the JavaScript gods, but, in 2023, I can just ask an AI:
I want to build a single page web app that will allow users to submit their name, their dog's name, and the time they intend to visit the local dog park. After users submit this information, it is displayed for anyone who visits the page. I need front end code and a database on the backend that can store state. First - Please explain how you would create this app using pseudo-code examples. Second - write the code for this app and share it as a single code snippet.First, let me outline the general structure and pseudo-code for the app.Frontend (HTML, CSS, JavaScript)a. Create an HTML form for user input (user's name, dog's name, and intended visit time)b. Style the form using CSSc. Add JavaScript to handle form submission and send data to the backend APIBackend (Node.js with Express and a database like MongoDB)a. Set up a Node.js server with Expressb. Create API endpoints to handle data submission and retrievalc. Connect to a MongoDB database to store and fetch the submitted dataConnect frontend and backenda. Use JavaScript to send data from the frontend to the backend APIb. Display the fetched data on the frontend
Ok, let’s drop the code it generated into my WordPress CMS just to take a peek and…by George, it works. Looks a little janky, though. Let’s clean things up.
Edit the code above so that the three text fields are centered on the page and there are three line breaks between the name and time fields.
And just like that: Sure, here’s the updated code with the changes you requested:
Looks better, but it’s still missing something. I know!
Modify the code above so that an ASCII image of a dog appears over the text fields for name and time. The ASCII image of the dog is centered on the page.
How sweet it is. This is what mean when they say AI is a tool to unlock human creativity and potential, not to replace us.
So far so good, but the input doesn’t persist. I need some kind of backend to record my state.
I want to add a database to the code above so that I can store the state of the output and display all text submitted to users on the client side. I want the database to contain two rows, one for "name" and one for "time". When users submit a "name" and "time" the database stores this state and it's displayed in the output section. The database clears these rows once a day at midnight Eastern time.
A few seconds later the AI spits back a code block that uses jQuery and PHP with a MySQL database. For a hopeless programmer like me, it’s fascinating to see that I’ve now got access to building blocks in multiple languages. I can’t even master one on my own!
That said, the AI can’t solve the issue of ME being an intractable vortex of bugs and errors, attracting obstacles to functioning code like a magnet picks up nails. I go through the process of setting up an AWS account and following the online tutorial for creating a MySQL database, but can’t actually get it to connect to the workbench.
The AI tries to be kind. I ask it to rewrite the code for a NoSQL database and it helpfully switches from PHP to Node.JS without missing a beat. I spin up a MongoDB Atlas cluster, but am lost again in a sea of error messages.
Eventually I try a clean slate. I start a new dialog with the AI and ask it to create a simple app that will work with Firebase. I’ve learned a few things from my first two attempts, so I understand a little better how the pieces are supposed to fit together. It’s easier for me to work in the terminal and to have a clean file and folder structure. At 9:30pm on a random Tuesday, I’ve got a functioning CRUD app—input your info about your next visit to the dog park, refresh the page and there it is for the world to see.
You can accuse me of talking my book, but in all honesty, there were some things the AI simply couldn’t solve for. It insisted I needed the code below:
<!-- The core Firebase JS SDK is always required and must be listed first --> <script src=“https://www.gstatic.com/firebasejs/9.6.8/firebase-app.js”></script> <!-- Add Firestore (database) --> <script src=“https://www.gstatic.com/firebasejs/9.6.8/firebase-firestore.js”></script>
But it didn’t connect that to an error I kept getting:
Uncaught SyntaxError: Unexpected token 'export'
A quick web search and I found the following question and answer pair. Do I understand why deleting that code fixed the issue? Of course not. But it let me get closer to a working solution.
The AI had a bunch of ideas about how to solve for this one:
Uncaught SyntaxError: Cannot use import statement outside a module
I tried three or four of its solutions, but we got nowhere. But the web had what I needed. I fed the context of the answer back in and voila, a working web app.
Index.html:
```
Today's Data
``` App.js:
// Initialize Firebaseconst firebaseConfig = { apiKey: "MYAPIKey", authDomain: "coolest-dogpark-scheduler.firebase.com", projectId: "Bens Awesome Project Goes Here", storageBucket: "Ben's Bucket", messagingSenderId: "NUMBERS", appId: "LOTTA CHARACTERS"};// Initialize Firestore (Database)const app = firebase.initializeApp(firebaseConfig);const db = firebase.firestore(app);// Form and data displayconst form = document.getElementById('data-form');const dataDisplay = document.getElementById('data-display');// Handle form submissionform.addEventListener('submit', async (event) => { event.preventDefault(); const name = document.getElementById('name').value; const dogName = document.getElementById('dog-name').value; const time = document.getElementById('time').value; const timestamp = firebase.firestore.Timestamp.now(); await db.collection('data').add({ name, dogName, time, timestamp }); // Clear form form.reset(); location.reload();});// Fetch data and displayasync function fetchData() { const today = new Date(); today.setHours(0, 0, 0, 0); const querySnapshot = await db.collection('data') .where('timestamp', '>=', firebase.firestore.Timestamp.fromDate(today)) .get(); dataDisplay.innerHTML = ''; querySnapshot.forEach(doc => { const data = doc.data(); dataDisplay.innerHTML += `<p>${data.name} - ${data.dogName} - ${data.time}</p>`; });}// Call fetchData() initially and whenever the form is submittedfetchData();form.addEventListener('submit', fetchData);
Lots of folks are making claims about AI replacing programmers, but for the time being, the effect on my usage was the opposite. The AI was the inspiration to try coding again; it was a springboard that got me going and handled some basics. But it wasn’t enough to get me to the finish line on its own. When things started to get tricky, I was pinging colleagues in chat for help, or searching up error messages and sifting through answers from Stack Overflow, technical documentation, and blog tutorials.
What do you call something that can string together complex concepts and provide useful answers to questions about everything from history to poetry to programming? A friend of mine suggested “thought calculator” and I’ve fallen in love with this phrase. It perfectly captures this new technology’s power, and its limitations.
The AI isn’t sentient or autonomous, as far as we know, but it has a form of intelligence which you can leverage as a tool. Coding is one of its best applications, because it uses textual instructions to produce an objective output. We can argue forever about the quality of an AI’s marketing copy or literary essay, but with programming, setting aside for a moment the important question of code quality, we can test to see if it produces the desired result.
As our CEO announced last week, we’re thinking about ways we can use the power of generative AI to continue building a knowledge community that is open and accessible to all. Some folks protested that it would be wrong for us to train AI on Stack Overflow data, but the reality is lots of people are already doing that. We could sit around and do nothing while other organizations ingest the web into an algorithmic black box, or we could try to build a system where human input is still recognized and rewarded, where the output created by the collaboration of a human and their thought calculator is something everyone can then leverage and learn from.
If you’ve been experimenting with AI to help you write code, let us know what you think in the comments. I’ll try to be back in a week or two with an update, once my army of autonomous agents completes my plan for world domination.
The post The worst coder in the world tries an AI sidekick appeared first on Stack Overflow Blog.
Paul van der Boor is a Senior Director of Data Science at Prosus and a member of its internal AI group. He talks with Ben about what’s happening in 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.
Episode notes:
Prosus, one of the world’s largest tech investors, acquired Stack Overflow in 2021.
Check out the annual State of AI Report from Nathan Benaich and Ian Hogarth.
Read our CEO’s recent post on Stack Overflow’s approach to Generative AI.
Connect with Paul on LinkedIn.
Today’s Lifeboat badge winner is suvayu for their answer to How to put a big centered “Thank You” in a LaTeX slide.
TRANSCRIPT
The post Is this the AI renaissance? appeared first on Stack Overflow Blog.
What is KYC and why is it so challenging?At its most basic, Know Your Customer (KYC) is a due diligence process used to verify that the person is who they say they are and that data they have shared is correct (e.g. phone number, email, and address). KYC regulations are in place to prevent criminal activities such as identity fraud, money laundering, and other financial crimes. However, the compliance and implementation of these regulations comes with a host of challenges. Some of these challenges include:
- Customer identification: You’ll need to compare the customer’s likeness with a photo on an approved ID card (usually government-issued like a passport or driver’s license). There is additional friction if this happens in-person.
- Documentation verification: Making sure the picture matches the person isn’t enough; the government-issued ID of the individual must be checked for forgery or tampering. This requires the person carrying out the verification to be trained to recognize these signs and look for the presence of appropriate watermarks, etc.
- Address verification: As an additional check on their documents, the customer must provide proof that they live at the address on the government-issued ID documents (Proof of Address or POA) usually by providing recent utility bills. This is getting trickier as many of us opt for electronic bills, so the customer may have to request one-off letters from approved sources to prove they live at the address they’ve provided.
- Verify contact details: Finally, you’ll need to check that the email address and phone number provided are correct and belong to the customer. A common approach is to support a one-time-passcode (OTP) system that allows a customer to enter the passcode they receive and have it linked to the account profile that is being created.
For software developers, all of these steps slow down your user onboarding. Many of these verification steps are manual and some require the customer to come in to meet face-to-face, which adds friction to the onboarding experience. This manual process creates additional costs for the organization performing the validations.
KYC can have multiple layers of customer verification such as anti-money laundering checks and risk assessments—for example, using Ekata to spot if an address provided has being used repeatedly before for fraudulent transactions. It can even include checking an individual’s crypto footprint for inappropriate transaction history or if they’re on a sanctions list (Ciphertrace).
For the purposes of this post, we’re going to look at how Mastercard Open Banking Account Owner Verification APIs can help support the most fundamental step in a KYC pipeline: verify the digital identity of your consumers or small businesses based on their provided name, address, and contact details.
But the banks have already done KYC for their customers!Yes, the banks have built a rigorous KYC practice to verify customers before they open any account. Banks adhere to a range of regional privacy, security, and anti-money laundering regulations. Many of us have had to go through that process of providing proof of identity and address as well as completing registrations using OTPs sent to our email and phone. An important consideration is how we as customers also keep this information up to date, so we don’t miss any important communications from our bank.
The timeliness, quality, and accuracy of the customer data that the bank holds is very useful, but also valuable because of the time and effort invested in collecting it and keeping it up to date. The US Open Banking API enables you to unlock this value. Specifically, we can use the Account Owner Verification API to access this valuable data.
Using Mastercard Account Owner Verification APIs to leverage the bank’s KYC effortsOpen banking empowers users (consumers and small businesses) to access, use, and benefit from their own financial data. They can control what accounts can be seen, how long that access can be granted, and for what purpose— things like opening new accounts, securing loans, improving credit scores, and enabling consumer choice in payments.
The user (your customer) feels safe doing this because they are authenticating directly with their bank using their online banking credentials, giving them confidence that the third-party won’t see or store them.
The US Open Banking API handles a trusted connections to the banks, provides a secure dialog so the account holder can authenticate, and caches the financial data so when you execute a query it comes back quickly (avoiding a round trip to the bank every time).
The US Open Banking API provides a range of features including account aggregation, payment enablement, and confidence scores that can be used for financial services use cases like lending, payments, and account opening.
To help support your KYC pipeline, we can use Mastercard’s Account Owner Verification API, which returns bank pre-verified data (i.e. name, email, address and phone number) along with identity insights and an identity risk score based on users’ activity pattern and its association to help detect fraudulent behavior, thereby instantly verifying that the user (bank account owners) are genuine and help mitigate online fraud. This makes it exponentially harder for criminals to use real or fake IDs to commit fraud and significantly reduces identity fraud by enhancing the effectiveness of fraud detection systems for account openings, me-to-me (M2M) transfers, peer-to-peer (P2P) transfers, bill payments, and other transactions.
How it works1. Your server registers a customer with Open Banking and receives an ID for this customer. 2. With this customer ID, your server can generate a redirect URL for loading the connect experience that will allow the customer to connect to their bank. 3. Your frontend application redirects the customer to connect using the generated URL from step 2. 4. The customer logs into their financial institution using their bank credentials through the connect experience. 5. The customer grants permission for their financial data to be accessed.
Once the customer has granted you access to the account, you make a call to the Get Account Owner Details API.
The Get Account Owner Details API is aligned with the Financial Data Exchange (FDX) standards. The FDX is dedicated to unifying standards for secure and convenient access of user-permissioned financial data sharing throughout the financial services industry. This allows the API to return the payload about the user (consumer or small business) in a standard format with the following details:
- Names: The names of the account holders. It will also indicate whether it is a person, business, or other entity.
- Address: The standard format for a US address, broken into constituent parts, which will also have an entry to say if it is a business or home address.
- Phone numbers: An array of contact phone numbers along with type (Personal/Business).
- Email addresses: An array of email addresses and their type (Personal/Business).
- Documentation: An array of the document proofs provided: tax identifier SSN, government-issued ID (passport number, visa number, driver’s license number, etc.) Quick sidebar: though this element is a required field in some regions, it is not mandatory in the US, and as such, it is at the discretion of the bank.
Example response
{ "holders": [ { "relationship": "AUTHORIZED_USER", "ownerName": "John Smith, PhD", "firstName": "John", "middleName": "L", "lastName": "Smith", "suffix": "PhD", "nameClassification": "person", "nameClassificationconfidencescore": 100, "addresses": [ { "ownerAddress": "434 W Ascension Way", "type": "Home", "line1": "434 W Ascension Way", "line2": "Suite #200", "line3": "UT 84123", "city": "Murray", "state": "UT", "postalCode": "84123", "country": "USA" } ], "emails": [ { "isPrimary": true, "email": "myname@mycompany.com", "emailType": "Personal" } ], "phones": [ { "type": "HOME", "country": "61", "phone": "1-801-984-4200" } ], "documentations": [ { "taxId": "123-45-7890", "taxIdCountry": "USA", "governmentId": "123456789" } ] } ]}
Congratulations! Now you have the data (verified by a bank) necessary to enhance your customer onboarding process.
How are the account holder’s credentials secured?The US Open Banking Service uses OAuth when integrating into the bank APIs and as a third party in that process, it never sees the account holder credentials. When the account holder successfully authenticates with their bank and selects the account they want to allow access to and for how long, the service will get a token that it encrypts and stores until it needs to access the data. It will be limited to just the data that the account holder has explicitly granted access to.
If you are using the Get Account Owner Details API as part of a one-off customer onboarding verification step, you can set the token up to be a single-use token to further limit access to the account owner data. If, however, it is part of a broader Account Opening process, Account Aggregation or similar Open Banking use case, you can configure the token to live for a longer period of time.
How do I get started?Check out this Quick Start Guide on Mastercard Developers to get up and running with the US Open Banking API and then use the Get Account Owner Details API call to pull the data necessary to power your KYC process.
The post Instantly verify your customers online with Open Banking APIs appeared first on Stack Overflow Blog.
Welcome to ISSUE #174 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: the difference between software engineering and computer science, hard-coding table and column names, and open-sourcing nuclear physics.
From the blogWhat’s the difference between software engineering and computer science degrees? stackoverflow.blog
While these two areas of study may seem very similar, they do have some differences.
Are meetings making you less productive? stackoverflow.blog
Developers view about half their meetings negatively. Can we find better ways to use that time?
Going stateless with authorization-as-a-service (Ep. 553) stackoverflow.blog
The home team welcomes Alex Olivier, cofounder and product lead at Cerbos, for a conversation about how to centralize business logic in a microservices environment, the value of stateless applications, and what’s under Cerbos’s hood.
Maximize Cloud Savings with DoiT promotion
AWS and Google Cloud customers are invited to an exclusive program designed to help tackle complex cloud issues. Focus on innovation while we help you save on cloud costs and avoid billing surprises. Learn how to get started.
Interesting questionsIs it okay to hard-code table and column names in queries? softwareengineering.stackexchange.com
How often to you change your table and column names but not the structure?
Does the law make exceptions for good samaritans? law.stackexchange.com
For those of us whose legal education comes from the back half of Law and Order.
My employer’s “401(k) contribution” is cash, not an actual retirement account. What are my options? money.stackexchange.com
Go for the old school 401(k) and stuff it in your mattress.
How much louder was a Napoleonic era cannon than a musket? history.stackexchange.com
Loud enough that when Napoleon met his Waterloo, it could be heard over 300km away in London.
Links from around the webOpen source is fueling the future of nuclear physics github.com
You don’t really associate “openness” with “nuclear fusion,” but that’s changing!
New on the web: How to detect disabled JavaScript in CSS www.stefanjudis.com
Though very few people disable JavaScript these days, it’s good to be able to detect that. And now, you can do it in CSS!
React, visualized react.gg
This is a great free visual introduction to React that illustrates its fundamental concepts in a beautiful way!
Building webhooks into your application: Guidelines and best practices workos.com
Webhooks are a common way for devs to receive events from your apps, but they can be tougher to implement than you might think.
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #174: This email could have been a meeting appeared first on Stack Overflow Blog.
Computer scientist Jean Yang, founder and CEO of monitoring and observability platform Akita, tells the home team how her drive to improve developer tooling led her from academia to Silicon Valley.
Episode notes:
Akita is a monitoring and observability platform that watches API traffic live and automatically infers endpoint structure.
Jean, who comes from a family of computer scientists, earned a PhD from MIT and taught in the CS department at Carnegie Mellon University before founding Akita.
Read Jean’s post on the Stack Overflow blog: Monitoring debt builds up faster than software teams can pay it off.
Jean is on LinkedIn and Twitter.
Congrats are in order for Stellar Question badge winner legendary_rob for asking Adding a favicon to a static HTML page.
TRANSCRIPT
The post When setting up monitoring, less data is better (Ep. 563) appeared first on Stack Overflow Blog.
SPONSORED BY CHRONOSPHEREA common refrain you’ll hear these days is that servers should be scaled out, easy to replace, and interchangeable—cattle, not pets. But for the ops folks who run those servers the opposite is true. You can’t just throw any of them into an incident where they may not know the stack or system and expect everything to work out. Every operator has a set of skills that they’ve built up through research or experience, and teams should value them as such. They’re people, not pets, and certainly not cattle—you can’t just get a new one when you burn out your existing ones.
On this episode of the podcast—sponsored by Chronosphere—we talk with Paige Cruz, Senior Developer Advocate at Chronosphere, about how teams can reduce the cognitive load on ops, the best ways to prepare for inevitable failures, and where the worst place to page Paige is.
Episode notes:
Chronosphere provides an observability platform for ops people, so naturally, the company has an interest in the happiness of those people.
If you’re interested in the history of the pets vs. cattle concept , this covers it pretty well.
Previously, we spoke with the CEO of Chronosphere about making incidents easier to manage.
We’ve covered this topic on the blog before, and two articles came up during our conversation with Paige.
You can connect with Paige on Twitter, where she has a pretty apropos handle.
Congrats to Stellar Question badge winner Bruno Rocha for asking How can I read large text files line by line, without loading them into memory?, which at least 100 users liked enough to bookmark.
The post Ops teams are pets, not cattle appeared first on Stack Overflow Blog.
Paulo and Guilherme Silveira, brothers and cofounders of edtech platform Alura, join the home team for a conversation about polyglot programming, edtech, and the role of generative AI.
Episode notes:
Alura is a Portuguese-language edtech platform where users can learn programming, backend and mobile development, data science, design and UX, DevOps, and more.
They started small, grew into a bustling online program, then purchased a majority stake in FIAP, a private university in São Paulo, Brazil.
Paulo and Stack Overflow Director of Engineering Roberta Arcoverde cohost a popular Portuguese-language podcast about programming, design, startups, and technology.
Paulo’s new open-source project is full of career resources for T-shaped developers.
Connect with Alura CEO Paulo Silveira on LinkedIn.
Connect with Alura Chief Education Officer Guilherme Silveira on LinkedIn.
Connect with Roberta Arcoverde on LinkedIn.
Today’s Lifeboat badge winner is netblognet for their answer to Get JSON object from URL.
TRANSCRIPT
The post We bought a university: how one coding school doubled down on brick and mortar (Ep. 555) appeared first on Stack Overflow Blog.
In today’s remote-first, distributed team culture, tech leaders are in search of ways to achieve economies of scale across teams while still empowering individual members to be autonomous. For many modern organizations, the answers lie in creating a space where individuals with shared interests can come together to collaborate and engage on a common technology space, problem set, or tech stack to improve upon their craft, much like the guilds of the medieval times. To help our customers achieve this, we’re happy to announce a new feature on Stack Overflow for Teams Enterprise: Communities.
Communities are shared spaces where users can build, organize, and enable cross functional groups within their organization to collaboratively learn, share, and solve problems focused around similar technologies, domains or interests.
Guilds: the first Communities of PracticeSome historians believe the concept of guilds can be traced back as early as 24th century BC Mesopotamia and has been significant in the development of human civilization throughout history, including giving us the first universities. Guilds organized artisans, merchants, and craftsmen specializing in a particular craft, but could also be religious or fraternal guilds organized around specific beliefs and interests. Post-classical guilds utilized the classifications and standards of expertise, beginning as apprentice, advancing to journeyman, then becoming a master craftsman.
Though the economic guild system has died out, the concept of guilds in developing and mastering a domain has seen a resurgence. We see organizations like Spotify returning to the guild model because many of the challenges tech organizations face ultimately come down to people—distributed teams, knowledge silos, redundant work, inefficiencies, and need for growth opportunities. Communities of Practice (CoP) can address these issues in effective ways.
According to the Scaled Agile Framework, Communities of Practice are organized groups of people with a common interest in a specific technical or business domain, regularly collaborating to share information, improve their skills, and actively work on advancing their knowledge of the domain. In other words, CoPs are the modern day guild for knowledge workers.
Enabling Communities of Practice at Stack OverflowStack Overflow has a strong foundation of enabling technical communities both in the global public community and within private organizations. But a lot has changed since we first set out to build a library of programming knowledge. The variety of formats and sheer volume of content out there requires more time and effort to find what you need all while the technologies we use continue to evolve. More people leverage technology in their everyday lives, resulting in an increase in both technology and technology-adjacent roles and growing diversification in tech backgrounds. The result is more people are searching for more content around more technologies than ever before.
On the other hand, there’s plenty that remains constant since we began in 2008. How we as humans learn starts with a question—Q&A is still an intrinsic part of the learning model. Additionally:
- We want to share our knowledge and help others
- We want to be more efficient and productive
- We want to be part of community
- We want to be recognized for our contributions to our communities, especially at work
- We know tech communities are diverse and need to be inclusive, and
- Technologists trust Stack Overflow to help them learn and solve problems
As technology and the people using it change, our needs for learning change too. So we looked at how we can continue to enable our technical communities to develop technology through collective knowledge and identified three main areas where we have an opportunity to make a great impact: enable more domains to emerge, broaden the types of content and ways to practice skills, and expand community roles to provide more ways for people to engage and have a sense of belonging.
Announcing Communities on TeamsOur aim is to evolve our platform to empower technical communities to learn, share, and grow together. One big step in that direction is launching Communities on Teams, designed to bring together people and knowledge within a technology organization around a specific domain.
The newest feature in the Stack Overflow for Teams Enterprise plan, Communities are self-organizing, bottoms-up groups that help bring colleagues together across projects, interest, and need, narrowing the scope to be more focused around a central theme or domain. While open to all instance members, Communities are especially valuable to those working in the specific domain as content there is aggregated based on the tags chosen for the Community. Users who join these Communities can keep a pulse on activity around their area of interest so they know what’s trending, who’s sharing new knowledge, and where there’s opportunity to contribute or learn.
Once enabled by your Stack Overflow for Teams admin, anyone can create or join a Community. Each Community has a unique name, purpose, and set of tags that define it. From within your Community, you can see recent activity and trending content in your Community, ask a question, post an Article, or create a Collection. You can also see other members in your Community and identify practitioners with expertise across multiple related tags or in a project. Communities identify these experts and their contributions through member acknowledgement and highlight activity from these designated subject matter experts.
By enabling employees to connect, leverage collective knowledge, and work together to solve problems, Communities can strengthen a sense of belonging, provide focused opportunities to participate, reduce duplicate efforts, and ultimately identify more efficient solutions that drive positive outcomes.
How organizations can use CommunitiesThere are many ways organizations can use Communities to build an inclusive, outcome focused culture. Whether or not your organization already leverages communities of practice or guilds, Communities on Teams is a great platform to enable them and help them thrive. Here are some examples of how customers can use Communities:
- Specialized collaboration: Increase speed to solutions through highly-targeted collaboration and problem solving. (example: cloud migration initiative)
- Support: Increase ticket deflection, speed-to-resolution, and customer satisfaction by empowering your support team to step into their full potential for problem solving and process building. (For example: IT, customer support)
- Areas of practice and knowledge curation: Tailor what’s important to your community to learn, share relevant knowledge, and discover best practices and standards. These are typically focused around a specific technical topic or tooling. (For example: CI/CD, DevOps, AI/ML, API platform)
- Affinity groups: Increase sense of belonging and connect users across your workforce with shared interests, affinities, or identities. (For example: accessibility, ally groups, women in tech)
We believe by combining domain, practice, and community, we will expand long-held notions of what a distributed community can accomplish:
- Bring together individuals within a common domain to learn and solve problems together.
- Enable the monolithic community to self select into many smaller communities without disturbing the foundation of the whole.
- Blend individual and community goals within a single platform.
- Create new opportunities for more members to contribute more knowledge and feel a sense of belonging to the community.
- Elevate passive consumers into active learners.
We’re excited to see how your organization will learn, share, and grow together with Communities on Teams, both now and as we continue to make more updates. To learn more about the value of Communities of Practice and how to leverage Communities in your organization, join our upcoming webinar.
The post Introducing Communities on Teams: where domain, practice, and community come together with purpose appeared first on Stack Overflow Blog.
Throughout history, great thinkers have made predictions about how new technology would reshape the way in which humans work and live. With every paradigm shift, some jobs grow, some change, and some are lost. John Maynard Keynes wrote in 1930 that new technology meant humans would be working 30 hours a week or less, and that the main challenge would be what to do with all our free time. So far, predictions of this nature haven’t exactly come true. As new technology empowers us, we push ourselves to new heights and reach for previously unattainable goals.
Over nearly 15 years, Stack Overflow has built the largest online community for coders to exchange knowledge, a place where anyone with an internet connection can ask or answer questions, free of charge, and learn from their peers. Stack Overflow for Teams, our enterprise SaaS product, is trusted by over 15,000 organizations to serve as their internal knowledge bases. With the recent advent of dramatically improved artificial intelligence, many industries are wondering how technologies like ChatGPT will change their business. For software development, the answer seems more immediate than most. Even before the latest wave of AI, a third of the code being written on popular code repositories was authored by an AI assistant.
Today, sophisticated chatbots, built on top of cutting edge large language models (LLM), can write functional code for a website based on nothing more than a photo of a rough sketch drawn on a napkin. They can answer complex queries about how to build apps, help users to debug errors, and translate between different languages and frameworks in minutes. At Stack Overflow, we’ve had to sit down and ask ourselves some hard questions. What role do we have in the software community when users can ask a chatbot for help as easily as they can another person? How can our business adapt so that we continue to empower technologists to learn, share, and grow?
It’s worth reflecting on an important property of technological progress. The Jevons Paradox shows us that, as innovation allows us to do more, we settle on a new normal, moving the goal posts for what we expect of people and organizations, then competing to see who can find new ways to pull ahead of the pack. For knowledge work, as the cost of an action diminishes, we often do more of it. Abstracting away repetitive or tedious tasks frees technologists up to make new discoveries or progress innovation.
If new AI systems make it possible to create software simply by chatting with a computer, my prediction is that, far from the job of programmer disappearing, we’ll end up with millions of new software developers, as workers from fields like finance, education, and art begin making use of AI-powered tools that were previously inaccessible to them. We are enthusiastic about welcoming this next generation of developers and technologists, providing them with a community and with solutions, just as we have for the last 15 years. We’ve got a dedicated team working on adding GenAI to Stack Overflow and Stack Overflow for Teams and will have some exciting news to share this summer.
Community members and AI must work together to share knowledge and solve problemsI’m not alone in thinking AI might lead to an explosion of new developers. I’ve heard similar sentiments expressed recently by Microsoft founder Bill Gates, by Geoff Hinton, the godfather of the neural network approach that produced today’s AI revolution, and by Stephen Wolfram, a pioneer across computer science and mathematics. Each sees in today’s AI the potential for the loss of certain jobs, yes, but also, if history is a guide, a future in which a great variety of more highly skilled work becomes available to an even larger group of people. Just as tractors made farmers more productive, we believe these new generative AI tools are something all developers will need to use if they want to remain competitive. Given that, we want to help democratize knowledge about these new AI technologies, ensuring that they are accessible to all, so that no developers are left behind.
I talk to developers of varying experience levels all of the time, and I’ve been hearing anecdotes of novice programmers building simple web apps with the help of AI. Most of these stories, however, don’t begin and end with an AI prompt. Rather, the AI provides a starting point and some initial momentum, and the human does additional research and learning to finish the job. The AI can debug some errors, but is stymied by others. It can suggest a good backend service, but often can’t solve all the points of friction that arise when integrating different services. And of course, when a problem is the result not of instructions from a machine, but human error, the best answers come from other people who have experienced the same issues.
For more experienced programmers, AI will be an amplifier of their existing skill, making them more ambitious in their projects. The result, as Jevons would predict, is that they spend more time with AI, but also more time creating new ideas, researching new topics, and asking new questions that had not occurred to them before. They feel empowered to reach farther beyond their traditional skillset and to push the boundaries in terms of the kind of work they want to take on.
We are excited about what we can bring to the fast moving arena of generative AI. One problem with modern LLM systems is that they will provide incorrect answers with the same confidence as correct ones, and will “hallucinate” facts and figures if they feel it fits the pattern of the answer a user seeks. Grounding our responses in the knowledge base of over 50 million asked and answered questions on Stack Overflow (and proprietary knowledge within Stack Overflow for Teams) helps users to understand the provenance of the code they hope to use. We want to help coders stay in the flow state, allowing them to create with the latest tools with the confidence that they will be able to document and understand the provenance, source, and context of the code being generated.
Community and reputation will also continue to be core to our efforts. If AI models are powerful because they were trained on open source or publicly available code, we want to craft models that reward the users who contribute and keep the knowledge base we all rely on open and growing, ensuring we remain the top destination for knowledge on new technologies in the future.
AI systems are, at their core, built upon the vast wealth of human knowledge and experiences. They learn by training on data – for example open-source code and Stack Overflow Q&A. It is precisely this symbiotic relationship between humans and AI that ensures the ongoing relevance of community-driven platforms like Stack Overflow. Allowing AI models to train on the data developers have created over the years, but not sharing the data and learnings from those models with the public in return, would lead to a tragedy of the commons. It might be in the self-interest of each developer to simply turn to the AI for a quick answer, but unless we all continue contributing knowledge back to a shared, public platform, we risk a world in which knowledge is centralized inside the black box of AI models that require users to pay in order to access their services.
AI is built on our collective knowledge, and we must all participate in building its futureAs 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.
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.
Incorporating generative AI technologies into the organizations using Stack Overflow for Teams will allow us to layer a conversational interface on top of this wealth of information. We believe this could lead to tremendous productivity gains: from new hires being able to onboard more quickly, to speed up developer workflows, as users are able to quickly ask questions and retrieve answers tapping into the company’s history, documentation and Q&A.
The example above is just one of many possible applications of GenAI to our Stack Overflow public platform and Stack Overflow for Teams, and they have energized everyone at our company. We’ll be working closely with our customers and community to find the right approach to this burgeoning new field and I’ve tasked a dedicated team to work full time on such GenAI applications. I’ll continue to share updates through channels such as my quarterly CEO blog, but I’ll be back in touch soon to announce something big on this topic. In the meantime, thank you to our community and customers for continuing to help us on our mission to empower the world to develop technology through collective knowledge.
The post Community is the future of AI appeared first on Stack Overflow Blog.
Welcome to ISSUE #173 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: the downside of data-driven decisions, around the world without leaving your car, and a big collection of accessibility resources.
From the blogThe people most affected by the tech layoffs stackoverflow.blog
Overall, these layoffs are a body blow to diversity in tech, not just slowing but actually reversing hard-won gains.
“Data-driven” decisions aren’t innovative decisions stackoverflow.blog
If you want to innovate new solutions, you can’t rely on data about existing solutions.
From cryptography to consensus: Q&A with CTO David Schwartz on building blockchain apps stackoverflow.blog
Imagine a world where you own your digital purchases instead of license them.
From Smalltalk to smart contracts, reflecting on four decades of programming (Ep. 551) stackoverflow.blog
We chat with Dean Tribble about his journey from Xerox PARC to blockchain CEO.
Put your best work on display! promotion
Showcase your skills and build an online resume with .ME, the most personal domain name. Check if your FirstNameLastName + .ME combination is available and check out lots of developer-specific tips and resources for building your online presence.
Interesting questionsSQL as a means of avoiding “releases” softwareengineering.stackexchange.com
On monkey patches and cowboy coding…
Can you travel around the world by ferries with a car? travel.stackexchange.com
Who’s up for a road trip?
Is RAM wiped before use in another LXC container? security.stackexchange.com
What did the containers say to RAM when overprovisioning? Just so we’re not on the same page…
Do I really need plural grammatical number when my conlang deals with existence and uniqueness? conlang.stackexchange.com
There are many language without formal plural.
Links from around the webAccessibility for designer: where do I start? stephaniewalter.design
This is an amazing collection of accessibility resources for the projects you might be building!
Buying a bicycle using Playwright maciekpalmowski.dev
We’ve all wanted to buy one of those limited-edition items that sell out immediately…here’s how one dev took matters into his own hands.
CSS creator Håkon Wium Lie interview by Evrone evrone.com
This is a fascinating interview with the creator of CSS on his journey into the web.
A guide for building open-source communities blog.vaunt.dev
Open-source communities have been around for years. Here’s a breakdown of how to attract contributors, build infrastructure, and iterate on your own.
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #173: From Smalltalk to smart contracts appeared first on Stack Overflow Blog.
For this episode, we talked with Matt Butcher, CEO at Fermyon Technologies, about distributed computing, the long-term promise of WebAssembly, and the HR mix-up that switched his career from lawn care to computer programming.
Episode notes:
Fermyon offers serverless cloud computing. Spin is their developer tool for building WebAssembly microservices and web applications; check it out on GitHub.
Like past podcast guest David Hsu of Retool (and yours truly), Matt earned a degree in the humanities before deciding to prioritize his “side gig” in tech.
Follow Fermyon on GitHub. Matt is on LinkedIn.
Shoutout to Lifeboat badge winner keineahnung2345 for saving Hamming distance between two strings in Python from the dustbin of time.
TRANSCRIPT
The post The philosopher who believes in Web Assembly appeared first on Stack Overflow Blog.
For years, we in tech have grumbled about meetings. According to a study from SurveyMonkey, 32% of people think “this meeting could have been an email” all or most of the time. Sometimes we get roped into meetings with a dozen or more people without really knowing why we’re there. And when we get out, we often have just minutes before our next meeting.
At the beginning of the year, Shopify took drastic steps to reduce their meeting burden. They automatically canceled all meetings of three or more people, a total of around 12,000 calendar series and events that would have taken up roughly 322,000 person hours. Chaotic and drastic? Maybe. But as Kaz Nejatian, Shopify’s COO and VP product wrote in the email announcing the change to employees, “We’ve unleashed the ‘chaos monkey’ before and have always come away faster—faster at shipping, at making great decisions, at getting to results and impact. No one joined Shopify to sit in meetings.”
Chances are that no matter where you work, you didn’t join that company for the meetings. You wanted to build software. But the meetings became part of that, and the more senior you are, the more meetings you probably get asked to attend.
In this article, we’re going to take a look at the productivity impact of meetings, reevaluate why we have meetings at all, and consider ways to make meetings better (or avoid them altogether).
One third of meetings are unnecessaryUnless we’re actively multitasking during a meeting (which humans do badly), we’re blocked from other parts of our work: writing code, debugging processes, or designing new features. So if we’re asking for our coworkers’ time, that time should be spent productively. Professor Thomas Fritz of the University of Zurich ran several studies about how software developers perceive their own productivity across their activities. Perceptions across all three studies found that developers view slightly more than half of their meetings negatively. For more from Prof. Fritz, check out our recent podcast with him:
Plenty of things about meetings can make attendees feel they’re wasting their time: guest lists that spiral out of control, overwhelmingly negative participants, and meeting participants who stray off-topic. Otter.ai and Stephen G. Rogelberg, Professor of Organizational Science, Management at UNC Charlotte, found that developers in bad meetings report feeling “frustrated” and “annoyed.” Even good meetings can turn bad if run poorly.
In that same study, they found that developers see about one-third of all meetings as unnecessary—they want to decline 31% of meetings, but only nix 14%. Worse yet, bad meetings not only affect how developers feel about their jobs, they cost organizations money—an estimated $25,000 per employee per year. You can estimate how much any given meeting costs your company with this calculator. And that’s just the direct costs of the meeting, regardless of how disruptive it is to the rest of a developer’s day.
Meetings don’t happen in a vacuum; often they happen back-to-back with other meetings. Microsoft’s Human Factors Lab found that back-to-back meetings cause a great deal of stress and make people worse at meetings.
This wasn’t just a subjective perception. They strapped an EEG cap that measured brain waves to 14 volunteers and either set them up with four consecutive meetings or four meetings with a ten minute meditation break in between. They found that back-to-back meetings caused stress to build up and caused attendees to lose focus and engage worse over time. Surprisingly, one of the biggest sources of stress came from the transition between meetings, as participants tried to switch gears without adequate time.
These factors combine to drag down the company as a whole. In a study of 20 organizations in manufacturing sectors, Simone Kauffeld of Technische Universität Braunschweig and Nale Lehmann-Willenbrock of the University of Amsterdam found that bad meeting behaviors were associated with lower levels of market share, innovation, and employment stability. A company that doesn’t have meeting discipline may soon find their best employees fleeing to greener pastures as their balance sheets slowly drift into the red.
All these downsides to meetings may make you wonder why we have meetings at all.
Wait, why do we have meetings at all?Obviously, nobody schedules a meeting to torture their coworkers. Meetings are the standard tool for collaboration in companies, ways to find consensus and make a decision, share knowledge, or brainstorm solutions—essentially, they are pop-up communities of practice. Get everyone in a room and talk it out.
The Harvard Business Review quotes an unnamed pharmaceutical executive who sums up the pro-meeting bias that many people in leadership positions hold: “Our abundance of meetings at our company is the cultural tax we pay for the inclusive learning environment that we want to foster…and I’m OK with that. If the alternative to more meetings is more autocratic decision-making, less input from all levels throughout the organization, and fewer opportunities to ensure alignment and communication by personal interaction, then give me more meetings any time!”
In fact, these are all things that I’d wager every one of us wants from a job. We may lionize the enlightened dictator CEOs of the past, but those who attract praise for their decisive style are a perfect example of survivorship bias. Those successful autocratic leaders still need to inspire and motivate their workforce to do the work behind their decisions. If you’ve ever worked for a determined and bull-headed leader who gave orders instead of direction, then you know how painful it is to work in a culture without collaboration.
Many people see reluctance to attend meetings or outright rejection of a meeting as an insult. They hold the attitude of our mystery pharma exec: by rejecting the meeting, you are rejecting an opportunity to collaborate. For one person, maybe that meeting would have been better as an email—you want something done, so send me the requirements/brief so I can do the thing. But another person may see the meeting as a way to feel out an idea, to get a better solution by working with an expert—you.
Those meetings that come during points in the software development lifecycle when collaboration is most important—planning, designing, and setting scope—end up being the ones that feel the least disruptive. At these moments, meetings aren’t taking you away from other work; they are the work. Without all stakeholders coming together and determining what needs to be done, engineering orgs would be coding solutions blind.
Finding ways to have better meetings (or skip them altogether)But let’s put some big asterixes on “all stakeholders” and “what needs to be done.” The right attendees can make a meeting feel productive for everyone. “I have heard in our studies that there are often meetings that have a lot of participants yet require only a few,” said Professor Fritz. “In my opinion, the most important part of a meeting is to take the time and reflect on who is really necessary for a meeting and even examine whether or not I should participate, and provide an environment in which it is OK to make that decision yourself.” Everyone at the meeting should have a sense of what to do next: Only 56% of participants leave meetings knowing what actions they need to take.
If you need to call a meeting, the research suggests that you need to be a good steward of the meeting, same as you would any other project. More than half of SurveyMonkey participants say two things would make meetings better: a clear agenda and a short meeting time. All participants can improve meetings by being direct, clear, and communicating in a way that leads to a decision. While we all have different communication styles, understanding which ones work best for video calls can make those better, too.
When meetings happen can also make a huge difference in whether people see them as valuable or not. One of the big changes that came with Shopify’s meeting-ageddon was that Wednesdays became meeting-free and Thursday had a block allocated for meetings of 50+ people. In a statement, Nejatian said, “Uninterrupted time is the most precious resource of a craftsperson, and we are giving our people a no judgment zone to subtract, reject meetings, and focus on what is most valuable.”
As the Human Factors Lab research above showed, breaks between meetings are absolutely necessary. But they also found that days without meetings improve overall collaboration, which is the whole reason we have meetings in the first place. And Professor Fritz and his students found that self-reported productivity declined if a developer had more than two meetings in a day.
All this research is a great excuse to have fewer meetings. Meetings will still occasionally be necessary, but limiting them improves developers’ lives. Dropbox uses a framework to identify when something needs a meeting that they call the 3 Ds: decisions, debates, and discussion. These are the business actions that need people to collaborate in order to get them done. Everything else can be served in other ways.
It’s worth thinking about how we can use other tools to take the place of those meetings we call reflexively. Status check-ins like the standup meeting have traditionally been served by actual meetings where everyone reports the status of their projects one at a time. But if companies genuinely want to embrace remote options (and preferably, asynchronous working), there are plenty of tools that will let you do that without turning on your camera. Better yet, there are tools that can automate status updates for you.
Especially for companies with remote options, finding ways to replace the visibility of office life can make a lot of the pushes for video meetings moot. Working in public as much as possible can help share information across teams and give everyone access to the company’s domain experts. Greater transparency reduces the need for meetings, which can build trust and improve overall morale. When we spoke with the folks at 84.51° about how they use Stack Overflow for Teams, Michael Carrico, director of data science, told us, “It’s a way to help spread institutional knowledge through that entry point person and make connections. Otherwise it would have been seen as more intrusive to directly ping or email somebody.”
Meetings, especially post-pandemic as more people have gone remote, have become the de facto way we collaborate, and it’s making us all more stressed, less productive, and worse at actually collaborating.
There is hope, but it takes thought, care, and the right tools. We have meetings for genuinely good reasons, but they take a toll on us and our organizations. You don’t have to nuke the calendars from orbit, but finding alternative ways to collaborate will win out in the end. And if you’re interested in improving our overall understanding of meetings, providing the data we need to change company cultures for the better, well Professor Fritz would like to speak to you.
The post Are meetings making you less productive? appeared first on Stack Overflow Blog.
The home team welcomes Alex Olivier, cofounder and product lead at Cerbos, for a conversation about how to centralize business logic in a microservices environment, the value of stateless applications, and what’s under Cerbos’s hood.
Episode notes:
Cerbos is an open-source, scalable authorization-as-a-service that aims to make implementing roles and permissions a cinch. Explore their docs or see how their customers are using Cerbos.
Stateless applications like Cerbos don’t retain data from previous activities, giving devs predictable plug-and-play functionality across cloud, hybrid, on-prem, and edge instances.
Connect with Alex on LinkedIn and Twitter.
Shoutout to Lifeboat badge winner Hoopje for rescuing Print in bold on a terminal from the dustbin of history.
TRANSCRIPT
The post Going stateless with authorization-as-a-service (Ep. 553) appeared first on Stack Overflow Blog.
Getting a job as a programmer no longer requires that you have a degree in that field—or even a degree at all. Our 2022 Developer Survey found that slightly more than 70% of respondents learned to code using online resources. And about a quarter of professional developers did not have a college degree.
Of course, plenty of developers do have college degrees in relevant fields. If you’re looking at colleges in the hopes of landing a coding job, you may have to decide: Computer science or software engineering? Both are great fields to study for a career in technology, so what’s the difference?
A formal education in either subject will contain a large amount of overlap, particularly in the first half. Both fields require a solid understanding of math, logic, and basic computer programming skills and concepts. After this, the two diverge significantly.
This article will discuss the subjects that each of these majors will cover, where they overlap, and which you might want to pick depending on where you’d like your career to go.
What is computer science?Computer science is the study of algorithms, information, and automation. This is a domain separate from programming; computer science builds off of the theory of computation, which has deep roots in logic, mathematics, and philosophy from hundreds of years before computers existed. In fact, the first computer science departments grew out of mathematics. The founder of the first computer science department, Purdue University professor Samuel D. Conte had a PhD in mathematics.
You can get a sense of what a university computer science degree will teach you by the questions you should be able to answer in the curriculum. What is the most efficient way to sort a list of random numbers? How can we transmit information between two people privately and how do we mathematically prove it is secure? Is there an algorithm that will sometimes return an answer, but other times continue endlessly? Much like how material science seeks to understand the fundamental properties of the things that civil engineering uses to build a bridge, computer science explores how we can organize and compute information as the foundation to writing software.
Take a look at our Computer Science Stack Exchange to get a sense of what sort of questions the field covers. Where the questions on StackOverflow.com cover the ins and outs of using programming languages and tools that build software, the computer science site is almost entirely about algorithms.
What is software engineering?However, knowing how to calculate things doesn’t mean you can build the operating systems and computer programs that have become ubiquitous in modern life. Software engineering is the study of how to design, build, test, and maintain software. How do you coordinate thousands of programmers to work together to build a new version of the operating system on your phone and make sure that millions of people can install the update successfully? How does a social media website organize its code so that people can use the same program in dozens of different languages? Software engineers need to understand the algorithms they use to build a product, but they focus their attention on designing and building a working product for thousands or millions of people.
In fact software engineering is less about the actual code that gets written and more about the processes one goes through to write the code. Ensuring that code is properly tested, deploying code changes to production are reliable and automated, and teams are working together with a common set of standards and practices are paramount to running a successful software project. Here at Stack Overflow, we have an Architecture Guild that regularly meets so that we can come up with standardized practices for all of engineering that ensure that our teams are working together as best as possible. As Yogi Berra once said, “In theory, there is no difference between theory and practice. In practice, there is.” Software engineering is about ensuring that coding practices get as close to theory as practically possible.
However, there is a specific difference between these degrees in certain countries like Canada (and technically in many other places). Canada has very strict laws regulating who can call themselves an engineer: to do so, you must be licensed by the local engineering board where the title will be used, similar to how there are rules around calling yourself a medical doctor or a lawyer in many countries. While this requirement initially came about because of a bridge collapse, it applies to anyone who calls themself an engineer, including software engineers. If you want to say you are a software engineer (or anything else with “engineer” in the title) in Canada, you need to be properly certified; otherwise you risk being fined.
Again, to see what the field discusses, check out the Software Engineering Stack Exchange. You’ll see a lot of questions about things like software design, bug tracking, and deploying code.
What else could I study if I want to code?Computer science and software engineering alone aren’t enough to build a software product. Computer engineering works to design the CPUs, GPUs, and data storage devices that enable our digital worlds and none of those devices would even turn on without electrical engineering. Mathematics builds the theory and understanding of numbers that underpin the foundation of cryptography and statistics builds the tools to process and understand the information we gather. Newer fields like data science are starting to get their own degrees as artificial intelligence and advanced statistical modeling blurs the line between math, statistics, and computer science. Many other fields in science and engineering use a combination of computer science, software engineering, computer engineering, and mathematics to design planes, develop vaccines, and create animations for TV and film. In fact, many of the best programmers I know have degrees in mechanical engineering or bioinformatics and use their skills to develop robotic systems or medical drug treatments. Even medical degrees like neuroscience and audiology are now requiring programming knowledge so clinicians can compare brain images or sound recordings in scientific programming languages like R or MATLAB.
Put together, computer science research creates the building blocks that software engineering uses to design and build a working computer program. Here at Stack Overflow, software engineering practices have helped us bring together a community that serves around 500 million pages a month. Our team uses these practices to coordinate over 200 programmers to put together the website you see today. What most people might not know is that this website runs on just five servers together small enough to fit in your living room. A solid understanding of computer science principles allowed our team to efficiently store and compute all the data we keep to help people get answers to their questions. As we work to move our company fully into the cloud, we rely on software engineering principles to allow us to continue to smoothly run all our websites while we redesign our software architecture and move our code from physical servers to cloud services.
There is no right path for how to become a developer, so keep asking questions to help you find the best path for you!
The post What’s the difference between software engineering and computer science degrees? appeared first on Stack Overflow Blog.
Welcome to ISSUE #172 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: a new browser has entered the game, an absurd exercise in spelling shows how difficult English is, and a guide to avoiding dark patterns helps you stay honest with users.
From the blogBuilding a collaborative asynchronous work environment stackoverflow.blog
Fully embracing a remote workplace means letting everyone work when they want to work.
From Web2 to Web3: How developers can upskill and build with blockchain stackoverflow.blog
Why web3 is here to stay and how developers can build killer dApps.
The next gen web browser has no tabs, only spaces (Ep. 549) stackoverflow.blog
Ben and Cassidy sit down with The Browser Company to talk about reimagining the web browser—and the way we use the internet.
Put your best work on display! promotion
Showcase your skills and build an online resume with .ME, the most personal domain name. Check if your FirstNameLastName + .ME combination is available and check out lots of developer-specific tips and resources for building your online presence.
Interesting questionsWhat is this famous example of the absurdity of English spelling? english.stackexchange.com
Further proof that English is three languages in a trench coat.
Gravity assist as energy source sustainability.stackexchange.com
What goes up must be able to charge your phone.
Told it’s “my responsibility” to find coverage for shifts scheduled during previously-approved vacation time workplace.stackexchange.com
In fact, it is your manager’s responsibility to find coverage for shifts during approved PTO.
Liability for releasing AI into the “wild”? law.stackexchange.com
No matter how smart it is, you’re still liable for malware you create. Just ask Miles Dyson.
Links from around the webBicycle – Bartosz Ciechanowski ciechanow.ski
We take for granted how bicycles “just work” when we ride them…and this is a great reminder of the cool physics behind them!
The ultimate guide to image optimisation calibreapp.com
When you start to think about web performance, most of the time, optimizing your images comes first and foremost!
Scientists created a new recyclable plastic not made from crude oil www.sciencealert.com
There’s a new plastic in town. Maybe this could help improve recycling!
Dark patterns in UX design—Which ones are the most deceptive? www.uxpin.com
As you build, you’ll want to stay away from the patterns that trick your users.
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #172: The path to async work appeared first on Stack Overflow Blog.
Marco Palladino, CTO and cofounder of Kong, joins Ryan to talk about the evolution of API protocols over time and why building the API is only half the battle.
Episode notes:
If you prefer, you can read this as a Q&A article or watch the video.
Kong is a cloud-native API platform. The first iteration of an API marketplace Marco and his colleagues built was Mashape.
Developments like GraphQL and gRPC have become critical as the number of APIs increases over time.
Find Marco on LinkedIn and Twitter.
TRANSCRIPT
The post Building an API is half the battle (Ep. 552) appeared first on Stack Overflow Blog.
SPONSORED BY RIPPLERight now, plenty of people are building businesses on social media platforms, on streaming platforms, and on market platforms that they don’t control. That platform can make the rules in any way they want and remove access at any time. That means founders are potentially one step away from losing their livelihood. The same goes for consumers buying from these platforms: if you lose access to your account, there goes all your purchases. As it turns out, you were licensing everything, not buying it.
On this sponsored episode of the podcast, we talk with Ripple CTO David Schwartz about the promise that decentralized trust and distributed consensus has for software development—and for more transparency in ownership.
Episode notes:
Cross-border payments, while they might not be the sexiest app, are one of the best product-market fits for blockchains.
Learn more about Ripple at their home page.
Get started learning about the XRP Ledger with their documentation.
Congrats to Lifeboat badge winner, asmeurer, for their answer to What does S signify in SymPy?
TRANSCRIPT
The post From cryptography to consensus: Q&A with CTO David Schwartz on building blockchain apps appeared first on Stack Overflow Blog.
Dean Tribble, CEO of Agoric, joins Ben and Ryan to talk about his journey from working on early programming languages at Xerox PARC to leading a company developing an open-source blockchain.
Episode NotesSmart contracts aren’t actually new. Computer scientist, legal scholar, and cryptographer Nick Szabo coined the term in 1994 (possibly earlier, depending on who you ask).
Old problems seem to keep coming back. Bret Victor gave a talk in 2013 called “The Future of Programming,” where he talked about problems from 1973 that were still relevant.
To learn more about the Agoric blockchain, check out their homepage.
If you’d rather shape how the blockchain itself operates, much of Agoric’s code is open source.
Connect with Dean on Twitter or Telegram
TRANSCRIPT
The post From Smalltalk to smart contracts, reflecting on 50 years of programming (Ep. 551) appeared first on Stack Overflow Blog.
Focus Groups. Surveys. Segmenting our customer data. Segmenting competitors’ customer data. Digging through people’s smartphone data.
The modern tech product company wants to be data driven—and they’ll do whatever they can to get their hands on that data.
Compare that to the approach that produced the unicorn companies of the late nineties: your eBays and your Amazons, for example. The archetypical founding story? Some guy—admittedly it’s usually some wealthy, well-connected guy, but some guy nonetheless—thought up a thing that he wanted for himself. It turned out that the world wanted it, too, to the tune of billions of dollars.
Why aren’t the unicorn companies of 2023 talking about how some dude in his garage wanted a thing for himself in 2013?
The answer derives from who built the internet of today, and who they built it for.
Innovation serves unmet needsAn innovative product breaks the market for existing solutions. And this is important: it usually doesn’t just serve a need better than other solutions serve it. Instead, it serves a need that other solutions don’t serve at all.
Let’s look at some examples.
eBay used reputational scores to connect buyers and sellers who did not know each other and have stuff actually get paid for and delivered—across time and space! Until the early internet, sales had to be colocated, and even after the internet they carried the risk of some faceless website stealing your money and never sending the thing you ordered. At the time, no mainstream solution did this.
Amazon added a logistical system that made ordering things over the internet not only reliable, but also relatively fast. No more waiting three weeks for John in Ohio to ship your CrazyTown album sticker via snail mail. To this day, for better or worse, Amazon offers a more streamlined, reliable online purchasing infrastructure for many products than even the sites of the shops that create the things they’re selling.
When Apple released the iPhone in 2007, no other phone offered the opportunity for different apps to have different input interfaces. Its introduction more or less broke the market for existing phones.
In the days of the early internet, unserved needs were easy to find: until then, commerce had to happen either in person or via snail mail and phonecalls. Quick, self-service, asynchronous options simply did not exist. The web made it possible for them to exist. It more or less dumped a whole vat of krill into the waters of commercial demand for companies to snap up without having to be that creative.
Now, those krill have largely been eaten. The easy wins have been won. Online commerce is a saturated business. The commercial web’s early garage founders built the things they wanted, and now the things that that demographic wants have been built.
Focus groups, surveys, segmented customer data, segmented competitor customer data, smartphone data—today’s product and marketing teams lean heavily on these resources to find the tiniest capillary opportunities for monetization within that demographic.
Innovation means, pragmatically, serving a heretofore unserved need. Those are hard to find among the people that the internet was built for. The problem lies in the fact that the product and marketing teams’ sources of data—people who do focus groups and fill out surveys from their smartphones, people who already use the product or a competitor’s product or a variety of smartphone apps—come from the people that the internet was built for. These people have few unserved needs online.
In search of the unserved needSo where can we find the unserved needs—the opportunities to innovate? It will sound too basic to be true when I say it: we have to talk to folks that don’t enjoy an internet built for them. We can’t find them among folks already well-represented in boardrooms, product teams, and pools of active customers. Instead, visionary products derive directly from centering people at the margins of modern technology.
That doesn’t sound like it would be a profitable strategy, does it? Our instinct on this tends to get hindered by two flawed assumptions.
Flawed Assumption #1: “Marginalized folks constitute a minority of our potential customers.”
This is just flatly incorrect in a lot of cases. Take a look at the difference in uptake by race for online money transfer companies CashApp and Venmo. These two companies do not differ in size by orders of magnitude. A Venmo employee might say of the company’s numbers “That’s just who wants/needs a money transfer app.” And they’d be, candidly, wrong.
Flawed Assumption #2: “Pursuing solutions in underserved populations will cost us demand from existing customers or larger demographics.”
This would be true if the needs of the two groups were mutually exclusive, but they’re often complementary. My favorite example of this is the same 2007 iPhone introduction I mentioned above. The star feature of that phone—the multi-touch capacitative screen that facilitates different interfaces for different apps—was not an Apple invention. Apple got that screen by acquiring FingerWorks, a small company founded by John Elias and Wayne Westerman to distribute a computer input device Westerman had designed to help his mother, who lost much of her fine motor function, to continue to do the activities she wanted to do on her computer. Indeed, you’d be floored by the number of your favorite technological features that started as accessibility features for people with disabilities.
Now, reams have been written about how to get marginalized people into the room on product decisions. Tech companies individually tend to experience intermittent hiccups of trying really hard on that, but as an industry as a whole, the situation ain’t great. No number of DEI trainings seems to manage to keep a diverse team. And I maintain that the reason for this is that, as not-racist, not-sexist, or not-ableist as individuals want to be, we run into two things:
- There is so much to learn about so many axes of marginalization, that a single corporate training could not possibly completely inform and educate about all of them.
- An equitable environment that welcomes diversity requires its members to have a complement of skills, but most training on the matter focuses on values or demographic groups rather than skills, leaving folks unequipped to uncover and examine unserved and underserved needs that technology could address.
Teams can facilitate an inclusive environment and increase their capacity to sniff out unserved needs by explicitly practicing that complement of skills in their work. Some of these get touched on in DEI trainings, but they form the foundation of creating a team where everyone experiences positive changes in their opportunity to contribute. I have written before about building an employee evaluation rubric for what I see as the critical five:
1. ModerationThis is the skill of giving folks in a meeting the opportunity to listen by protecting their opportunities to speak. Without this, teams run into all kinds of icky demographic patterns governing who gets to talk in meetings, and it’s often not the people with the most thought-out ideas. That’s why moderation is such a critical skill—especially for leadership of an innovative team. You need people’s ideas, and that requires the skill of uncovering them in groups.
- Soliciting opinionsThere’s also skill associated with uncovering ideas individually, and identifying who to ask for those ideas. It includes thinking specifically about who will be affected by a decision, and seeking them out for input. It also includes identifying which perspectives would disagree with those making the decision, and explicitly soliciting those objections to avoid running into obstacles later on that could have been predicted.
3. AttributionThis often feels like a small skill, but it has a huge impact. It’s common in tech for folks to misattribute ideas, forget where they heard them, or fail to recall who taught them something they know. In the aggregate, this makes folks less likely to share their ideas out of concern that they’ll lose credit for them. It’s especially true among underrepresented groups, but it can happen to anyone. A team that cares about attribution, and practices making it regularly, facilitates earlier and more open idea sharing.
4. Most advanced assumptionIt’s easy to accidentally condescend to others in the workplace and give the impression that we think other people are less capable than we are. We want to share what we know, and sometimes the unintentional result of that is that we lecture someone who knows more than we do. This makes folks feel like we don’t respect their valuable expertise. And if we don’t respect it, why should they share it?
This is another one that feels small but makes an outsize impact. It’s also tricky to broach a topic when we don’t know the level of expertise of others in the conversation. But we can learn to ask questions about that. We can also learn to share knowledge with explicit consent to be stopped if an interlocutor already knows, or if we assume too much knowledge and they have questions.
- Capitalizing on alternative perspectivesWe’re a conflict-avoidant culture: we’ll go to great lengths to skirt disagreement. But disagreement often signals and precedes conversations that result in more complete solutions that better serve unserved needs. Developing a more positive attitude about disagreement requires tools for navigating it more comfortably and with more grace for each other. And that, like the other four items discussed above, is a skill that can be taught, learned, and practiced.
Those skills all have a lot of nuance in them, and I have not explained exactly where to get it. I’m working on an online, self-paced workshop with exercises in it to help technologists like you create and lead teams that can, in fact, innovate. You can pre-order that course right here (and, if you want proof of my teaching chops, this course on tech debt is already up and available).
But the takeaway here revolves around where innovation comes from. We can employ skills—individual, interpersonal skills—to create the kind of environment that makes innovation possible, even in a tech sector that often looks bleakly saturated. There’s hope for us, hope for our teams, and hope for our industry if we can learn to execute on our curiosity about the unmet needs we can build for.
The post “Data driven” decisions aren’t innovative decisions appeared first on Stack Overflow Blog.
So far, the current wave of tech layoffs has directly affected more than 153,000 people in 2023. But it’s had a disproportionate impact on women, people of color, and people in the United States on H1-B visas. Overall, these layoffs are a body blow to diversity in tech, not just slowing but actually reversing hard-won gains.
Of those who lost their jobs in the most recent round of layoffs, 45% were women—which doesn’t sound bad until you remember that less than a third of tech industry roles and less than a quarter of tech leadership roles are filled by women. Other underrepresented groups, especially Black tech workers, have also been impacted at outsize rates. And the layoffs have revealed cracks in an immigration system that hasn’t been overhauled since LISTSERV was born.
Women and people of color are more likely to have jobs perceived as expendableWomen and people of color aren’t being laid off at higher rates because we were dead-weight DEI hires in the first place. According to Sarah Kaplan, director of the University of Toronto’s Institute for Gender and the Economy, it’s because “the roles that historically underrepresented groups are hired into tend to be seen as the most expendable.”.
This includes less technical roles and ones perceived as less prestigious or farther from the product—like field and customer support, human resources, communications, and marketing. “Overall, definitely nontechnical roles are more affected, women are more affected,” Reyhan Ayas, a senior economist at Revelio Labs, told The Washington Post.
The rise of remote work during the pandemic allowed more women and people of color to enter the tech workforce because remote work made barriers like childcare and unaffordable housing within commuting distance of the office easier to overcome. At Meta, for instance, US hires for remote roles in 2022 were more likely to be people of color, while global hires were more likely to be women. But when companies make cuts, remote workers may be more likely to lose their jobs—they certainly feel more anxious about it, according to Harvard Business Review. Since companies often follow the “last in, first out” rule when determining which jobs to cut, recently hired remote workers—more likely to be women and people of color—are often the first to be laid off.
The reasons why roles seen as less technical and/or less prestigious tend to be stacked with representatives of underrepresented groups are manifold and complex, including structural barriers like historical access to education and economic resources, geographic location, social conditioning in school, and cultural and familial expectations. But the result is that industry-wide layoffs fall disproportionately on people who are already underrepresented in tech.
Our immigration system is failing H-1B visa holdersFor foreign-born tech employees in the US on H1-B visas, a layoff isn’t just a job loss: it can uproot their entire lives, and their families’ lives. The H-1B visa program allows people with specialized skills who are sponsored by an employer to come to the US to live and work. H1-B visa holders can stay in the US for no longer than six years unless an employer sponsors their permanent residency (their green card).
The number of H-1B visas awarded is capped at 85,000, and big tech companies account for a hefty percentage of these, with nearly 70% of the visas going to people in “computer-related” roles. Because only a limited number of employment-based residency applications can be granted every year, people can wait decades for a green card, tying H1-B visa holders to the same employer for years and making them especially vulnerable in the event of layoffs.
When someone on an H1-B visa is laid off, they have 60 days to secure sponsorship with another employer or leave the country. “These visa holders have built lives here for years, they have a home, and children, and personal and professional networks that extend for years,” Linda Moore, president and CEO of TechNet, told WIRED. When the companies responsible for sponsoring most H1-B visas are the same companies laying off workers, the system fails the workers (and the companies) it exists to serve.
Part of the problem is we’re using a legacy system from the 80s. The H1-B system hasn’t changed substantially in more than 35 years, writes Anna Kramer for WIRED, but in those decades, the US has become a dominant presence in science and technology, a rise fueled in large part by foreign-born talent. The immigration system hasn’t evolved along with the reality of the industry, and that creates problems—not just for individuals, but for companies and the industry as a whole.
“Tech companies have invested decades and millions of dollars into lobbying for kinder rules and an increase in the number of visas available, and in sponsoring hundreds of thousands of workers,” writes Elliott. “Yet the process remains unchanged, and layoffs mean some skilled workers that companies may want to hire from competitors either now or in future will instead leave the country.” And that’s our loss.
A problem for everyoneThe erosion of diversity in tech is a problem for everyone, not just individual members of underrepresented groups. “If you don’t have a diverse workforce, you’re going to get technologies that exacerbate inequalities in our society,” Kaplan told Fast Company, referring to technologies like AI-powered facial recognition or credit score assessment. “We should care that the tech sector is not diverse, because it’s creating technologies that shape our lives.”
The post The people most affected by the tech layoffs appeared first on Stack Overflow Blog.
Welcome to ISSUE #171 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week, the many ways to build SRE into an engineering org, the velocity needed for death by pineapple, and the mirror that reverses time.
From the blogWhat’s different about these layoffs stackoverflow.blog
As the discouraging news continues, we revisit how our core community of developers has been experiencing the layoffs—and explore what sets this economic situation apart from previous dips and busts.
Who builds it and who runs it? SRE team topologies stackoverflow.blog
Ad-hoc SRE principles can get you on the right track, but if you want to sustain it long-term, you’ll need organizational structure.
Your tech toolbox: The middle ground between tech chaos and rigidity stackoverflow.blog
Do you solve new problems the same way because it’s already done? Or do you go with a new approach that offers more benefits?
Moving up a level of abstraction with serverless on MongoDB Atlas and AWS stackoverflow.blog
Storage isn’t where you’ll run up costs; spending engineer time on sorting out low-level issues is.
What our engineers learned building Stack Overflow (Ep. 547) stackoverflow.blog
Charles “Cobih” Obih and Radek Markiewicz of the Stack Overflow platform team join Ben and Ryan to talk about changes to the inbox and what it’s like to build Stack Overflow’s public platform.
Claim your FREE .app or .dev domain from Porkbun promotion
Porkbun is a refreshingly different domain name registrar offering an oddly satisfying experience. If you’re a developer or designer, get your FREE .app and .dev. domain. This offer is an ideal home for your next project. Claim your free domain today!
Interesting questionsHow fast does a pineapple need to fly to kill? worldbuilding.stackexchange.com
“I came here to chew bubblegum and shoot pineapples and I’m all out of bubblegum.”
Is it logical to seek revenge? philosophy.stackexchange.com
Imagine if a Vulcan and a Klingon had a baby, then asked a question on Stack Exchange.
How to protect the code from being ‘rephrased’ by AI to avoid license limitations? opensource.stackexchange.com
Until the courts say otherwise, machine translation of a copyrighted work is still translation.
Computer is frying all USB devices that are connected superuser.com
Officer! Arrest that computer! It’s a murderer!
Links from around the webLessons from linguistics: i18n best practices for front-end developers shopify.engineering
Internationalization matters, and linguistics can help you do it right.
10 years of Electron www.electronjs.org
Electron celebrated its 10th anniversary this month! Have you built anything with it?
Command-line fu www.commandlinefu.com
Sometimes you just come back over and over again to the same handy command-line tools. Here’s an awesome resource of thousands of them!
This mirror reverses how light travels in time spectrum.ieee.org
Physics is dang cool, and this project reflects that (get it?).
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #171: The tech toolbox appeared first on Stack Overflow Blog.
A Principal Engineer at GitHib, Kris is president of the Nivenly Foundation and an admin at Hachyderm, an instance of the decentralized social network powered by Mastodon.
The ongoing changes at Twitter have fueled interest in alternative, decentralized platforms like Mastodon and Discord.
Read Leaving the Basement, Kris’s post about scaling and migrating Hachyderm out of her basement.
Watch Kris’s conversation with DigitalOcean Chief Product Officer Gabe Monroy about building decentralized IT platforms.
Find Kris on Twitter, GitHub, Twitch, or YouTube.
Congrats to Lifeboat badge winner metakeule for answering: How can I get an error message in a string in Go?
TRANSCRIPT
The post How to keep the servers running when your Mastodon goes viral appeared first on Stack Overflow Blog.
Coming off the heels of 2022, it may be difficult to assess where web3 technologies stand in 2023. Bitcoin rose to $47,000 and fell to $16,000. NFT trading volumes peaked at $17B in January 2022 and a year later collapsed to a mere $143M. “Blockchain” and “digital currencies” became everyday terms in the mainstream media. We saw the collapse of FTX and all its cascading consequences.
It was a tumultuous year in the world of web3—full of speculation, crashes, and scandals. But does this mean that web3 is dead and the underlying technologies made obsolete? Hardly.
Though mainstream enthusiasm for NFTs and cryptocurrency has ebbed and flowed, the community is still very much alive and actively invested in not just the technology, but in ensuring the promises of a decentralized internet are realized. The world at large is frustrated with the data collection practices of the tech industry heavyweights. The global reach of eCommerce needs trustworthy payment systems that can operate worldwide. While much of the discussion around NFT collectibles focused on high profile acquisitions and losses, NFTs themselves have only scratched the surface of what’s possible.
Web3 is here to stayWe are still in the early days of blockchain. Keep in mind that we’ve been using the term “web 2.0” since 1999 (24 years ago!) but blockchain quietly entered the market as an underpinning technology for Bitcoin in 2008 (15 years ago). That difference of nine years may sound small, but consider that nine years ago most large companies were just starting to move to the cloud.
Today, blockchain technologies power much more than basic cryptocurrency transactions. Banking and finance applications support cross-border payments that settle in seconds, not days. Multi- and cross-chain transactions via DeFi applications allow for increased crypto liquidity and improved exchanges with fiat currencies. Blockchain developers can build their own customized sidechains (more on those later) to support integration with real-time, low-cost transactions in video games and other use cases. SDKs are available in nearly every popular language, making it easy for today’s web2 developers to take their existing coding capabilities and embrace decentralized technology.
Emerging applications of blockchain and crypto include:
- Cross-border payments
- Real-time tracking of goods in supply chain and logistics
- Electronic health record storage
- Energy supply transaction tracking, including renewable energy certificates
- Citizenship and credential tracking across borders
- Documenting legal agreements, such as real estate and carbon credits
Despite everything that’s been reported in the news about crypto and blockchain this past year, their potential is still largely untapped. Blockchain advances are bringing economic and technical utility to both users and developers. It’s an emerging technology with no single app to rule them all. There’s still opportunity for the next iPhone-level disruption.
The tech behind the headlinesThe technology comprising a blockchain is rather sophisticated. In the most simplistic sense, a blockchain is a database: it stores data in an ordered fashion. However, a blockchain doesn’t act as a simple database with all data on a single server, but rather as a distributed ledger: multiple computers across the world store redundant copies of all the data in the blockchain and share the work of confirming transactions, without needing a central authority or intermediary.
In a blockchain, each node has a copy of the blockchain ledger and participates in the transaction validation process. New transactions are broadcast to the network, and nodes work together to verify the transaction data and add it to the blockchain. This process is known as consensus, and it ensures that all nodes on the network agree on the state of the blockchain and that it remains secure and tamper-proof.
While some blockchains are centralized and managed by a single organization, most are open source and decentralized, meaning they are managed and maintained by a community of developers. For example, the XRP Ledger is a public, permissionless blockchain, meaning anyone on the internet can set up a validator and join the network. The reference implementation of the protocol is open source and any developer can propose amendments to this software. Because of the XRP Ledger’s decentralized nature, no singular authority can make decisions for the network. Instead, network changes are determined by a specific subset of validators, who vote on behalf of the XRP Ledger’s best interest. That being said, in order for amendments to pass, at least 80% of the validator community has to vote “yes” and that minimum threshold must be maintained for at least two weeks. If both of those conditions are met, then amendment proposals can be passed.
Consensus protocols run cryptographic functions to ensure the integrity of the network and its ledger. These usually include:
- Hash functions: Create a unique digital fingerprint of each transaction on the blockchain. They are one-way functions that take an input (e.g. a transaction) and produce a fixed-length, unique output based on that input (SHA-256 is an example of a hash function). Hash functions ensure the integrity of data because any error in transmission or other change results in a totally different hash value. If you get the same output from the hash function, you know you have the same input data.
- Public-key cryptography: Used for enabling secure communication between nodes on the network. Each node on the blockchain has a public key and a private key. The public key can be shared with anyone, while the private key is kept secret. Digital signatures are for ensuring the authenticity and integrity of transactions on the blockchain. Each transaction on the blockchain is signed using the sender’s private key, which creates a digital signature that can be verified using the sender’s public key.
Validator nodes execute the consensus protocol and can often run on commodity hardware (depending on the energy and computation requirements for the specific blockchain). Different blockchains use different consensus protocols to compute the final state of a transaction on the ledger.
Because the XRP Ledger is open source, anyone can learn how it works, contribute to the code base, and report issues. Or they can simply write and consume apps; mint, manage and otherwise interact with NFTs; and much more.
Consensus algorithms, energy consumption, and transaction timesThe two most popular consensus algorithms have long been Proof of Work (PoW) and Proof of Stake (PoS).
In PoW algorithms, every node on the network competes to solve cryptography problems in order to validate a transaction. That’s fine for small networks of a few dozen computers, but multiply this computational cost over 100,000+ nodes and it adds up very quickly. This is compounded by the fact that the fastest nodes to validate transactions often receive financial rewards, hence a competitive arms race to deploy thousands of powerful, electricity-hungry GPUs to solve these cryptographic puzzles faster than other nodes in the network.
PoW methods are what led China to ban cryptocurrency mining altogether, the White House to issue a press release about energy concerns, and the Ethereum community to push for and switch to the more energy-efficient PoS methodology in 2022.
In PoS algorithms, instead of solving a cryptographic puzzle on every node, nodes that hold a larger stake in the network (i.e. the greater the number of tokens, the greater the stake in the blockchain) are the ones to validate transactions. They still perform a cryptographic validation process, but it’s only a fraction of the nodes on the network with the biggest stake. The algorithms are no less complex and the validation mechanisms are similar to PoW, which is why PoS transactions can also take minutes or hours to be validated.
Ethereum moved to PoS “because it is more secure, less energy-intensive, and better for implementing new scaling solutions compared to the previous proof-of-work architecture.” It was a tremendous shift in how that chain operated and resulted in more than 99.9% reduction in electricity consumption. So tremendous, in fact, that they termed it The Merge. According to CoinTelegraph, Ethereum on PoW was using 112 TWh per year and on PoS is now using 0.01 TWh per year. For reference, Bitcoin is still using tremendous energy—more than many countries on earth.
There are many alternatives to PoS and PoW algorithms, with various tradeoffs to speed, centralization, and efficiency. Chains such as the XRP Ledger and Stellar use “federated consensus” or “proof of association” algorithms where a subset of nodes collectively build and agree on the next block of transactions. Other chains, such as Ignite, use hybrid systems that combine elements of federation and PoS. These systems are far more efficient than PoW and faster than both PoW and PoS because they eschew the wasteful work of competing to solve cryptographic puzzles. For example, transactions on the XRPL take 3-5 seconds to be validated, rather than minutes or hours.
Additionally, both PoW and PoS typically let the winning validator build a block however they like—which leads to miners and validators gaming the system to get the maximum extractable value (MEV) from each block. Federated consensus algorithms are typically less susceptible to these problems because they always arrange each block of transactions in a canonical order.
Making developers’ lives easier with abstractions, dApps, and smart contractsWeb2 brought us rich application experiences, cloud computing, asynchronous communication, and plenty of centralization. It’s practically impossible to develop a web2 app without paying corporations and being subject to their privacy policies, terms and conditions, and fiduciary responsibility. Web3 gives developers the ability to write and run apps that are fully-independent, widely-available, and decentralized. No limits and no corporate dependencies.
To make this a reality, most major blockchains are working hard to attract and onboard developers to their platforms with easy-to-use SDKs and high-quality documentation (e.g. Solana, Cardano, XRPL). Open-source blockchains are widely available and provide fertile ground for innovation. Each has built-in support for financial transactions using their native tokens (e.g. SOL, ADA, XRP), ensuring that people can pay and be paid.
Many chains support the development of dApps—decentralized applications. They can be written in a variety of programming languages, depending on what the chains support. Generally speaking, the larger the developer community of a given chain, the more languages it supports. For example, Ethereum supports .NET, Go, Java, JavaScript, Python, Ruby, Rust, Dart, and Delphi. The XRPL supports Python, JavaScript/TypeScript, C++, Java, React.js and Ruby.
Some blockchain apps are backed by or written as smart contracts. Smart contracts are tamper-proof, immutable pieces of code that live on the blockchain and facilitate interactions or agreements between the app, the user, and the chain. Blockchains offer simple abstractions and SDKs so developers can get up and running quickly with app development. For example, Ethereum offers a variety of application development tools to help people experiment, build front ends, and test their dApps and smart contract implementations. The downside to smart contracts is that, since they’re immutable and shared online, if anyone finds a bug in the contract’s code, they can exploit it to their advantage, and the developer can’t easily patch the vulnerability away. This makes developing smart contracts a delicate task with higher stakes than many other projects.
The XRP Ledger supports programmability through a number of protocols and standards. It includes native transactors that provide out-of-the-box functions which are already battle-tested and standardized. The Hooks proposal would further extend programmability on the Ledger. Hooks are small, efficient pieces of code that allow for the quick and easy execution of logic before and after a transaction — all native to the Ledger. This is important because standard smart contracts can be complex and difficult to navigate, especially for developers that are new to web3.
Unlike other protocols, the XRPL also has native support for NFTs, which means developers don’t need to build or maintain a smart contract in order to bring their NFT projects to life. This lowers the barrier to entry for developers, creators, and anyone else who wants to interact with NFTs on the XRPL. Additionally, automatic royalties are enforced at the protocol level which helps ensure maximum value for creators and developers. Core operations such as minting and burning are native to the Ledger to promote ease-of-use regardless of experience level.
An upcoming amendment, XLS-30d, proposes a native Automated Market Maker (AMM) on the XRPL. The proposal will include bid and vote features, allow for simple token swaps, and should create deep liquidity between token and currency pairs. The AMM’s functionality allows application developers to create interfaces for traders and liquidity providers (LPs) and introduces a novel auction mechanism that incentivizes arbitrageurs while reducing the impact of impermanent loss faced by LPs.
Developers make the chain better—for everyoneThe XRPL community is also currently testing sidechains. Sidechains allow developers to build and experiment with customized features in a sandbox-like environment—connected to, yet distinct from the mainnet—enabling innovation without disrupting or compromising the mainnet. Sidechain features could eventually be proposed as amendments and be merged into mainnet if voted on by the community. There is also ongoing development and testing of an Ethereum Virtual Machine (EVM) sidechain to bring Ethereum’s native Solidity-based smart contracts to the XRPL ecosystem.
As developers do more work on blockchains, we’ll inevitably see improvements in utility, security, scalability, cost and sustainability. The more adoption, the greater the improvements, and the greater the likelihood that more developers (and users) will further adopt this technology. The network effect and a fast-growing list of innovative features are already appealing to developers who want to move on from web2 conventions.
How developers can upskill and start buildingThe innovations underpinned by blockchain and advantages over web2 are getting hard to ignore. Web3 protocols are making it easier than ever to build on decentralized technologies. Web3 tech isn’t just “an upgrade” or “a step up” from web2—it’s a whole new paradigm of working on applications. They’re decentralized, permissionless, scalable, and stable. Developers can use what they already know and upskill to web3 technologies. For once, they can have skin in the game with full ownership of their assets and intellectual property. Using the programming languages they already know, they can increase their domain expertise and take advantage of decentralization.
When choosing a chain to start on, developers should consider:
- Adoption: Do you want to build on a prime-time chain with lots of users, an up-and-coming chain with a growing user base, or get in early on something brand new?
- Ease of development: Is there sufficient documentation, fully-featured and supported SDKs, an ecosystem of existing dApps to explore, and low-friction onboarding?
- Ledger functionality and transaction time: How does consensus work? Is it efficient and quick?
- Environmental impact: Are energy consumption and sustainability priorities for the blockchain?
- Time to first dApp: How long does it take to build an app? Minutes? Hours? Weeks?
- Community: Is there a living, vibrant user and developer base? Are they passionate about the chain, its growth, and web3?
Blockchain and crypto have the power to enable a better future, and there is a vibrant community of developers that are building, testing and iterating on top of the technology to help uncover future use cases and applications. Ripple is just one contributor among many to the XRP Ledger; as members of this developer community we are deeply committed to helping it grow and thrive.
There are a number of programs like grants and bounties to help developers of all levels get started with the funding and resources they need to bring their web3 projects and applications to life. The XRP Ledger also recently launched an online learning portal where developers can learn more about the basics of crypto and blockchain, or dive straight into coding on the XRPL with courses in languages such as React.js (currently in beta).
For additional information or to join the community, check out the developer Discord, view open source code and repos on GitHub, and follow @RippleXDev on Twitter where we regularly share updates, projects, new features, and fixes from the XRPL community.
The post From Web2 to Web3: How developers can upskill and build with blockchain appeared first on Stack Overflow Blog.
Ben and Cassidy sit down with The Browser Company to talk about reimagining the web browser—and the way we use the internet. Plus: The best username out there (don’t @ us).
Episode notes:
Today’s guests from The Browser Company are software engineer Victoria Kirst and design lead Dustin Senos.
The Browser Company is building a new kind of browser designed to keep users “focused, organized and in control.” Arc, their browser, is “full of big new ideas about how we should interact with the web” and has been called “the best web browser to come out in the last decade.”
For an introduction to and first look at Arc, start with this video. You can also join the waiting list or subscribe to the Substack.
Follow The Browser Company on Twitter.
Connect with Victoria on LinkedIn or Twitter.
Connect with Dustin on LinkedIn or Twitter.
Special thanks to Ellis Hamburger, owner of the best username, for facilitating this terrific conversation with Victoria and Dustin.
Congrats to Lifeboat badge winner Todd for answering How can I name a @Service with multiple names in Spring?.
TRANSCRIPT
The post The next gen web browser has no tabs, only spaces (Ep. 549) appeared first on Stack Overflow Blog.
“Quick question for you…”
Is there anything more annoying to hear when you’re elbows deep in a hairy bug?
When I was working as a software engineer a few years ago, I remember putting on headphones with no music, just to keep people in the office from disturbing me when I really needed to focus. It’s frustrating, and disruptions waste a lot of time. Gloria Mark, a professor of informatics at the University of California, Irvine points out that it can take over 20 minutes to get back into a complex problem after being jolted out by a distraction.
While remote work might make it easier to carve out focus time, it depends entirely on the company. Some still expect software engineers to be ready to respond to chat or email messages at any moment, and those who are slow may suffer professionally for it. Others bring developers into so many meetings that they rarely have an hour away from video calls to get any deep work done.
So when I started my own business a couple of years ago, I decided we would do things a bit differently. I wanted to build a company that allowed me to have time for deep work, time to take walking breaks in the middle of the day, and time to pick up my son from school. Even more, I wanted to create a work environment that gave my employees the same privilege.
The working model we developed is a form of asynchronous remote work. In an asynchronous environment, all or most of the work is done at the employees’ preferred working time. Employees use asynchronous work tools to communicate, and there are typically very few real-time meetings.
Draft.dev remains almost completely asynchronous, even as our team has grown to over 12 full-time people and 300 technical writers. We don’t use real-time chat tools, and by letting people work in their own timezones, we are able to hire employees and contractors in over 50 countries around the world.
I’m not alone in embracing asynchronous work though. There is a growing trend in companies of all sizes to adopt this style of work because of the productivity, lifestyle, and hiring benefits it affords.
For this piece, I interviewed several founders and leaders of asynchronous-first companies. You’ll hear more about why they adopted this work style, what they’ve learned about making it effective, the tools they use, and some of the challenges that arise in asynchronous work environments. Whether you’re looking for a job and curious about what it might be like to work at an asynchronous company, or you’re a leader who is considering rolling this out with your team, there will be some good takeaways here.
Why asynchronous work?Initially, my reason for making Draft.dev asynchronous was personal. My partner and I had recently had our first child and with daycares closed during Covid, I needed to be home to watch him most days. I would try to schedule sales calls during his naps or in the evenings and spend most of the day watching him, responding to emails when I had little gaps of time.
As I started hiring more people though, I realized there were other benefits to being all remote and mostly asynchronous.
Productivity time“The original reason we went asynchronous was the timezone distribution and the need to respect each individual’s productive time,” Sameera Perera, a manager at CloudExtend told me. He pointed out that his company of 44 is located around the world and some are night owls, while others are early risers. They have a few real-time meetings per week, but 90% of their workday is done asynchronously.
My team’s experience has been similar. While we have some roles that need to be available for meetings with clients, most of our team spends their day focused on deep work like writing, editing, or coding.
I’ve also found that in some regions of the world, it’s almost impossible to work at certain times of the day. For example, rolling blackouts in South Africa often force our team members there to move their workdays based on when they have power.
Access the global talent poolProbably the most common reason technology companies move to asynchronous work is that it gives them access to the growing global talent pool. This was certainly a factor for me when I started Draft.dev. We grew from 0 to 80 clients in just two years, so I couldn’t find enough software engineers in the United States to write the volume of content we needed.
Rishabh Kaul, Head of Marketing at Appsmith, had a similar experience as they had to hire quickly too. “After the first five employees, we decided to hire globally to access a broader talent pool,” he told me. “We have users from 140+ countries, with the top six all being from different time zones,” he said, adding that by hiring globally, they have support employees ready nearly 24/7.
Improve documentation and collaborationA less obvious benefit to working asynchronously is having a record of almost every conversation that happens in the company. While private email or chat threads aren’t ideal for documenting decisions, there are a few purpose-built tools I’ll discuss later for building documentation or training material from past discussions.
“We end up documenting or having a trail for all discussions,” Rishabh Kaul told me, “which makes it easier for people to help themselves.”
“We encourage documentation and regular updates in a public forum like Slack or Notion,” Ronak Ganatra, Marketing Director at Lano added, saying that they “try to minimize ‘important’ projects being kicked off in 1-on-1s,” because they don’t want any details to get lost.
A common objection to asynchronous work is that collaboration is harder, but Brian Casel, CEO of ZipMessage said that he sees the opposite.
“We actually collaborate much better because we are async,” told me, pointing out that everyone gets time to think about and organize their thoughts before they speak or write. “All messages are logged,” he told me, “so it’s really easy for us to link back to something someone said.”
You might forget what someone said in a video call three months ago, but if you can go back through your message history, you can avoid losing important organizational knowledge.
Increase team autonomyOne of the benefits my team talks about most often is the high level of flexibility and autonomy they get thanks to our asynchronous environment. Employees are able to work around their lives, but also in the way they work best.
“People are happier when they have flexibility, and when they are happier they are more productive,” Kiran Shahbaz, founder of GrowWell Ventures and Goodwork told me. “Our team really values the freedom and autonomy that remote and async work provides.”
As a manger, having an asynchronous team means that I really can’t rely on metrics like hours worked. Whenever possible, I try to use output-based metrics, which encourage team members to get more efficient at their jobs rather than maintain the status quo.
How to make asynchronous workOne thing that I find challenging about asynchronous work as my company grows is that I can’t get answers to all my questions immediately. I know that’s probably a good thing (because I’m not constantly interrupting my teammates), but it’s required an adjustment to my expectations around work and forced me to get better about processes.
In addition to the mindset shift required, there are a few other things you’ll need to do to go async:
Strengthen your writing skills“[We ask everyone to] have everything posted on public channels to increase transparency,” Rishabh Kaul told me, adding that this means they often have to “train people to emphasize the written word.”
Brian Knoles of Bellawatt’s advice was similar. “Writing is more time consuming than speaking,” he said, “but it also helps to clarify thinking in a different way. We’ve all had an ‘aha!’ moment while typing up something we were confused about.”
I’ve always thought that writing was an incredibly important skill for software developers, and Harvard neuroscientist, Juliette Han says the same is true for everyone:
“The most underrated skill that successful people, especially introverts, have is the ability to write clearly. It doesn’t matter what industry you’re in. If you are a thoughtful and strategic writer, you’ll be more confident in your interactions—in emails, public speaking or even just small talk.”
So whether your company is asynchronous or not, it’s worth investing time to become a better writer, but if you join an async company, this is doubly true.
Build processes and documentationAs writing becomes more ingrained in your daily life at an asynchronous company, it’s only natural that some of that writing will turn its way into documentation. “We document everything that is done more than once,” Kiran Shahbaz told me. “Because we don’t have the luxury of ad-hoc questions and answers, these need to be prepared beforehand.”
Of course, not all documentation is written. “We record a lot of calls,” Rishabh Kaul said, “Many meetings are recorded, especially meetings that have more than two or three people.” These recordings then serve as a library of context for people who couldn’t make the meeting and want to review it afterwards.
Finally, we’ve found that automated processes also really help our team at Draft.dev. Using tools like Zapier and Airtable, we’ve been able to automate many of our internal communications, allowing our teams to work more efficiently at their own time.
Choose the right toolsWhile there are a handful of tools that just about every office worker is familiar with (Zoom, Slack, Google Docs, etc.), there are some tools that work especially well for asynchronous teams.
For example, Stack Overflow for Teams offers a collaborative place for teams to ask and answer questions without interrupting each other in real-time chat platforms. Similarly, Twist is organized around threads and works more like a traditional forum than a real-time chat tool.
My team uses a daily standup tool called Status Hero to record what we’re working on each day without all having to hop on a call in real-time. Other teams I spoke to use tools like Metro Retro to capture and share their agile retrospective notes both synchronously and asynchronously.
Finally, I’ve gotten to be a big fan of leaving async video messages through ZipMessage. While real-time calls are useful for collaborating quickly, a lot of meetings could be replaced by video messages.
The challenges asynchronous work introducesWhile I think a highly asynchronous environment can work for the right type of team and business, it introduces its own set of challenges. Having tools and metrics will help you, but ultimately, it’s not the right work environment for every company in every kind of business.
Trust is keyFirst, if employees are allowed to work when, where, and how they want, you have to be able to trust them. “Async only works with 100% reliable team members,” Kiran Shahbaz told me. Ronak Ganatra agreed, adding that everyone must be “accountable and independent.”
That last part can be tough for some managers to accept. I have worked for a few managers who didn’t believe people working from home were “really working,” and async won’t work in a low-trust environment.
For me, the key is having good work and result-tracking measures in place. For some roles, employees log and report their hours weekly, while other roles are paid on an output basis. This allows managers to compare performance objectively, even if they’re not able to meet with each employee face-to-face every day.
Hiring employees who are used to working asynchronously also helps. I look for people who have worked remotely and independently in the past. For example, a lot of freelancers tend to succeed in an asynchronous environment because they know how to motivate themselves and stay focused without a boss looming over their shoulders.
But employees have to be able to trust each other too. “Team members should remember that asynchronous means someone might not be available when you want them to be,” Anthony Eden of DNSimple told me. “Team members must accept and respect their fellow team members’ schedules and work habits.”
If you can’t trust your fellow team members or your employees, then asynchronous work is not going to be a good fit.
The mindset shift
“Regular sharing is a habit that takes time to build.” – Anthony Eden, DNSimple
Almost every new employee we hire goes through a period of time where they’re still trying to wrap their head around this asynchronous work thing. For example, we use Trello for project management, so if someone has an idea for a new project, our company’s best practice is to add it to the correct backlog and tag anyone you’d like to review it for you.
But it usually takes new employees three to four months to remember that this is how they’re supposed to do it, so I find myself stopping long email threads with a reminder to move the discussion to the proper forum.
Some people struggle to get into a consistent work routine. One of our core values is that “we work at a sustainable pace,” so I often have to remind team members not to put in extra time on the weekends or evenings unless that’s when they prefer to work. Just because work is always available doesn’t mean you have to be constantly plugged into it.
Real-time tasks and rolesFinally, some tasks and roles are simply not suited to asynchronous work. Everyone I talked to for this mentioned how challenging brainstorming in an asynchronous workplace is. Many of them use real-time meetings for that work and regular team check-ins that require more back-and-forth at a quicker pace.
Our account management and sales teams are also much more synchronous than our production team due to the nature of their work. Clients expect availability in their timezones, and responding to a client question quickly can often build a lot of trust. While we encourage these teams to set boundaries, we also want to serve our clients the best we can.
The key thing is to be honest with new hires about the amount of real-time vs. asynchronous time their role entails. Most people will understand as long as you’re open about it.
ConclusionFor technology workers, remote work is becoming the norm, but asynchronous workplaces are still relatively rare. This working style requires total buy-in across the company and a high degree of trust between employees and managers, so it may never become the standard. That said, it has advantages, especially for engineers, writers, and other knowledge workers who need to spend a lot of time in deep work.
What do you think? Have you ever worked in an asynchronous environment? Did you like it or not? Find me on Twitter to continue the conversation.
The post Building a collaborative asynchronous work environment appeared first on Stack Overflow Blog.
Welcome to ISSUE #170 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week, find out what happens after you build your API, discover the effects of bubbles in your booze, and reminisce about the less-than-perfect first versions of today’s most popular sites.
From the blogCan Stack Overflow save the day? stackoverflow.blog
Tell us how Stack Overflow helped you and enter to win a limited edition key cap!
Building an API is half the battle: Q&A with Marco Palladino from Kong stackoverflow.blog
API gateways, service mesh, and GraphQL, oh my!
Visible APIs get reused, not reinvented stackoverflow.blog
How open API specifications can help developers—and computers—understand your APIs.
Developers think AI assistants will be everywhere, but aren’t sure how to feel about it stackoverflow.blog
The things we expect to succeed aren’t always the things we’re hoping to see more of.
Need help scaling your company growth? promotion
For startups and small to medium-sized businesses (SMBs) working to expand their customer base, revenue, and standing in their industries, adopting a DevSecOps platform is one move that can help make all of that growth happen.
Interesting questionsDid mechanical hard drives often malfunction in high-elevation places such as Bogota? retrocomputing.stackexchange.com
It depends on whether the hard drive had helium in it or not.
How are the banks behind high yield savings accounts able to pay such high rates? money.stackexchange.com
Maybe they lose money on every account, but make up for it in volume!
What are the benefits of tracking solved bugs? softwareengineering.stackexchange.com
Those who forget history are doomed to reintroduce bugs in prod.
What happens if you carbonate ethanol? chemistry.stackexchange.com
Who wants a round of burptinis?
Links from around the webFrom gaming with your eyes to coding with AI: New frontiers for accessibility github.com
Accessibility is forging new frontiers in every industry thanks to open-source contributions!
Adventures in time: Debugging a daylight saving bug alextaylor.ca
We still have to deal with daylight savings time, so timezone bugs will never die.
The first version of your favorite digital products www.theversionone.com
If you’re ever feeling down about how your project doesn’t look that great from the start, here’s a fun little site showing what “Version 1” of some of your favorite services looked like!
Moving from Vue 1 to Vue 2 to Vue 3: A case study of migrating a headless CMS system www.smashingmagazine.com
Handling migrations within long-term projects can be tough, and this is an interesting deep dive into how one team did it.
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #170: Wary about AI assistants appeared first on Stack Overflow Blog.
Kenny Hearn, Fund Manager and Head of Research at SwissOne Capital, tells Ben about his path from traditional asset management to Web3 specialist and why he remains optimistic about the future of the market.
Episode notes:
In his role at SwissOne Capital, Kenny champions investments in Web3 and the metaverse. A writer on all things crypto since 2013, he’s a regular contributor to the US Chamber of Commerce.
The collapse of Three Arrows Capital and FTX eroded investor trust in crypto, but Kenny remains “cautiously optimistic” about the market’s future.
Connect with Kenny on LinkedIn or Twitter.
Congratulations are in order for Lifeboat badge winner xray1986 for their answer to Unicode symbol that represents “download”.
TRANSCRIPT
The post After crypto’s reality check, an investor remains cautiously optimistic (Ep. 548) appeared first on Stack Overflow Blog.
Thanks to David Meyers, Principal Engineer at Flipp, for introducing me to this concept, normalizing it, and implementing it flawlessly.
Raw startups are often chaotic and scattered. “Move fast and break things!” was repeated in the standups of hundreds of startup engineering orgs. Typically, startups tend to build monolithic systems to reduce friction in creating and changing features. As time goes on, the monolithic architecture begins to show strain, and almost inevitably begins to be broken up.
Teams begin to take ownership of the new services, usually adhering to Conway’s Law. Since each service is only owned by a single team (or should be), questions inevitably arise related to the technologies used for each of them.
Should the backend administrative system, used by a dozen internal employees, be written using the same frameworks and stack as the tight, performance-critical end-user system? Should batch processors have the same technical footprint as stream processors? Should analytics databases use the same solution as the one used for ad-hoc queries?
Some engineers love to experiment with new, bleeding-edge technologies. Others warn of the perils and demand adherence to the tried-and-true. As the company grows ever bigger, the same sorts of problems emerge over and over again to be solved. Do you solve those problems the same way you did earlier because it’s already done? Or do you go with a new approach that offers more benefits?
How these problems get solved becomes more critical as a startup transitions to a medium-sized company.
TerminologyThis article discusses all kinds of technology from a software engineering perspective. This can include programming languages, frameworks, database systems, ways to store and transfer files, schema definition systems, etc. I will use the word tech as a shortcut to describe this list of solutions, systems, and projects.
Option 1: The Wild WestAt one extreme, we could simply allow every team to choose whatever tech they wanted to use with full autonomy. There’s no oversight committee, no red tape, and no blockers to doing what they want how they want.
The benefits* Teams are empowered to make their own technology decisions based on the information they have. * The “best” tech for the problem being solved can be used. * Teams are not tied down by previous technical decisions made either by themselves or other teams. * Morale is high since engineers get to use new, fun tech rather than being stuck with old or out-of-style choices. * Engineers feel that their voices matter in technology decisions.
The downsides* It is more difficult to reuse previous solutions written in other languages or frameworks. * It is harder to generalize solutions across similar problems since reuse is harder. * There is risk of “technology sprawl”: a single engineer has to know multiple technologies in order to succeed at their job. * This can result in superficial broad knowledge of languages or systems rather than deep knowledge of one tech, which can affect the ability to debug problems or make more advanced changes. * Hiring and internal training becomes more onerous. Either the company has to hire engineers who already know the full set of tech or spend more time training them once they are hired. * Internal support becomes more fractured since there will be fewer experts in any one tech to help less experienced developers. * Building internal tools may become more difficult since it has to work with all the tech that the team (or company) supports.
Option 2: Lock it downAt the other extreme, whatever choice was made at the company’s inception becomes the one and only solution that must be used. If the first application was made using Python and Postgres, then every service must use only Python and Postgres.
The advantages and disadvantages are swapped here.
The benefits* Reusing previous solutions and generalizing them becomes much easier since you are guaranteed to use the same tech stack. * Each engineer can be trained on a single stack and can more easily learn deep knowledge about it, and therefore help support other engineers. * Hiring is easier since only one set of skills is necessary. * Internal tools are simpler since they only have to deal with one set of tech.
The downsides* Engineers become demoralized since they feel stuck with old tech that may not be well suited to the problem at hand. * Trying to squeeze a tech into solving a problem it isn’t designed for can result in increasingly hacky and costly kludges. * Engineers do not feel empowered since they have no agency to make technological decisions.
The golden meanAs you can guess, the “right path” is somewhere in the middle of these extremes. At Flipp, the term used is the Tech Toolbox, and it works like this.
- The team or company curates a list of approved tech. This list should be very small.
- The contents of the list should start with whatever the company is using at the moment.
- Each tech on the list should be given an overall status of approved, pending approval, discouraged, or not allowed.
- Further, each tech should be specific as to what use cases it is approved for. For example, Postgres might be approved for ad-hoc queries and internal tools, while MongoDB might be used for more performance-critical uses where the queries are well-known.
- All new projects must by default use tech on this list, and all other tech is not allowed.
- Approved tech are given official support by internal tools and our engineering guilds. All other tech is not supported.
Crucial to the success of this framework is that it should have three processes:
- Adding a tech to the toolbox
- Auditing and removing tech from the toolbox
- Allowing one-off exceptions to the policy
There should be a committee of senior, staff, or principal engineers who manage these processes. This sounds heavy-handed, but in reality, once the toolbox is set and disseminated properly, these processes happen very rarely.
Adding a new techIf a team feels that none of the tech in the toolbox currently solve its problem set and that a new tech could be broadly useful across the team or company, it can petition the committee to add it to the toolbox.
This petition needs to be presented as a business case. This doesn’t mean that the team needs to do research with actual dollars attached to it. They need to be able to argue one or more of the following:
- The tech allows us to significantly reduce infrastructure cost by being more performant.
- The tech allows us to reduce engineering costs and go to market faster by making it significantly faster to develop with.
- The tech saves on testing and quality costs by reducing errors.
- The tech increases morale by providing a less stressful development environment. (This could be a broad category).
Generally, there should be some kind of data attached to this. In the latter point, it might simply be surveys of the engineers on the team.
Once the committee is satisfied, the tech is considered pending approval. The requesting team should proceed with a proof-of-concept implementation of the new tech so that any kinks or surprises can be ironed out. Once this is deemed a success, the tech can be approved in the toolbox.
If the tech fails the process, that doesn’t mean the proposal is dead in the water! Proposals can always be revisited if there is new information or use cases. And the proposing team always has the option of using it for one-offs (see below).
Auditing and removing techPeriodically, the committee should speak to the engineers who manage the systems they own and see if a particular tech has fallen out of favor, and if so, why. Sometimes a new tech entirely supplants an older one and is deemed unwise to use since the new one is better in most respects for the use case in question.
If the committee and engineers agree, the tech in question then becomes demoted to discouraged. This means that no new projects should be built with it, and all existing projects using it should have some kind of plan to move off of it if possible.
Once as many services as possible have moved off it, the tech can be moved to not allowed. There can be legacy systems using the old tech that are grandfathered in and allowed to stay, but these are “special cases” and don’t affect the overall status of the tech in the toolbox.
One-off exceptionsNo one likes working for tyrants, and the tech leadership committee is no different. There are always cases where a tech that didn’t make the cut or is marked as discouraged still needs to be used.
At Flipp, we moved Node.js from approved to discouraged for our end user-facing systems, and effectively replaced it with Go. However, we identified that there are some cases that Go is not well suited for—data munging arbitrary JSON files, for example, or using third-party SDKs that often are better maintained in JavaScript. These projects were able to argue their case and got a pass, with the caveat that these teams were on their own for support and tooling.
The resultWith a tech toolbox, we have a single central document we can point to explaining what we use at Flipp and why. We have a “paved road” to make it easier to create projects using this technology, such as an app generator, shared libraries, deployment support, and more. We have guilds that meet regularly and take on projects to improve the usage and documentation for how we use that tech within the company. And we have an explicit process to make changes to this list so engineers don’t feel disenfranchised.
As your company grows, technology decisions become more costly. Having a framework like this in place will provide a defined path forward.
The post Your tech toolbox: The middle ground between tech chaos and rigidity appeared first on Stack Overflow Blog.
SPONSORED BY MONGODBThe history of computing has been a story of moving up levels of abstraction: from hard-coding algorithms and directly manipulating memory addresses with assembly languages to using more natural language constructs in high-level general purpose languages to abstracting the hardware of the computer in cloud compute. Now serverless functions take that abstraction even further. We’ve made the algorithms that process data simple and natural; MongoDB wants to do the same for how we persist data.
On this sponsored episode of the podcast, we chat with Andrew Davidson, SVP Products at MongoDB, about how they’re turning a database into a fully-managed service that developers can use in a more natural way. Along the way, we discuss how the cost bottleneck has moved from the storage media to developers’ minds, how greater abstractions can enable developers, and how to get insights from production data faster.
Episode notes
Try MongoDB Atlas on AWS for free.
You can get started with MongoDB Atlas directly from the AWS Marketplace.
If you’re at a startup, you can take advantage of their special offer for startups.
The community edition of their classic database is available to download as well.
If you’re looking to learn a thing or two before diving in, check out MongoDB University.
Our thanks to Great Question badge winner Derek 朕會功夫 for asking How can I reverse an array in JavaScript without using libraries? You know the rarest kung fu of all: asking great questions.
The post Moving up a level of abstraction with serverless on MongoDB Atlas and AWS appeared first on Stack Overflow Blog.
Charles “Cobih” Obih and Radek Markiewicz of the Stack Overflow platform team join Ben and Ryan to talk about changes to the inbox and what it’s like to build Stack Overflow’s public platform.
Episode notes:
The inbox improvements were Radek’s graduation project. Not bad for a newbie.
Not everyone likes change, and the inbox change was no exception. So we looked into fixing that.
Read about what our engineering team learned building and scaling Stack Overflow to support millions of users.
Connect with Radek on LinkedIn.
Find Cobih on LinkedIn and Twitter.
Longtime staff member Yaakov Ellis is on LinkedIn and Twitter.
Congrats to user HelloCW on receiving a Socratic Badge for asking a well-received question on 100 separate days and maintaining a positive question record.
TRANSCRIPT
The post What our engineers learned building Stack Overflow (Ep. 547) appeared first on Stack Overflow Blog.
Site reliability engineering (SRE) can emerge as a bottom-up initiative to run services in an organization and grow into a successful practice fulfilling SRE principles. While ad-hoc SRE can help developers maintain code in production, to sustain the practice long-term, an appropriate organizational structure for SRE is needed. In this article, we explore SRE team topologies—ways to organize for SRE that stood the test of time.
SRE principles vs. SRE organizational structureTo begin with, we need to distinguish between fulfilling the SRE principles and an organizational structure for SRE. The SRE principles are:
- Operations is a software problem
- Work to minimize toil
- Automate this year’s job away
- Move fast by reducing the cost of failure
- Share ownership with developers
- Use the same tooling, regardless of function or job title
It is vitally important to understand that the SRE principles do not dictate any organizational structure. Rather, the SRE principles can be followed by teams embedded in several different organizational structures.
An SRE practice where the SRE principles are followed can succeed either with a central SRE team, without a central SRE team, or with several central SRE teams comprising an SRE organization. With this, what are the options to organize well for SRE?
Who builds it? Who runs it?Organizing for SRE must start with a fundamental decision: “Who builds and who runs the services?” This gives rise to several options ranging from the traditional “you build it, ops run it” to the modern “you build it, you run it.” The main options in-between are “you build it, you and SRE run it” and “you build it, SRE run it.” In Establishing SRE Foundations, these options are aligned on the so-called “who builds it, who runs it” spectrum. The spectrum is shown in the figure below.
(Image attribution: “Establishing SRE Foundations”)
What is important to understand about the options on the spectrum are the incentives they provide for the development teams to implement reliability. With “you build it, you run it,” the incentives are maximized because developers are on-call and do not want to be woken up in the middle of the night due to reliability issues. This will prompt the developers to do everything possible to implement reliable services, though it does add yet another responsibility to developers. These incentives diminish with every other option.
With “you build it, ops run it,” the incentives are minimal and can lead to the notorious chasm between development and operations teams. The chasm results in developers throwing their code over the wall to operations engineers. In this case, neither the code is written with operability in mind nor the operations engineers possess the knowledge to operate it. We therefore exclude this option in the considerations below.
Other differences between the options on the “who builds it, who runs it” spectrum include knowledge synchronization between teams, incident resolution times, service handover for operations, establishment of an SRE organization, etc.
Setting up an organizational structure for SREOnce an organization selects an option from the “who builds it, who runs it” spectrum, they can set up an organizational structure for SRE. To do so, the following questions need to be answered:
- Which teams are in the development organization?
- Which teams are in the operations organization?
- Which teams are in the SRE organization, if it is to be created?
The cross product of
- you build it, you run it
- you build it, you and SRE run it
- you build it, SRE run it
and
- development organization
- operations organization
- SRE organization
yields nine sensible SRE Team Topologies. These are described in detail in Establishing SRE Foundations. In the next section, we provide an overview of the topologies.
SRE Team TopologiesThe SRE team topologies are embedded in the development, operations, and SRE organizations of an enterprise. To avoid ambiguity, here are the primary responsibilities of the three organizations:
| Organization | Primary responsibilities | | Development organization | Build products Depending on the SRE team topology: Run products to the extent agreed | | Operations organization | Provide tools as a serviceDepending on the SRE team topology:Build and run the SRE infrastructure Run products to the extent agreed | | SRE organization | Depending on the SRE team topology: Build and run the SRE infrastructure Run products to the extent agreed |
That is, a selected SRE team topology determines to a great extent the primary responsibilities of the development, operations, and, if it exists, SRE organization. Below is the list of nine SRE team topologies from Establishing SRE Foundations.
SRE Team Topology 1:
| Development organization | You build it, you run it with no dedicated SRE role. Every developer is an SRE on rotation | | Operations organization | SRE infrastructure team | | SRE organization | Does not exist |
This is a classic “you build it, you run it” SRE team topology as followed by Amazon, for example.
SRE Team Topology 2:
| Development organization | You build it, you run it with a dedicated SRE role in the team | | Operations organization | SRE infrastructure team | | SRE organization | Does not exist |
This SRE team topology introduces a dedicated SRE role in the development team. That is, unlike the SRE team topology 1, not every developer is an SRE on rotation here.
SRE Team Topology 3:
| Development organization | You build it, you run it with a dedicated SRE role in the team and a dedicated developer on rotation | | Operations organization | SRE infrastructure team | | SRE organization | Does not exist |
This SRE team topology is a combination of the SRE team topologies 1 and 2. There is a dedicated SRE role in the team that runs the product together with another developer on rotation.
SRE Team Topology 4
| Development organization | You build it, you and SRE run it with a dedicated SRE team | | Operations organization | SRE infrastructure team | | SRE organization | Does not exist |
This SRE team topology introduces a dedicated SRE team placed in the development organization. The members of the SRE team run the product in a shared on-call together with the developers from development teams.
SRE Team Topology 5
| Development organization | You build it, you & SRE run it | | Operations organization | Dedicated SRE team and SRE infrastructure team | | SRE organization | Does not exist |
This SRE team topology places a dedicated SRE team into the operations organization. Like in the SRE team topology 5, the members of the SRE team run the product in a shared on-call together with the developers from the development teams.
SRE Team Topology 6
| Development organization | You build it, you and SRE run it | | Operations organization | SRE tool chain procurement and administration | | SRE organization | Dedicated SRE team and SRE infrastructure team |
This SRE team topology introduces a dedicated SRE organization. The SRE team running the product together with the development teams is in the SRE organization. The SRE infrastructure team building and running the SRE infrastructure is in the SRE organization too. The shared on-call is the same as in the SRE team topologies 4 and 5. This is roughly the SRE team topology employed by Facebook with their production engineering organization. At Facebook, it is called the “centralized reporting, embedded locality” model.
SRE Team Topology 7
| Development organization | You build it, SRE run it with a dedicated SRE team | | Operations organization | Dedicated SRE infrastructure team | | SRE organization | Does not exist |
This SRE team topology places the responsibility of running the product onto a dedicated SRE team placed in the development organization. However, if the services fall below an agreed service level, the SRE team “returns the pager” to the development team until the agreed service level is reached again.
SRE Team Topology 8
| Development organization | You build it, SRE run it | | Operations organization | Dedicated SRE team and SRE infrastructure team | | SRE organization | Does not exist |
This SRE team topology places the responsibility of running the product onto a dedicated SRE team placed in the operations organization. As in SRE team topology 7, if the services fall below an agreed service level, the SRE team “returns the pager” to the development team until the agreed service level is reached again.
SRE Team Topology 9
| Development organization | You build it, SRE run it | | Operations organization | SRE tool chain procurement and administration | | SRE organization | Dedicated SRE team and a dedicated SRE infrastructure team |
This SRE team topology places the responsibility of running the product onto a dedicated SRE team placed in the SRE organization. As in SRE team topology 7, if the services fall below an agreed service level, the SRE team “returns the pager” to the development team until the agreed service level is reached again. This is the SRE team topology employed by Google.
In addition to the differences in organizational structure, different SRE team topologies vary in other areas such as knowledge synchronization between teams and organizations, effort for service handover for operations, incident resolution times, and more. An often overlooked difference is the SRE cultural identity created by an SRE team topology.
SRE cultural identity An SRE cultural identity is based on three identity dimensions: a product-centric identity, an incident-centric identity, and a reliability user experience-centric identity. A product-centric SRE identity is when SREs strongly identify themselves with the product they run. They are not just SREs, they are (for example) Microsoft Office 365 SREs taking pride in the product. This is typical when SREs are placed in the development organization.
An incident-centric identity is when SREs are focused on having as few incidents as possible in products they run. These SREs pride themselves in metrics like only having just a few incidents a year. This is typical when SREs are placed in the operations organization.
A reliability user experience-centric identity is when SREs are focused on achieving the user experience of reliable products for the products they run. These SREs pride themselves in having SLOs tracking the user experience well, having the SLOs fulfilled by the products they run, etc. This is typical when SREs are placed in a dedicated SRE organization.
An SRE team topology spawns an SRE cultural identity triangle with the vertices: product-centric identity, incident-centric identity, and reliability user experience-centric identity. A particular SRE team topology will lean more towards one of the vertices on the SRE identity triangle.
Transition to the selected SRE team topology Once an SRE team topology has been selected, the question of transitioning from the current setup to the selected one becomes important. If a new SRE organization gets established during the transition, it needs to be positioned within the overall product delivery organization.
The SRE organization can be viewed as a cost center, an asset, a business partner, or a business enabler. The goal of the newly minted head of the SRE organization is to position the organization as much as possible to be the business enabler.
Within the SRE organization, an SRE career path needs to be established to provide a proper career ladder for SRE professionals as they grow their skill and practice. A defined SRE career path also helps attract SRE talent to the company.
SummarySRE principles can be fulfilled by many organizational structures. In this article, nine SRE team topologies were presented, which can be widely found in the industry. A decision to choose a particular SRE team topology needs to be made taking into account the current organizational setup and culture, the envisioned target organization and SRE cultural identity, knowledge synchronization requirements between teams, and other factors.
More details on how the decision can be made are available in the talk “Establishing SRE Foundations: Aligning The Organization On Ops Concerns Using SRE Team Topologies” from the DevOps Enterprise Summit US 2022 and the corresponding book Establishing SRE Foundations: A Step-by-Step Guide to Introducing Site Reliability Engineering in Software Delivery Organizations by the author.
The post Who builds it and who runs it? SRE team topologies appeared first on Stack Overflow Blog.
It’s an anxious time to work in tech. According to one count, more than 280,000 people were laid off from tech jobs in 2022 and the first two months of 2023.
This is scary. People have lost their livelihoods. Thousands of people in the United States on H-1B work visas, along with their families, face deportation unless they can find another job within 60 days. Diversity gains in tech have been dealt a serious blow. These layoffs have spotlighted the tenuous and unsustainable situation the US immigration system creates for foreign-born workers; the disproportionate impact of tech layoffs on women, people of color, and parents; and the still-shifting landscape of the post-pandemic economy.
More than 280,000 people were laid off from tech jobs in 2022 and the first two months of 2023.
Many of us have been through layoffs before, sometimes several times. My career at tech companies began in 2014, and in that time I’ve been laid off once. My colleague Ryan Donovan recently wrote about his experiences with tech startups and how to handle industry-wide layoffs, whether you recently lost your job or you’re just afraid you might.
As the discouraging headlines and meta-narrative about what the layoffs really mean continue, we thought it was worth revisiting how our core community of developers has been experiencing and coping with this ongoing reality—and exploring what sets this economic situation apart from previous dips and busts.
The post-pandemic economy isn’t what we expectedAny conversation about tech layoffs in 2023 has to account for the fact that, as The Atlantic’s Derek Thompson put it, “the post-pandemic economy has been much weirder than most people anticipated.”
In 2020, Thompson writes, people noted our rising dependence on technology like streaming video and food-delivery apps and predicted an “acceleration” of the rapidly digitalizing pandemic economy: “In this interpretation, the pandemic was a time machine, hastening the 2030s and raising tech valuations accordingly.” In response, hiring across tech jumped. By 2022, it was clear that the pandemic had produced less of a steady, sustainable acceleration and more of a…well, bubble. And we all know what bubbles tend to do.
The current economy has less in common than you might think with the dot-com bubble or the Great Recession.
But the current economy has less in common than you might think with the wreckage of the dot-com bubble or the Great Recession. Overall, it’s still a good time to work in tech, and the hiring market remains robust: One survey found that almost 80% of people laid off in tech found new roles within three months of launching their job search. There are more open tech positions than people to fill them (about 375,000, according to one estimate), and job listings between January and October 2022 were up 25% over the same period in 2021.
Company see, company do?If the job market isn’t as dire as we think, why does this round of layoffs feel so widespread, affecting companies often perceived as more recession-proof than their peers? Part of the answer may be what organizational behavior experts have termed “copycat layoffs.”
“Laying off employees turns out to be infectious,” writes Annie Lowrey in The Atlantic. “When executives see their corporate competitors letting go of workers, they seize what they see as an opportunity to reduce their workforce, rather than having no choice but to do so.” Organizations seeking to reduce risk in the face of an anticipated economic downturn may jump on the opportunity to trim costs without raising a ruckus. Companies that lay off employees while everyone else is doing it also reduce their risk of reputational damage: they’re not the only ones doing it, which suggests that layoffs are due to external economic factors, rather than company-specific shortcomings.
The jobs aren’t gone—they’ve just movedIn many cases, workers laid off by household-name tech companies have found new jobs outside the traditional parameters of the tech industry, where their skill sets are in high demand. As Matt McLarty, global field chief technology officer for MuleSoft, told CNBC, businesses that have long needed tech professionals to upgrade their stack or guide a long-delayed cloud migration can now scoop up freshly laid-off tech workers (and those for whom Silicon Valley has lost its luster). Companies in energy and climate technology, healthcare, retail, finance, agriculture, and more are hiring tech pros at a steady clip, even if FAANG companies are less bullish. It’s been said before that every company is a tech company, but in 2023, that’s truer than ever.
In fact, the biggest difference for tech workers this year, reports The New Stack, is that “the greatest opportunities may not lie exclusively in the FAANG companies anymore, but in more traditional industries that are upgrading their legacy stacks and embracing cloud native.”
The greatest opportunities may [lie] in more traditional industries that are upgrading their legacy stacks and embracing cloud native.
Some of those opportunities also lie with startups, including ones helmed by Big Tech veterans ready to turn their layoffs into lemonade. And efforts are underway to build the leading generative AI platform and an expanding ecosystem of related tools. “There’s a lot of investment firms that are still bullish about the startup space,” Lindsay Grenawalt, chief people officer at Cockroach Labs, which raised $278 million in Series F in late 2021, told The New Stack.
So whether you’ve been affected by the recent spate of layoffs or not, it’s worth expanding your list of potential employers to include companies—even industries—you’ve never considered. You might find that they’re thrilled to have you.
One place to start is Indeed’s layoff support resources, offered in collaboration with Stack Overflow, Glassdoor, and Tech Up For Women. You’ll find free, automated tools to optimize your job search; paid professional services like career coaching and resume building; and articles and webinars to help you navigate things like negotiating a severance package, understanding unemployment eligibility, pivoting to a new career, and more.
We’re also teaming up with Indeed to provide a 45-minute learning and development webinar where experts at Indeed will share best practices for job hunting and professional development while answering your career questions. Register below to get your questions answered by the experts!
The post What’s different about these layoffs appeared first on Stack Overflow Blog.
Welcome to ISSUE #169 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: what developers think about cutting-edge tech, how to protect your open-source hardware specs from a commercial patent, and why large language models start understanding text.
From the blogFive Stack Exchange sites turned ten years old this quarter! stackoverflow.blog
High fives to a Stack Exchange milestone for English Language Learners, Magento, Reverse Engineering, Sustainable Living, and Tridion!
After the buzz fades: What our data tells us about emerging technology sentiment stackoverflow.blog
Developers expect AI assistants to be everywhere soon, but they aren’t necessarily happy about it.
“Move fast and break things” doesn’t apply to other people’s savings (Ep. 544) stackoverflow.blog
Christine Ryu, Engineering Lead at fintech platform Flourish, joins the home team to talk about how technology is transforming finance for everyone from big banks to individual consumers.
From writing code to teaching code (Ep. 545) stackoverflow.blog
After 37 courses and half a million students, a former developer reflects on his journey to instructor.
MongoDB Atlas University Course promotion
Learn how to deploy a global, multi-cloud database with MongoDB Atlas. Get hands-on experience creating and deploying a database with this free course.
Interesting questionsProtect public project from potential patents opensource.stackexchange.com
Check out the concept of defensive publishing, which is the legal equivalent of posting “First!”
Does the Earth constantly lose mass? astronomy.stackexchange.com
It loses a tiny amount as air escapes and astronauts leave flags on the Moon. But none of this is the Moon’s fault.
Did courtiers of antiquity hold in their pee or did they have common commodes available in the king/queen’s court? history.stackexchange.com
To pee or not to pee, that is the question.
How to politely decline a take-home test task? workplace.stackexchange.com
That depends: do you want the job or not?
Links from around the webEmergent abilities of large language models www.assemblyai.com
If you’ve heard the term “large language model” (or LLM) a lot lately, you’re not alone. Here’s a look at how new capabilities emerge as the LLM scales without changing the algorithm.
How to become a DevOps engineer: An untimed guide www.theopalblog.com
DevOps is a huge space with a ton of opportunities. If you’re interested but unsure how to get started, this is a great guide for you.
Why you need to know your site’s performance plateau (and how to find it) www.speedcurve.com
When do your website performance metrics plateau?
Data Reliability Engineering Conference drecon.org
Stack Overflow’s own director of reliability engineering, Ellora Praharaj, will be speaking at DRE Conference. If you can’t make it in person, check out the virtual option!
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #169: Fear the Frankencode appeared first on Stack Overflow Blog.
The home team unpacks their complicated feelings about AI, the Beyoncé deepfake that got kpop hopes up, and the pandemic’s ripple effects on today’s teenagers. Ben, the world’s worst coder, tells Cassidy and Ceora about building a web app with an AI assistant.
Episode notes:
Our recent Pulse Survey showed how technologists visiting Stack Overflow feel about emergent technologies. The consensus is clear: AI assistants will soon be everywhere, and developers aren’t sure how they feel about that. Check out the podcast here or dive into the blog.
Learn more about the emergent abilities of large language models (LLMs).
For more on the intersection of AI and academia, listen to our episode with computer science professor Emery Berger or read his essay on how academics are coping with AI that can ace exams and do everyone’s homework.
Catch up on the adventures of the worst coder in the world.
Congrats to user d1337, whose question How to assign a name to the size() column? won a Stellar Question badge.
TRANSCRIPT
The post Let’s talk large language models (Ep. 546) appeared first on Stack Overflow Blog.
There’s a wonderful thing that happens to many of us who work at Stack Overflow. In casual social conversation, someone will ask where I work, or on the way home from the gym while wearing a Stack Overflow T-shirt, someone will stop me in my tracks. “Do you work at Stack Overflow?” they ask breathlessly. The answer is of course yes, and inevitably, the person’s eyes light up, and frequently there is a story that goes with that reaction. “You got me through my first coding bootcamp,” or “I always have a tab open to Stack Overflow when I’m at work.” The genuine excitement and enthusiasm is inspiring for those of us who take our mission of empowering the world’s technologists to heart and a palpable embodiment of the millions of developers who visit our public platform to get unstuck, learn, and share their technical expertise. Additionally, many of the same technologists use our market-leading knowledge sharing platform Stack Overflow for Teams, a private instance of our public platform, in their day to day work lives to collaborate with their colleagues, find subject matter experts, and stay productive.
To that end, we want to hear directly from YOU: Stack Overflow enthusiasts with stories of how our public platform or Stack Overflow for Teams swooped in, taught you something new, saved the day, or even introduced you to your spouse. (We kid…sort of.) Did Stack Overflow help resolve a pesky bug in your code? Or maybe Stack Overflow for Teams helped you find an answer at work and made you more productive? Perhaps someone on our site or in your Teams instance taught you something new that unlocked answers on a side project you’ve been working on. If you’ve got a story about Stack Overflow or Stack Overflow for Teams, we want to hear all about it.
As an extra special treat for our community members who submit their stories, we partnered with artisan key cap makers Tiny Makes Things and Clackeys on a limited edition, 3D Stack Overflow Key Cap! Every individual who submits a story about how Stack Overflow or Stack Overflow for Teams saved the day will be automatically entered into a drawing to win a key cap. As a coda to our long love affair with the Key and the Key V2, our limited edition Stack Overflow Key Cap is the perfect decorative accoutrement for a keyboard enthusiast or a fun Stack Overflow collectible. But don’t wait! We have an extremely limited number of key caps, and we want to share these with as many of our community members as possible.
Submit your story for Stack Overflow Saved the Day here.
Submit your story for Stack Overflow for Teams Saved the Day here.
The post Can Stack Overflow save the day? appeared first on Stack Overflow Blog.
With so many companies offering API products, it can be hard to get your particular APIs discovered and used by the developers who need them most. You might have the best, most useful solutions out there, but if you’re relying on the digital equivalent of foot traffic for discoverability, it might as well not exist. And if an API solution can’t be found, then someone else is going to reinvent it.
On this sponsored episode, we chat with SmartBear API Technical Evangelist Frank Kilcommins about the growing challenges of API visibility and how to outsmart the invisibility trap with the right development strategies and tools.
Episode notes:
Kilcommins suggests you can get better visibility for your APIs with SmartBear’s new free API exploration tool.
Open specifications like the Open API Initiative help make your endpoints easier to understand—both by humans and computers.
Connect with Frank Kilcommins on Twitter and LinkedIn.
Congrats to Stack Overflow user WorstCase, who asked five well-received questions on five separate days and earned themselves a shiny new Curious badge.
The post Visible APIs get reused, not reinvented appeared first on Stack Overflow Blog.
This week we sit down with some fellow Stackers, Erin Yepis and Joy Cicman Liuzzo, to discuss the results of our latest Pulse Survey. Developers told us what emergent technology they expect to become mainstream, what they think is a fad that will pass, and how they feel about everything from AI to open source to blockchain.
Episode NotesYou can dive deeper into the research, including some lovely matrix charts, on our blog.
Erin has also explored tag trends among our most loved languages and job insights from our community.
Learn more about Joy on her LinkedIn.
Thanks to our Lifeboat badge winner of the week, russbishop, for helping to answer the question: Where is the app content folder in the simulator of Xcode?
TRANSCRIPT
The post Developers think AI assistants will be everywhere, but aren’t sure how to feel about it appeared first on Stack Overflow Blog.
In networked software, APIs have become the foundation of every app. Whether those are the backend endpoints that power the app or third-party APIs that provide specialized services, managing them effective can mean the difference between a successful API product and death by 500 server error.
We spoke with Marco Palladino, CTO and co-founder at Kong, all about APIs past and future and what engineers need to do once their API endpoint has been built.
We’ve edited this conversation for clarity. This Q&A is also available as a video.
Ryan Donovan: How did you get involved in the world of APIs?
Marco Palladino: When we started our journey with APIs, we started with an idea in 2009 to build an API marketplace like Amazon but for APIs. We imagined a world where APIs would be the main foundation block for every application that anybody creates in the world. In 2009, that was just about to get started, so people were asking us, “What is an API?” We built our first business called Mashape, which was an API marketplace. If the world runs on APIs, then we need to have a marketplace for APIs. That product was the beginning of the Kong journey, because the Mashape marketplace didn’t work very well for us but the technology we built was very good in this new microservices and API world. We built it for ourselves and we open sourced it, so we extracted it and we pivoted into Kong as part of a transition we made in 2015.
RD: That’s very much ahead of the game. You must be excited about the innovations in Jamstack these days.
MP: Yeah, I mean there’s innovations that are happening pretty much across the board. Now in my space, which is the API space, what we’re looking at is APIs as fundamentally running pretty much every digital experience we can think of. 83% of the world internet traffic today runs on APIs. APIs are powering everything, as we all know, in our daily lives, in every category and every industry that we normally interact with.
RD: What makes a good API?
MP: Well we should think of APIs as user interfaces, except the user is a developer. Good APIs are easy to use, easy to understand, and not convoluted, and fundamentally they provide a nice abstraction on top of the service or the data that we want to access through the APIs. The ones that are bad are the ones don’t have any of these properties. They’re ugly, they’re hard to use, they’re inconsistent. There is no documentation whatsoever, therefore, it’s hard to consume them and hard to test them and debug them.
Ultimately, the criteria that separates the good APIs from the bad APIs is the consumption. At the end of the day, APIs are as valuable as the consumption that we’re able to create on those APIs. And if these APIs are not being consumed, it doesn’t matter how good the service is or the data is that’s behind that API. If the API is not being consumed, that API, quite frankly, is useless.
RD: Do you have an opinion on the various architecture styles or frameworks like the REST versus GraphQL, or even SOAP from back in the day?
MP: It’s funny to see the evolution of API protocols over time. We started with SOAP, but some in the audience may think we started earlier than that with CORBA. APIs as a concept have permeated our industry since forever.
Now with SOAP APIs, we have the emergence of web service for the first time. SOAP APIs were notoriously hard to use, hard to consume, very verbose, and so when mobile came out in 2007-2008, everybody needed to create mobile applications. It turns out that consuming RESTful APIs is a much easier endeavor, and we can leverage most of our existing knowledge and clients to be able to do that so we don’t need to have specialized SOAP clients to consume those APIs.
The problem is, as the number of APIs increases over time, it becomes very computationally and network expensive to make lots of requests to all the RESTful APIs that we have. So we started to see new patterns emerge, like GraphQL, which allow us to essentially get multiple responses for multiple APIs in one request and one response. That allows us to save in bandwidth which is very important, especially for mobile, and also improve the latency because we’re not sending 50 requests across all the APIs but only one request. In GraphQL, the gateway is going to be responsible for aggregating all those other responses.
GraphQL is obviously one of those trends, but we’re seeing a lot more. Internally especially we’re seeing adoption of GRPC, where we want to use faster protocols that do not require computationally intensive serialization and deserialization in JSON. We’re seeing events being used as a way to create asynchronous microservices by propagating state changes in the data, not via a service-to-service synchronous requests, but an asynchronous event that we can store in a log collector like Kafka. We’re seeing that APIs were SOAP only for a very long time, then REST came in, and then now it is many different protocols depending on the use case and the requirements that you have.
RD: When we’re talking about a large number of APIs, we’re usually talking about microservices. How do gateways, service meshes, and other architecture-level applications help manage microservice overload?
MP: Building an API is half of the job. Once we have an API, we need to expose the API and govern how we want these APIs to be consumed, either internally or externally. There’s lots of controls that we have to build in the API infrastructure that allow us to manage access to or revoke access, monitor and capture analytics, document the API, and create an onboarding flow for the API. All of these complimentary use cases are critical for that API to be successful. Having an API sitting somewhere does not mean that API will be successful. This is very important at the edge where we want to expose our API to partners, to a developer ecosystem, to mobile applications.
We want to have that whole product journey to the API to be very nice. APIs are products in a way, right? So we have to treat them with the same lifecycle that we treat every other product. How do we version them? How do we decommission them? How do we make them better? API gateways are great at this. API management is a function that allows us to productize an API, either externally or internally, and it allows us to create all these flows and highways to the consumption of the API. Now some of these APIs are going to be consumed internally within the applications themselves—so not across different applications, but within the application itself. There we don’t need to have this higher level management of the API, but what we need is a lower level that’s faster, lower level network management of the API, and that’s where service mesh comes in.
With service mesh, we can reduce and remove that extra hop in the network that we would have by having a centralized ingress. We can remove that and go from service to service via a sidecar model in such a way that we make that performance much quicker because there is less networking hops we need to do, as well as it allows us for a more fine grain, lower level management of the underlying networking. This allows us to implement zero trust. It allows us to implement observability. It allows us to implement across data centers, across cloud failovers. If you experience problems in one cloud, we can automatically redirect to the other cloud. Now the reality is we need both. We need to have a service mesh to create this underlying network overlay that’s secure, that’s reliable, that’s observable, and then some of these APIs we want to expose at the edge or to another team or another application. That’s when API management comes into the picture to provide all those other capabilities. So the way I see it, these are complementary technologies.
RD: What’s the security risk with lots of APIs?
MP: Yeah, as a matter of fact, APIs are the biggest attack vector for pretty much every product that anybody is creating these days. Every product runs on top of those APIs, so APIs become a great source of problems if we do not secure them properly. Security means many things in the world of APIs. Security means securing the protocol and the underlying transport, so we want everything to have an identity and we want everything to be encrypted over a secure HTTPS connection in the case of RESTful APIs.
We want to secure access to the API, so we want to make sure that we can create tiers of access for those APIs. We can assign clients and consumers to these tiers in such a way that we can control who consumes the APIs, but we can also then apply specific rules to a specific tier of consumers, such as, “This type of consumer can make x number of requests per second, but this other tier cannot.” There is a third level of security where we are looking at all the traffic that anybody’s making through our APIs and trying to identify patterns that are suspicious, for example, a developer trying to send random fields to an API to see if it breaks or not. Every attacker is going to be exploring and using APIs in ways that were not intended in such a way that they can find a vulnerability. Being able to detect these types of traffic patterns becomes very important to identify suspicious behavior.
RD: What’s the most work you’ve seen a single API do? (the largest number/volume of processes behind it)
MP So I’ve seen it all. There’s different types of APIs. There are APIs that are high frequency so there’s lots of value to those APIs, but fundamentally each response is not as valuable so we can afford to lose some of that traffic because it doesn’t really matter. For example, I’m sure that Twitter has lots of API requests whenever somebody wants to open a tweet or send a new tweet. It’s not a big deal if somebody cannot see a tweet; they can just retry. That is high volume but low value for each transaction.
Then there are low volume but high value transactions, for example, when we send a tax return using one of those tax return services. We are never going to use that app and that service ever throughout the year but that one time that we’re going to be submitting our report, and that request happens once a year for each user but it’s very high value. So in my experience working with enterprise organizations and customers, Kong today is the most adopted API gateway in the world in the open-source community, but we also work with great enterprise organizations around the world that are building their API infrastructure on our technology. And I’m seeing all of these use cases so it’s very hard to pinpoint a specific one, but I’ve seen responses of gigabytes of data. So you make one request, you get gigs back, you get this huge response back. I’ve seen APIs taking days to be processed because those APIs probably should have been replaced with a job queue system. There’s pretty much everything out there.
RD: For those high-value APIs, how do you ensure reliability without sort of duplicating effort?
MP It’s very important to provide the right API infrastructure. This is why building an API is only half of the job. The other half is to make sure that these APIs are reliable. How do you make them reliable and secure? Well, we need to build that for every API that we have. And there is a series of things that have to happen to make sure that APIs are reliable, but first and foremost, reliability intended as security that has to be in place. Reliability intended as low latency and performance, we need to be able to trace the full stack of our requests to determine where potential bottlenecks could be located in such a way that we can fix them. And then there is reliability intended as being able to measure the API response status codes and response parameters in such a way that we can detect those types of anomalies and then act upon them. For high-value APIs that are low frequency, we’re working with customers where every 500 error is an open investigation that may take two or three weeks to be resolved, because they cannot lose any API request because it would create harm in their reputation and to the final end user. There are different levels of reliability that we want to achieve.
Being able to also replicate our infrastructure across multiple clouds and multiple regions in such a way that we can tolerate unpredictable failures in the underlying infrastructure becomes very important. When we have lots of APIs, it’s very hard to think of these problems on an ad hoc basis for each one of these APIs and it becomes much easier to provide this reliable infrastructure for APIs to the whole organization in such a way that we can cater to everything that’s creating APIs and not just a subset of it.
RD: In the next five to ten years, how will the ways that software services talk to each other change?
MP I am speaking with customers that are telling me in the next five years they’re going to be creating more APIs in the organization than all the APIs they’ve created up until now. So what we’re going to be seeing in the next ten years is an incredible amount of scale. And scale is both exciting and frightening. Scale is exciting because it allows us to build faster and better, and this is why we’re adopting APIs. APIs allow us to turn every product and every silo into a platform. There is lots of value in that because we can build products faster on top of that, we can create ecosystems that are much more efficient, like partner ecosystem across the globe. There is lots of business value in that scale that we’re going to be creating, but there is also a requirement to have the right infrastructure in place so that that scale can be enabled in the first place. If we are not making the application teams that are building all of these APIs extremely productive whenever they ship a new API, then the application teams are going to be worrying about all these complementary concerns that they shouldn’t be worrying about. That’s not their job. So it’s very important that as we prepare for this type of scale we make sure that the application teams are builders of APIs but not builders of infrastructure. We want them to be consumers of infrastructure and builders of APIs.
RD: Was there anything else you wanted to touch on before we sign off?
MP No, this has been a fantastic conversation. APIs are fundamentally changing and shifting the way we think of software. The way I see it, APIs are providing us the opportunity to create an assembly line of software where you pick and choose different pieces like an assembly line, and put them together to ship new applications in a better way, in a faster way. They are fundamentally changing how we are building software in the digital world. So thinking about APIs really is thinking about the future of the business, because without an API vision there is not going to be a business vision that is going to be successful, because that business vision has to rely on an API to be successful. So it’s becoming very strategic for every organization these days.
The post Building an API is half the battle: Q&A with Marco Palladino from Kong appeared first on Stack Overflow Blog.
Welcome to ISSUE #168 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: we chat with an open-source game engine creator, ponder the software that shifts in time may foul up, find the physical limits of haptic controls..
From the blogWhy governments need open source more than ever stackoverflow.blog
We face larger-than-life challenges in our world. Maybe open source’s wisdom of the crowds can help solve them.
Stop saying “technical debt” stackoverflow.blog
Everyone who says “tech debt” assumes they know what we’re all talking about, but their individual pictures differ quite a bit.
Announcing two new Collectives on Stack Overflow: R Language and CI/CD stackoverflow.com
Collectives have expanded to include areas of practice. Learn more and find out how to join the R Language and CI/CD Collectives today.
How Intuit democratizes AI development across teams through reusability stackoverflow.blog
They found success in a blended approach to product development—a marriage of the skills and expertise of data, AI, analytics, and software engineering teams—to build a platform powered by componentized AI.
The open-source game engine you’ve been waiting for: Godot (Ep. 542) stackoverflow.blog
Juan Linietsky, cofounder and lead developer of the Godot Engine, joins the home team for a conversation about what led him to create an open-source game engine, how open source is shaping game development, and the well-worn path from playing video games to learning to build them.
Integrate videos into your product within minutes, not months promotion
What’s the best way to handle and deliver video on your website, app, or software? We take care of all aspects of the video pipeline. Quickly encode, securely host, and reliably deliver videos worldwide via our global CDN. Don’t waste time and endure the hassle of integrating multiple providers.
Interesting questionsWhat are examples of software that may be seriously affected by a time jump? serverfault.com
In case you need to write an OS for a time machine.
Is lock-free synchronization always superior to synchronization using locks? stackoverflow.com
“There’s only one rule: when in doubt, use a lock.”
Is email scraping still a thing for spammers? security.stackexchange.com
The classics never die.
How to react to a student’s panic attack in an oral exam? academia.stackexchange.com
Lots of thoughtful answers here, but not among them: having your own panic attack to make them feel less alone.
Links from around the webA guide to accessible form validation www.smashingmagazine.com
Accessibility goes beyond complying with standards. You never want your users to get stuck!
The future of touch: Researchers uncover physical limitation in haptic holography techxplore.com
There are limits to the virtual world, but maybe by knowing them, we can overcome them.
Writing an effective tech spec yougotthis.io
Figuring out what you’re going to build and how is just as important as building itself!
Why is building a UI in Rust so hard? www.warp.dev
Rust is a very loved, speedy language. What are the cons?
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #168: Other words for technical debt appeared first on Stack Overflow Blog.
The home team talks with Wesley Faulkner, Senior Community Manager at AWS, about what’s going on with this cycle of tech layoffs, how to position yourself for success on the job market, and why it’s worth interviewing for jobs you might not want. Plus: The two things you should do as soon as you get an offer.
Episode notes:
Per one count, more than 280,000 people were laid off from tech jobs in 2022 and the first two months of 2023.
What do layoffs have in common with farting at a party? Both are a bad look if you’re the only one doing it.
ICYMI: On a recent episode, we talked about how these layoffs are reshaping the job market and where to find software engineering roles outside of tech.
Just laid off, or worried you might be? Cohost Ryan Donovan has some advice.
Connect with Wesley on LinkedIn.
TRANSCRIPT
The post How to position yourself to land the job you want appeared first on Stack Overflow Blog.
Information technology has always had a lot of hype around new developments. New tech emerges, piques the curiosity of technology enthusiasts, and optimistic speculation about the future begins. But sometimes when the technology gets field tested, it doesn’t always enter into wide adoption. Gartner even has a phrase for this process: the hype cycle.
We wanted to see how developers feel about the tech making headlines, so our latest pulse survey asked developers to think about nascent trends in technology and tell us how they felt about them. Despite many of these technologies having been around for quite some time, the conversations about them and their applications are evergreen and always evolving. With AI-assisted technologies in the news, this survey’s aim was to get a baseline for perceived utility and impact of a range of buzzworthy technologies in order to better understand the overall ecosystem.
The survey results’ matrix below shows four quadrants of sentiment where technologies are grouped into areas of “Positive-Emergent”, “Positive-Proven”, “Negative-Proven”, “Negative-Emergent” and in the opposing “Negative-Emergent” and “Positive-Proven” quadrants is where this analysis has placed a lot of focus due to the strength of sentiment shown in this survey’s results. Open source is clearly positioned as the north star to all other technologies, lighting the way to the chosen land of future technology prosperity.
Experimental to proven: Who’s ready for prime time?Technologies such as blockchain or AI may dominate tech media headlines, but are they truly trusted in the eyes of developers and technologists? On a scale of zero (Experimental) to 10 (Proven), the top proven technologies by mean score are open source with 6.9, cloud computing with 6.5, and machine learning with 5.9. The lowest scoring were quantum computing with 3.7, nanotechnology with 4.5, and low code/no code with 4.6.
| Technology | Proven mean | | Open source | 6.9 | | Cloud computing | 6.5 | | Machine learning | 5.9 | | Robotics | 5.7 | | Internet of Things | 5.7 | | 3D printing | 5.6 | | Serverless computing | 5.5 | | Natural Language Processing | 5.5 | | Biometrics | 5.4 | | Rapid prototyping tools | 5.3 | | AI-assisted technologies | 5.1 | | Real-time 3D | 4.9 | | Sustainable technologies | 4.9 | | Privacy preserving technologies | 4.9 | | Augmented/Virtual reality | 4.8 | | Vector databases | 4.8 | | Blockchain | 4.8 | | InnerSource approaches | 4.7 | | Low code/no code | 4.6 | | Nanotechnology | 4.5 | | Quantum computing | 3.7 |
By grouping frequency of scores into three sentiments and looking specifically at a handful of interesting standouts elsewhere in the survey, a pattern emerges: those without strong feelings about whether a specific technology is definitely experimental or proven take a larger share of the responses for those technologies that also have larger proportions of emergent ratings.
One hypothesis for this pattern is that technologies considered experimental may also be technologies that developers have less experience with and therefore absence of strong feelings. Those neutral feelings appear to be correlated with the question asked in the survey about whether respondents agreed on which technology would never be widely used in the future: blockchain and low code/no code both received more than 10% making them the top two choices in that category. It makes sense that you may grade a technology lower on the experimental-to-proven scale if you don’t believe it will be used much in the future.
Conversely and against expectations, those technologies that scored high proven scores were not necessarily the same that were chosen from our list of technologies as those that developers believed would be widely used in the future, however they were very close with one main exception. AI comes in at the top of the list by a large margin, but our three top proven selections (open source, machine learning, cloud computing) follow after. Technologists are willing to concede that AI isn’t a proven technology as of today but seem to be very positive about the direction it’s going.
The hero we need: the Positive Impact ScoreIt’s one thing to believe a technology has a prosperous future, it’s another to believe a technology deserves a prosperous future. Alongside the emergent sentiment, respondents also scored the same technologies on a zero (Negative Impact) to 10 (Positive Impact) scale for impact on the world. The top positive mean scoring technologies were open source with 7.2, sustainable technologies with 6.6 and machine learning with 6.5; the top negative mean scoring technologies were low code/no code, InnerSource, and blockchain all with 5.3. Seeing low code/no code and blockchain score so low here makes sense because both could be associated with questionable job security in certain developer careers; however it’s surprising that AI is not there with them on the negative end of the spectrum. AI-assisted technology had an above average mean score for positive impact (6.2) and the percent positive score is not that far off from those machine learning and cloud computing (28% vs. 33% or 32%).
| Technology | Positive Mean | | Open source | 7.2 | | Sustainable technologies | 6.5 | | Machine learning | 6.5 | | Cloud computing | 6.4 | | 3D printing | 6.4 | | Robotics | 6.4 | | Privacy preserving technologies | 6.4 | | Natural Language Processing | 6.4 | | Nanotechnology | 6.2 | | AI-assisted technologies | 6.2 | | Quantum computing | 6.2 | | Internet of Things | 6.1 | | Rapid prototyping tools | 6.0 | | Serverless computing | 6.0 | | Biometrics | 5.9 | | Real-time 3D | 5.7 | | Augmented/Virtual reality | 5.6 | | Vector databases | 5.5 | | Blockchain | 5.3 | | InnerSource approaches | 5.3 | | Low code/no code | 5.3 |
Possibly what we are seeing here as far as why developers would not rate AI more negatively than technologies like low code/no code or blockchain but do give it a higher emergent score is that they understand the technology better than a typical journalist or think tank analyst. AI-assisted tech is the second highest chosen technology on the list for wanting more hands-on training among respondents, just below machine learning. Developers understand the distinction between media buzz around AI replacing humans in well-paying jobs and the possibility of humans in better quality jobs when AI and machine learning technologies mature. Low code/no code for the same reason probably doesn’t deserve to be rated so low, but it’s clear that developers are not interested in learning more about it.
What can tech of the future learn from the journey of open source?Open source software is the overall choice for most positive and most proven scores in sentiment compared to the set of technologies we polled our users about. That’s a win any way you slice it. Open source is not new, but this survey is and one has to consider that open source was not always on top. The top tags for open source for non-commercially backed technologies on Stack Overflow are Python, Java, and Ruby, while the larger network has many sites dedicated to specific open source technologies: Ask Ubuntu, Unix & Linux, Blender, Drupal, Raspberry Pi, and more.
How did open source defy the assumed necessity of paid support in order to become regarded as the proven technology it is today? A big part of the history of open source that overlaps with the user base for our survey is the love of collaboration: open source and Stack Overflow’s public platform and Stack Overflow for Teams product don’t exist without it!
Collaboration isn’t just an unpaid internship type of gig, it’s important at the office. In our last pulse survey about jobs, almost one in four developers say collaboration is what retains employees and there is reason to believe that spirit of collaboration comes from experience with open source; in the same survey, 27% of developers said contributing to open source at work made a job more appealing.
Open source isn’t just about collaboration, and neither is the developer experience. Another reason to believe open source has persevered as a proven technology today is that it is a platform for learning. Proprietary software and programming languages are not going to be the first choice for educational institutions with low thresholds for cost, and definitely not for self-taught programmers completing online courses. Learning is the backbone of coding, something we can see on Stack Overflow, as well. Python, an open-source licensed programming language, has been one of the top tags for questions as of late and all of those questions being answered equate to tangible learnings. New tech talent going through traditional education paths or self-moderated online learning modules are coming into the workforce with skills in open-source tech and sometimes through open-source platforms. From our 2022 Developer Survey, Python is almost tied as the most popular language for people learning to code. Open-source removes friction in the learning process for developers, and what’s not to love about that.
Perhaps one of the biggest contributors to the growth and goodwill behind any of the technologies listed here is salary. Over half of respondents in our December survey agreed a better salary is still the largest motivator when considering a new opportunity (54%). The potential to grow one’s personal capital by learning and using open source most certainly is a large contributor to the positive and proven sentiment we see in this survey. Software engineering is projected to have the largest average growth in salary in the next 10 years by the BLS. This is likely due to the large return on the relatively low investment of time when it comes to entering the developer industry.
One of the main takeaways from our last developer survey found that blockchain developers garnered a comparable salary to people managers but with less experience. Given the sentiment scores in this survey, it’s very interesting to watch the progression of blockchain over time. While small, question share on Stack Overflow almost tripled from 2021 to 2022 (0.05% to 0.14%) despite nearly a quarter of respondents to our Web3 pulse survey believing blockchain was all hype or a scam. Post-FTX scandal, it’s clear that most developers do not feel blockchain is positive or proven, however there is still desire to learn as more respondents want training with blockchain than cloud computing. There’s a reason to believe in the direct positive impact of a given technology when it pays the bills.
AI-assisted technology should take notes from the way open-source technology has cultivated collaboration, learning, and take-home pay if it wants to make gains in sentiment around positive impact and be regarded as a proven technology. We can see the possibility of this already with machine learning, which overlaps and is a component of AI; machine learning is the third-highest scoring for both proven technologies and positive impact tech. Machine learning is already utilizing open-source programming languages and libraries, and the median salaries of data scientists/machine learning engineers worldwide are mid-range according to the developer survey. The trajectory of machine learning shows that there is a path for AI to become more proven and positive and the core characteristics of open source lay the foundation for AI to achieve that goal.
Organizations and business leaders everywhere should heed these lessons. Open source shows that collaboration and learning around emerging tech is key to wider adoption. If you’re part of an organization trying to implement new technology, Stack Overflow for Teams can help by encouraging the healthy cycle of knowledge sharing, collaboration, learning, and ultimately, knowledge reuse. While the topics, technologies, and sentiments discussed in this survey will shift over time, we’re confident that the role of collaboration and learning will not. We look forward to seeing more discussion and more learning take place on our platform in the years to come.
The post After the buzz fades: What our data tells us about emerging technology sentiment appeared first on Stack Overflow Blog.
SPONSORED BY UDEMYWriting code that runs without errors—and without all the bugs that only show up when the program runs—is hard enough. But teaching others to write code and understand the underlying concepts takes a deeper understanding. Now imagine doing that for 37 courses.
On this sponsored episode of the podcast, Ben and Ryan talk with Bharath Thippireddy, a VIP instructor at Udemy who has taught more than half a million students. We talk about how he went from a humble Java developer to one of Udemy’s top instructors (and a budding movie star!). Along the way, we discuss whether Java or Python is better for beginners and how to balance theory with syntax.
Episode notes:
Like a lot of today’s content creators, Bharath got his start posting videos on his Youtube channel in 2012.
Today, you can find all of Bharath’s courses on his Udemy page.
You can find out more about Bharath from his website or connect with him on LinkedIn.
Udemy is one of our launch partners for our online course recommendations.
Congrats to Lifeboat badge winner desertnaut for their answer to What is the meaning of exclamation and question marks in Jupyter Notebook?.
The post From writing code to teaching code (ep. 545) appeared first on Stack Overflow Blog.
Christine Ryu, Engineering Lead at fintech platform Flourish, joins the home team to talk about how technology is transforming finance for everyone from big banks to individual consumers. Christine explains what it’s like to move from Goldman Sachs to a tiny startup, how legacy tech stacks lead to Frankencode, and what an acquisition taught her about build vs. buy and good vs. perfect.
Episode notes:
Flourish is a fintech platform for registered investment advisers (RIAs) that was recently acquired by MassMutual.
After studying computer science at Carnegie Mellon, Christine spent almost 12 years at Goldman Sachs, where she was VP of fixed systematic marketing making, responsible for automating electronic trades of interest-rate products like US Treasury bonds and interest rate swaps.
Christine’s time at the world’s second-largest investment bank gave her a healthy wariness of Frankencode, the scourge of legacy stacks everywhere.
Find Christine on LinkedIn.
Shoutout to Lifeboat badge winner amirali for their answer to I can’t set up JDK on Visual Studio Code.
TRANSCRIPT
The post “Move fast and break things” doesn’t apply to other people’s savings (Ep. 544) appeared first on Stack Overflow Blog.
Can you believe we’re almost a third of the way through 2023? While it still feels like the year just started, we’d like to kick things off by celebrating five of the sites on the Stack Exchange Network that turned ten this quarter.
I love the anniversary celebrations on the platform because it’s an opportunity to connect a bit deeper with some of the moderators and community members on the network. As in past quarters, I’m always blown away by the depth and breadth of knowledge across all of the sites on Stack Exchange. So here’s a little spotlight on five of those communities:
English Language LearnersEnglish Language Learners Stack Exchange (ELL) has a unique history. They are actually an offshoot from another one of our Stack Exchange sites, English Language and Usage (ELU). While ELU is geared towards linguists and etymologists, ELL is a site geared towards people whose first language is not English. As one of the ELL moderators, Laurel, pointed out, “Even though the site is a sister site of ELU, it’s really come into its own. The top participants are different and they have their own norms.”
Moderator David Siegel mentioned, “We do much less referencing old posts than other sites. We get a lot of questions about mixing tenses. We have perennial topics and not perennial answers.” Resources for Learning English is an older post that community member, ColleenV, is really proud of the community for maintaining and updating over the years. The community is also fond of canonical posts, including What’s perfect and how to use it and How it works vs How does it work. ColleenV also points out that, “ Interacting with learner’s questions can sometimes offer insights about English to native speakers. Many of our questions are about things that native English speakers just know intuitively, but don’t really know the why behind it.”
The moderators are really proud that this is a community that goes out of their way to help others. It’s really easy just to look at questions and answers, but if you’re poking around on ELL it’s worth taking a look at the comments too. Community members tend to leave different possibilities and alternative suggestions there to help question askers out and get to the core of the problem they are trying to solve.
Magento Magento Stack Exchange is a Q&A community for people who use the e-commerce platform Magento. Magento happens to be an open source ecommerce tool, so as moderator Sander Mangel put it, “the community needed to rely on each other when the product launched.” Moderator Marius chimed in, “Magento appeared out of nowhere and was different, architecture and code-wise.” One can even become a Magento Certified Developer.
When the site was going through the Area 51 process, the word was spread to people using the Magento product so they’d join and help with asking and answering questions. A lot of the early members are still active. The community is still going strong with an average of 18K visitors a day. Marius attributes the continued participation on the site to the continued evolution of the product and also experienced users going back to find answers to actions they don’t use as frequently. “People probably go to the deep dark corners of the site and find new things. Sometimes people may forget. I searched once and found the perfect answer and found out that it was from me.”
Sander Mangel also pointed out that the continued high traffic is also in part to junior developers who are using Magento for the first time. “They are the new generation of community members.” As moderator, Amit Bera put it, “ Everyone is connected to each other. That’s the good thing about Stack Exchange. We’ve connected people around the world.”
Reverse EngineeringReverse Engineering Stack Exchange started as a subreddit. The community there was finding that the quality of posts and replies wasn’t what they were hoping for. Several community members, including Rolf Rolles, who’s a well-known reverse engineering expert, took an application to Area 51. Moderator Igor Skochinsky shared that Reverse Engineering SE is now the place for questions to be asked and answered, while the subreddit is mostly for sharing blog posts and news related to reverse engineering.
For those not familiar, reverse engineering is the act of dismantling a product or object to understand how it works. The community is a good balance of both professionals and hobbyists. You can find out everything from where to get malware samples to analyze to what PLT/GOT is.
Moderator 0xC0000022L shared that since there is prerequisite knowledge needed to ask meaningful questions, the community tries to counterbalance that barrier to entry by welcoming new members with comments and guiding them on how to best improve their questions.
The current moderator team is comprised of community members 0xC0000022L, Igor Skochinsky, and julian. They are extremely grateful to former moderators Peter Andersson, asheeshr, and Ange as well as the larger community for all of their contributions over the years.
Sustainable Living If you are looking to reduce your carbon footprint, then Sustainable Living Stack Exchange is the place to go. Moderator LShaver describes the community as eclectic. “If you look through our top questions and answers, you’ll see that we’ve got some folks who are experts in forestry and homesteading, others with a keen eye for data analysis, some electronics experts, and of course, some programmers (since this is Stack Exchange!).”
LShaver also points out that some of the best answers on the site lay out multiple ways to solve a problem, balanced arguments for each alternative, and even edge cases where a less obvious choice may be the best one. How effective is turning a car’s engine off while standing at a traffic light and does a dishwasher save water in the long term.
Indeed, you’ll find the answers to your burning questions on recycling, solar-power, composting, and so much more. LShaver said, “ What makes me proud of the community here is that so many of our questions come from folks who have heard some things about sustainability but want to dig deeper to make more informed choices. And the answers consistently come from people who have thought deeply about these things and want to pass on that knowledge in a way that’s backed by data and sound logic.”
Tridion While Tridion Stack Exchange just turned ten, the community is much older than that. Moderator Nuno Linhares shared that the history of the community and the Tridion product go hand in hand.” It is a 25-year-old community. One of the early content management systems. The community is mostly developers who worked with the product.”
The community was originally formed as a forum. A number of the members there were also active on Stack Overflow. They realized over time that they had enough content to be their own site, and when Area 51 opened up, they were excited to have the community more firmly embedded in the Stack Exchange network. A number of those founding community members were also Tridion MVPs.
While some of the early community members are still here, Nuno Linhares shared that new members joining the community is what has helped sustain the site during its first decade. “The transition that we’ve seen with the new generation of developers. We were a small, tightly knit group, and once we were on Stack Exchange, we grew, and new people were asking intelligent questions we hadn’t thought of before.” Questions about SDL’s Digital Experience Accelerator (DXA) have been popular since the beginning and new questions continue to be posed.
While each of the communities on the Stack Exchange network is unique and has their own audience and community norms, Nuno Linhares summed it up beautifully when he said this of Tridion, “If you know developers, you know they are passionate.” Developer engagement is what made this community special. You were talking directly with the source and having deep conversations with the source.” All of the communities on Stack Exchange are made of passionate subject matter experts who want to share their knowledge and learn from other experts. That spirit is something I’m always humbled by.
To our communities celebrating their first decade on Stack Exchange, we all raise a glass to you.
The post Five Stack Exchange sites turned ten years-old this quarter! appeared first on Stack Overflow Blog.
Welcome to ISSUE #167 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: Are clouds moving in-house? Can you quit to avoid a PIP? What’s the best way to change your mindset to include accessibility?
From the blogDeveloper with ADHD? You’re not alone. stackoverflow.blog
Is there a connection between programming and ADHD? And could it be that people with ADHD are particularly well-suited to programming careers?
Are clouds having their on-prem moment? stackoverflow.blog
While public cloud usage continues to grow, an increasing number are also moving to on-prem private clouds (sometimes even owning and operating their own hardware).
How edge functions move your back end close to your front end stackoverflow.blog
Serverless functions have made computing seamless and fast. But for worldwide audiences, you need to get closer to your user to overcome latency.
Authorization on Rails (Ep. 540) stackoverflow.blog
Sam Scott, cofounder and CTO of Oso, joins the home team to talk about what makes authorization a challenge, the difference between authentication and authorization, and what zombies taught him about web development.
Shorten the distance between production data and insight (Ep. 541) stackoverflow.blog
On this sponsored episode of the podcast, we talk with Stanimira Vlaeva, Developer Advocate at MongoDB, and Fredric Favelin, Technical Director, Partner Presales at MongoDB, about how a serverless database can minimize the distance between producing data and understanding it.
Accelerate Your API Testing promotion
High quality. Fast. Cheap. In the ideal scenario, dev and testing teams work to deliver high-quality applications; on schedule, under budget, and error-free. Check out this e-book to learn about best practices you should add when you are API mocking.
Interesting questionsWhat’s the correct way to do pair programming? softwareengineering.stackexchange.com
“There isn’t just one perfect way to do this. But doing it only because we’re supposed to do it is definitely wrong.”
What is the origin of “in the zone” or what “zone” is this about? english.stackexchange.com
You ever get so good at something that Rod Serling started narrating it?
Quitting instead of accepting Performance Improvement Plan? workplace.stackexchange.com
Quitting is actually the same thing as not accepting in this case.
How much slower was the 286 in protected mode? retrocomputing.stackexchange.com
Move over slow TV; here comes slow computing!
Links from around the webLast baseline alignment web.dev
All major browser engines now support the latest CSS feature, last baseline alignment!
Why your consciousness depends on the low-entropy early universe psyche.co
The laws of physics suggest that a “time-reverse twin” is possible. What the heck is that?
How I broke into a bank account with an AI-generated voice www.vice.com
Generative AI is all the rage these days, and the more we experiment with it, the more we have to be careful about what is real and what isn’t.
Keys to an accessibility mindset www.smashingmagazine.com
Accessibility can seem daunting, but it doesn’t have to be!
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #167: Programmers and ADHD appeared first on Stack Overflow Blog.
Dr. Jeannette (Jamie) Garcia, Senior Research Manager of Quantum Applications and Software at IBM Quantum, tells Ryan about IBM’s 433-qubit quantum computer and the real-life applications of quantum computing today.
Episode notes:
A chemist by training, Jamie serves as Senior Research Manager of Quantum Applications and Software at IBM Quantum, which offers cloud access to advanced quantum computers capable of solving highly complex, highly interconnective, and dynamic problems.
Learn about the superconducting qubits IBM Quantum uses to program quantum computers. (Need to back up a bit? Learn what a qubit is.)
Jamie explains how a heavy hex architecture allows IBM to limit crosstalk between qubits to ensure coherence times long enough to complete practical calculations within hours, not years.
IBM Quantum’s Qiskit Runtime allows users to optimize workloads and efficiently execute them on quantum systems at scale.
As you might expect, Jamie and her colleagues are already thinking hard about the intersection of quantum and AI. Learn about System Two, IBM’s next-generation quantum system.
Connect with Jamie on LinkedIn or Twitter.
Congrats are in order for Stellar Question badge winner Dmitry z for asking How can I use environment variables in docker-compose?.
TRANSCRIPT
The post The nature of simulating nature: A Q&A with IBM Quantum researcher Dr. Jamie Garcia (Ep. 543) appeared first on Stack Overflow Blog.
SPONSORED BY INTUITAI has become the core of everything we do at Intuit.
A few years ago, we set out to embed AI into our development platform with the goal of accelerating development velocity and increasing individual developer satisfaction. Building AI-powered product features is a complex and time-consuming process, so we needed to simplify it to enable dev teams to do so with speed, at scale. We found success in a blended approach to product development—a marriage of the skills and expertise of data, AI, analytics, and software engineering teams—to build a platform powered by componentized AI—what we at Intuit refer to as Reusable AI Services (RAISE) and Reusable AI Native Experiences (RAIN). These allow developers to deliver new features for customers quickly and build and integrate AI into products without the typical pain points or knowledge gaps.
Today, it’s not just our customers who benefit from our AI-driven technology platform; our developers do too. Whether it’s building smart product experiences, or keeping design consistent across multiple products, our investment in a robust AI infrastructure has made it possible for technologists across the company to build AI capabilities into Intuit products at scale for our more than 100 million global consumer and small business customers.
In this article, we’ll share Intuit’s journey to democratizing AI across our organization, along with lessons learned along the way.
Simplifying the path to integrating AIIn the beginning, when our developers wanted to add AI features to their projects, they couldn’t just plug in a library or call a service. They had to reach out to our data scientists to create or integrate a model. Most machine learning (ML) models are built on a bespoke basis because data is typically specific to a process or domain and doesn’t translate well outside of the identified scenario. While this is changing with multi-modal AI, in practice most systems still train on a specific corpus where they are expected to perform (images, text, voice, etc).
We realized that in order to make it easier for our developers to integrate AI just as they would with any other feature or component, we had to overcome three key challenges:
- Cross-domain communication
- Data quality standards
- Process improvements
Cross-domain communication: Getting devs and data scientists on the same page (and tech stack)Because product development teams work in different ways, aligning on an inclusive, common language when discussing how to integrate AI into the development process was key to fostering collaboration.
Software engineers and data scientists use different vocabulary in their day-to-day work. Data science terminology, for example, is very precise, especially around concepts like model performance, and can be difficult for non-experts to understand. Data teams might use terms like ROC (receiver operating characteristic curve), macro-F1, or hamming loss. Similarly, software engineers are usually focused on durability, scalability, and behaviors of distributed systems. Such technically-specific language can lose meaning in translation.
Simplifying such technical terminology—and having good documentation to explain what it means—made it much easier for developers and data scientists to communicate. Over time, developers will pick up new knowledge as their domain-specific comfort level improves. But we don’t want every developer and data scientist to have to learn a whole new set of jargon just to get started.
To address this, we adjusted the way we communicated based on context: using precise language when necessary (for accuracy purposes), and more approximate verbiage when the same message could be conveyed through more accessible terms. For example, when data scientists described data entities, we found that it was faster for engineers to understand once these were translated into rows, columns, and fields, as well as into objects and variable values.
We also found that mapping complex topics to business-specific terminology helped get everyone on the same page. For example, translating terms like classification, regression, and propensity scores into business use cases, such as pricing predictions or likelihood to resubscribe, made the concepts more accessible. Ultimately, we found that investing in finding a common ground and devising a more inclusive approach to communication resulted in better collaboration.
Equally pivotal to our success was bridging the worlds of software developers and data scientists by seamlessly integrating AI into existing processes. We had to find a way to support technology stacks our developers were accustomed to, so we mapped interfaces in the world of AI onto constructs they were familiar with. We built continuous integration/continuous delivery (CI/CD) pipelines, REST (Representational State Transfer) and GraphQL APIs, and data flows to build confidence in the platform’s integration across various domains.
With everyone speaking the same language and working in the same workflows, we turned our attention to the data we rely on to create AI-driven features.
Data quality: Being good stewards of data means aligning on standards of qualityAs a fintech company that deals with customers’ sensitive information, we have a higher bar for data access than may be the standard in other industries. We abide by a set of data stewardship principles, starting of course with the customer’s consent to use their data.
While technologists are eager to leverage AI/ML to deliver its benefits to customers, using it to solve the right problems in the right ways involves nuanced decision-making and expertise. While traditional API integration and state management in a distributed microservices world is already enough of a challenging task for most engineering teams to handle, AI-driven development requires a different level of complexity: identifying the optimal use cases, making sure the data is available, and capturing the right metrics and feedback.
But at the heart of AI/ML is data, and that data needs to be good to get good results. We aligned on a process of storing and structuring data, creating feedback loops, and systematically building data quality and data governance into our platform.
Having clean data was a non-negotiable—we couldn’t allow our core data to be polluted. At the same time, speed was crucial. These two factors can sometimes come into conflict. When they did, we decided to handle things on a case-by-case basis, as it quickly became clear that a blanket policy wouldn’t work.
Once an ML model has been trained and put into production, that isn’t the end of its need for data. ML models need a feedback loop of data signals from the user to improve their predictions. We recognized that this was new territory for some of our developers, and that they needed to account for more time for the models to gather results. Once developers got used to this, feedback loops became better integrated into the process.
However, the developers creating those loops also needed to have access to data. Most of our data scientists are used to dealing with writing big, complex SQL queries. However, you can’t expect an engineering team that wants to leverage ML in their daily work to train an algorithm to write highly complex SQL queries against a back end Hive table, as they may not have the same experience. Instead, we set up GraphQL or REST API endpoints that allowed developers to use a familiar interface.
We had a shared language, and we had an understanding of how to use data in our features. Now we needed to tackle the hardest and most time-consuming portion of feature development: development processes and the people in them.
Process deficiencies: This meeting could have been an APIIn the past, when a developer wanted to build a new feature with AI, the process went something like this:
- Developer has an idea (e.g., an AI-powered autocomplete).
- Developer speaks to the product manager to see if it’s something customers would benefit from.
- Product manager speaks to a back-end data scientist to find out if the data is available.
- Product manager speaks to front-end and back-end engineers to see if the relevant text field can be modified.
- Back-end engineer speaks to the data scientist to find out how to connect the data.
- Developer builds the feature.
We set out to streamline the process, enabling dev teams to build AI-powered features in a fraction of the time, as follows:
- Introduced rigorous standards for software integration, including proper syntax and semantics for describing how different types of software interact with each other.
- Built self-serve software components and tooling to make it easy to consume and implement those standards.
- On an ongoing basis, we’re building discovery mechanisms so that these components can be easily found and consumed.
So how does this improved process work in practice? Using the same example of an AI-powered autocomplete, we would provide the developer with a UI component that automatically takes user inputs and feeds them into our data lake via a pre-built pipeline. The developer just adds the UI component to their front-end code base, and the AI immediately starts learning what the user has typed to begin generating predictions.
Today, if an engineering team thinks a feature is valuable, data science leadership provides access to the data, algorithms, facilities to train the algorithm, and anything else they need from an AI or data perspective. No more waiting for months on a Jira request—developers can just go in, do the experiment, get the results, and find out quickly whether their feature will deliver value to the customer.
After AI integration, solving for scaleOnce we managed to successfully integrate AI into our development platform, the next question was: How do we scale this across our organization? It can take several months to develop a complex ML model from end to end. When we looked at our processes, we realized that we could make improvements and optimizations that would bring that down to weeks, days, and even hours. The faster we can build models, the more experimentation we can do and the more customer benefits we can deliver. But once we began to scale, we ran into a new set of challenges.
The first challenge was reusability. As mentioned previously, a lot of AI/ML features developed today aren’t reusable because models trained on data specific to a single use case don’t tend to generalize outside of that domain. This means developers spend a lot of time rebuilding pipelines, retraining models, and even writing implementations. This slows down the experimentation process and limits what an organization can achieve.
On top of that, since development teams don’t necessarily know what has already been built, they might end up building something that already exists. We uncovered our second challenge: duplication. By the time we had dozens of teams building data pipelines, we realized a lot of duplication was going on, and solutions that worked well for one group couldn’t scale across an entire organization.
This is how we arrived at Reusable AI Services (RAISE) and Reusable AI Native Experiences (RAIN). Software developers reuse components all the time. There’s no need to reinvent the wheel if there’s a method, class, or library that does part of what you’re trying to do. How could we apply reusability into our platform to solve for scale with AI?
Eventually, we realized the level of AI adoption and scalability we wanted was only feasible with a platform approach. We set out to identify solutions with potential for a broader set of applications, and invited teams to collaborate as a working group to develop scalable solutions. Getting the right people in the same room enabled sharing and reuse to drive innovation without duplication. We started building cross-cutting capabilities to be used across a range of different use cases for any team focused on building innovative new AI-driven products and features.
A truly AI-driven platform: making it RAISE and RAINThe objective was simple: create the foundational building blocks developers need to build AI into our products with speed and efficiency, while fostering cross-functional collaboration and simplifying approval processes. After addressing the roadblocks that were slowing us down—the different ways our teams spoke about their work, improving data quality, and streamlining processes—we were able to take our componentized AI services and turn them into RAISEs and RAINs that our developers could then integrate into Intuit’s end products, building smart and delightful customer experiences.
Our new platform, with AI at its core, provides developers with a marketplace of data, algorithms, and models. We standardized the metadata that developers and data scientists contributing to every model, algorithm, and service so that they are visible and understandable through our discovery service. We even use this metadata to describe the data itself through a data map, making it easy for developers to search the platform and see if what they need is already available. The platform also picks up updates and new releases and continuously prompts the development process to ensure AI-powered features provide the best possible customer experience. Today, AI-driven product features that used to take months can now be implemented in a matter of days or hours.
Our journey to democratized AI has not been a fast or simple one. It has required a complete change of mindset and approach. Has it been worth it? Absolutely. Aside from the compelling customer and business benefits, our data scientists have become better software engineers and, in turn, our engineers have developed a richer understanding of the limitations and possibilities of AI and how it can make an impact.
Fundamentally, we believe that democratizing AI across an organization empowers development teams to build products that deliver outstanding customer experiences. However, the journey to reach democratized AI is not a fast or simple one: it requires a complete change of mindset and approach for most organizations.
Was it worth it? Absolutely. Without our commitment to democratized AI, it would not have been possible for our development teams to deliver smart product experiences. It removes barriers to collaboration and ultimately leads to a virtuous cycle for developers and data scientists alike that’s driving innovation with speed at scale for our consumer and small business customers.
The post How Intuit democratizes AI development across teams through reusability appeared first on Stack Overflow Blog.
Although a lot has changed since Stack Overflow launched in 2008, one thing has not: Stack Overflow continues to help people find the answers they need when they need them. Our platform supports millions of the world’s most active developers and technologists who visit every month to ask questions, learn, and share technical knowledge. Our leading SaaS offering, Stack Overflow for Teams, empowers people to find what they need to develop some of the world’s most crucial technologies.
A consistent history of innovation and growthWhat started as a popular Q&A site has evolved over time to be one of the most valuable destinations for the world’s current and next generation of technologists. We continue to evolve and innovate to fulfill our role as a critical partner in a developers’ personal and professional journey.
With Stack Overflow for Teams, we’ve seen customers use the platform for helping onboard new employees, driving InnerSource initiatives, enabling cloud or platform migration efforts, as a self-serve help center to reduce tickets, and so much more. Since launching Stack Overflow for Teams in 2018, we have added more than 15,000 customers ranging in size from global enterprises to cutting edge startups. Developers and technologists love our Teams platform because it reduces their own disruptions and increases their focus on innovation.
A snapshot of some of the enhancements we’ve made to the platform since its launch include:
- Collections: Group related knowledge by topic or use caseIntroduced in May 2020, Collections allow you to group together related knowledge, helping to create an even better knowledge-sharing experience. Questions and long-form content can be arranged within a Collection so that users follow them in a specific order or not. It’s up to you.
- Articles: Long-form knowledge simplifies documentation In August 2020, Teams expanded beyond our Q&A foundation to support long-form content through the introduction of Articles. Articles allow for the creation and sharing of long-form content within Teams.
- Content Health: Programmatically flag old and inaccurate knowledge In November 2021, Business and Enterprise Teams received a boost in ensuring their knowledge is current, relevant, and accurate through the addition of the Content Health feature. Content Health is available in our Business and Enterprise plans.
- Enhanced Dashboard: Better insights into how your organization uses knowledge With the launch of the Enhanced Dashboard and end-of-year leaderboards in 2022, organizations can monitor trendlines, see which tags are popular, which questions and answers have been viewed the most, who their top contributors are, and make decisions to help close knowledge gaps.
- Minimize context switching by integrating Stack Overflow for Teams into existing workflows We updated our integrations with Microsoft Teams and Slack over 2021. The second version of the MS Teams integrations minimizes context switching, provides a personal app with tailored knowledge, and automates notifications. The latest version of our Slack integration allows users to ask questions to Stack Overflow for Teams directly from their chat window.
- Enhanced Security: Certifications for the modern workplaceSince 2020, Stack Overflow has completed annual SOC 2 Type II audits and added ISO27001 certification for its Enterprise plan in 2022. We expect the Business plan to achieve SOC 2 Type II starting in summer 2023.
The road ahead: New pricing and structureStack Overflow continues to innovate and invest in the Stack Overflow for Teams product and it has been recognized across the industry winning in Best software-as-a-service from the Cloud Awards, Best Developer Collaboration & Workflow Tools from the DEVIES, and most recently placing in G2’s 2023 Top 100 Best Software Products and Top 50 Best Content Management Products lists.
Stack Overflow is dedicated to providing additional value to our customers—and will continue to do so as we expand the platform offerings over the next several quarters. As those enhancements increase, so do the resources needed to keep one of the world’s most visited platforms functioning at the highest levels needed. As such, Stack Overflow for Teams is increasing its price across all tiers by approximately 10%. New prices take effect on or after April 1, 2023. Customers who sign up before April 1, 2023, will continue to benefit from today’s current price structure.
The post New pricing for Stack Overflow for Teams appeared first on Stack Overflow Blog.
Juan Linietsky, cofounder and lead developer of the Godot Engine, joins the home team for a conversation about what led him to create an open-source game engine, how open source is shaping game development, and the well-worn path from playing video games to learning to build them.
Episode notes:
W4 Games is dedicated to strengthening the open-source Godot Engine, a cross-platform game engine for 2D and 3D games. Their mission is “to help the video game industry reclaim their control of the technology powering their games and reverse a dramatic trend where they have to rely on proprietary solutions from an ever-shrinking number of vendors.”
To start learning more about Godot, explore some of the best games made with Godot or join the community.
Connect with Juan on Twitter, GitHub, or LinkedIn.
Today’s Lifeboat badge winner is Martijn Pieters for their answer to ‘While’ loop one-liner.
TRANSCRIPT
The post The open-source game engine you’ve been waiting for: Godot (Ep. 542) appeared first on Stack Overflow Blog.
We were supposed to release this feature three weeks ago.
One developer got caught in a framework update. Another got stuck reorganizing the feature flags. A third needed to spelunk a long-abandoned repository to initiate the database changes. The team is underwater. Every feature release will feel like this until we get a few weeks to dig ourselves out of tech debt. We have no idea how to even get the business to consider that.
Does this sound familiar? It’s a disheartening conversation.
But we often predispose ourselves to this situation. How? We try to get businesspeople, designers, product managers, and engineers onto the same page by using the phrase “tech debt.” But that phrase puts us on completely different pages.
Ask someone in tech if they’ve heard of tech debt, and they’re likely to respond with a knowing sigh. Now ask them what it is. Do this ten times, I dare you. How many different answers do you get? Three? Four? Seven?
Everybody associates the term with a feeling—frustration, usually—but they don’t have a precise idea of where that feeling comes from. So they slap the term onto whatever happens to bother or frighten them. Designers say it means the design can’t look the way they planned it. Product folks lament how it means they lose three weeks and get no features out of the deal. Engineers? Their answers vary the most, but often they’ve got something to say about “bad code.” We’ll return to why “tech debt equals bad code” is such a scourge, but first we have to address the effect of a bunch of different people defining the same term differently in the first place.
Here’s the effect: the minute we trot out the term “tech debt,” everyone is upset but no one is listening. Each conversant assumes they know what we’re all talking about, but their individual pictures differ quite a bit. It sounds to the business like the engineers are asking for three weeks free from the obligation to release any features. They remember the last time they granted those weeks: within a month the team was underwater again. When businesspeople don’t want to grant a “tech debt week” because they saw with their own eyeballs that the last one improved the team’s capacity zero percent, how can we expect them to grant us another one with alacrity?
We, the engineers, have to examine our terminology. And we can find that terminology by dissecting what we mean when we say “tech debt.”
Tech debt is more than just bad codeEquating tech debt to bad code allows us to fall into traps. It allows us to assume that the prior developers just sucked at their jobs—which is uncharitable, but fine, until we realize that there was actually a constraint we didn’t know about. This constraint explains the loathsome characteristics of this code, and it also prevents us from doing our own genius solution.
I once worked on a team that complained ad infinitum that customer information required a query that drew from two different tables. The team assumed that the structure remained in place because of inertia or because changing the database structure had backward compatibility implications. After spending a non-negligible amount of time bashing the database design and dreaming up ways to fix it, the team learned that their plan was…illegal. For privacy reasons in their industry, it’s illegal to store these two particular pieces of personally identifying data in the same table. Luckily, a product manager happened to mention the situation to a lawyer at the company before the engineering team got very far, or it might have been a showstopping compliance issue.
Equating tech debt to bad code also allows us to believe that if we just write good enough code, we won’t have tech debt. So we don’t spend time eliminating any. There’s no need to revisit, document, or test this code; it’s just that good. A year later, we’re back where we started. Whoops.
Equating tech debt to bad code also allows us to conflate “this code doesn’t match my personal preferences” with “this code is a problem”—which, again, is fine, until we’re under a time constraint. We spend “tech debt week” doing our pet refactors instead of actually fixing anything. Engineers love tech debt week because they get to chase down their personal bugaboos. The thing is, those bugaboos rarely intersect with the code’s most pressing maintenance challenges. So when each engineer finishes their gang-of-four-fueled refactoring bender, the code is no easier to work in than it was before: it’s just different, so no one besides the refactorer knows it as well anymore. Fantastic. A+. No notes.
In all seriousness, this is a huge reason that spending three weeks paying down tech debt, carte blanche, often does little or nothing for the team’s velocity after those weeks have ended.
To fix these problems, choose something measurable to evaluate the quality of the system. My recommendation: maintenance load. How much time and effort are developers spending on tasks that are not adding features or removing features? We can talk to folks outside the engineering team about that number. If we have six developers but half of our work is maintenance work, then our feature plan can only assume three developers. Business people think of engineers as expensive, so this framing motivates them to help us decrease our maintenance load.
We can also track that number and determine how fast it grows over time. The faster our maintenance load grows, the more frustrations we can expect. Zero growth means that we can always maintain the system with the same proportion of our engineering team.
Reclaiming your timeHow do we minimize maintenance load growth? With good code stewardship practices. We rarely reward, recognize, or teach code stewardship the way that we do feature development skills. But code stewardship skills—documenting systems, recovering context from code, and designing for future changes—make the difference between a team that hums along for a decade or more and a team that repeatedly mires itself in declarations of code bankruptcy, rewrites, and despair.
The Holy Grail? Negative maintenance load growth: the kind of growth that makes our code more maintainable over time instead of less. The Grail requires even more of the team than a healthy quotidian code stewardship routine. It requires us to look at individual maintenance tasks, track their origins, and address those problems at the source. These chores,backed by empirical evidence, give us something concrete to discuss in meetings about tech debt.
Are we performing lots of routine library or framework updates right now? Maybe we need to explicitly set aside time on a recurring basis to complete those. The more these pile up, the harder it becomes to debug the interactions between releases of different libraries. And the less programmers perform these, the more out of practice they remain—which makes the update rockier and more painful at the last possible second, when the update becomes mandatory.
Are we reaching into abandoned repositories and figuring out how to make a change? Maybe we need to devote effort to recapturing information about how those repositories work. It’s common for development to become much harder after some seminal team member leaves because it turns out they knew a lot of critical information that wasn’t written down or organized anywhere. I call this a context loss event, and we have no idea how maintainable a code base really is until it survives one of these. After a context loss event, developers need to proactively assess and repair the damage done to the team’s shared knowledge before unfamiliar parts of the code base become dark and scary.
Are we constantly working around an architectural choice from the past based on assumptions about our domain that are no longer true? Maybe we need to create and prioritize a ticket for rearchitecting that. A resilient code design considers what types of changes the team expects to make in the future, and it allocates flexibility in those parts of the code. As with any task that involves predicting the future, sometimes we get it wrong. In those cases, we might need to change our design. That may require a dedicated effort.
How do we identify and prioritize chores like these? I have a whole self-paced online course about that, but even focusingon maintenance load in units of specific chores, rather than a unitary towering thundercloud of “tech debt,” gives us a better place to start addressing it.
We want feature development to feel smooth and effortless. The longer we put off maintenance work, the less smooth and effortless feature development will be. Rather than sweep all of those tasks under a rug called “tech debt” and then occasionally ask for time to deal with it as one unit, we can track what specific elements of the system force feature development to take longer, measure them in terms of the amount of developer effort that they require, and then negotiate their completion as individual tasks with attractive outcomes for developer capacity. We’re no longer framing them as an opaque and uncertain cost. We’re instead framing them as clearly circumscribed investments in our ability to produce impactful features. That conversation puts folks on the same page. It also increases the likelihood that:
- Engineers can allocate specific time to do the maintenance work
- Engineers will even be recognized for doing the maintenance work
- The maintenance work, having been selected from the real reasons that feature development slowed down, will actually improve the feature development experience for the future
And that makes the conversation about tech debt a lot less disheartening; It might even make it hopeful.
The post Stop saying “technical debt” appeared first on Stack Overflow Blog.
We’re in a unique—albeit confusing—moment in history.
“We’ve started 2023 staring down the barrel of a confluence of challenges unlike any other in our lifetimes,” said United Nations Chief António Guterres during the General Assembly in New York on February 6. “Wars grind on. The climate crisis burns on. Extreme wealth and extreme poverty rage on.”
Meanwhile, the Doomsday Clock, established by the science and security board of the Bulletin of the Atomic Scientists—an organization established by Albert Einstein and others in 1945—moved 90 seconds to midnight this past January.
Against the backdrop of these existential challenges, it’s unsurprising that “open source attracted unprecedented attention from governments and the global policy community,” wrote Mike Linksvayer, head of developer policy at GitHub, back in the Octoverse 2022 report.
No matter what’s going on around us; however, it’s up to us to remain optimistic in charing the path forward.
Naturally, a lot of people in the tech sector—and developers in particular—are thinking about the power of our work in building a better future for our world. Does our industry’s open source roots serve a purpose in debugging the issues that have led humanity to this point in the first place?
COVID-19 was—and continues to be—a learning experienceConsider the enduring challenge of COVID-19 vaccine inequity, which was a contributing factor to the rise of the Omicon variant that impacted people all over the world—not just people in poorer countries.
The problem persists. As of January 2023, just 24.6% of people in low income countries have received at least one vaccine dose.
Scientists are talking about open source as a pathway for vaccinating people against the disease in regions lacking vaccine access, demonstrating the power of continued, persistent, and enduring collaboration. Regardless of what else was going on, the scientific community had humanity’s back from day one of the outbreak.
“While political leaders [locked] their borders, scientists have been shattering theirs, creating a global collaboration unlike any in history,” wrote Matt Apuzzo and David D. Kirkpatrick for The New York Times in April 2020.
“Never before, researchers say, have so many experts in so many countries focused simultaneously on a single topic and with such urgency.”
Within a matter of weeks from the onset of the pandemic, more than 200 clinical trials were launched. By August 2021, FDA approved the first COVID-19 vaccine, with the first vaccines beginning in December 2020. And that was only the beginning.
The power of bottom-up thinkingMike Volpi, general partner at Index Ventures, pointed out in a 2019 article for TechCrunch that with open source projects, the community effectively acts as a QA department and product manager. The absence of hierarchy enables ingenuity to proliferate in a compounding, decentralized fashion.
“Open source software also ‘keeps up’ with change and executes on the promise of continuous improvement more effectively due to breadth and depth of contribution to design, development and defect correction,” elaborates Craig Heartwell who leads the Chief Architects team in the public sector for North America at Red Hat.
In December 2022, when The Linux Foundation Training and Certification Team announced a partnership with Rancher Government Solutions to address security and operational needs of the U.S. government and military, the stated objective was to work through long-standing issues related to cloud adoption and legacy application modernization.
“Government sector entities are facing many fundamental challenges in IT including cloud adoption, legacy application modernization and new application development followed by continuous integration/continuous delivery (CI/CD) in a DevSecOps environment,” explains Heartwell.
Open source is about many minds converging to establish a technical superbrain that can outpace a seemingly never-ending onslaught of problems.
“The world is incredibly dynamic, and technology and threats are evolving faster than we have ever seen before,” explains DARPA Director Stefanie Tompkins. “Status quo is a losing strategy.”
So what challenges are in the way?Regulations. Compliance. Barriers to collaboration across and within institutions.
It’s a long-standing challenge of technical innovation and policy to achieve congruence and balance with each other.
According to Code.mil, an experiment in open source at the U.S. Department of Defense (DoD), “code written by U.S. Federal government employees typically does not have copyright protections under U.S. and some international laws” due to the current regulatory picture in the country. That makes it difficult to issue open-source licenses. Governments also run into challenges motivating people internally to make open source a part of their professional responsibilities.
The good news is that there’s ongoing discussion about how to get open source right in government, with legislation opening new doors, particularly in the security industry.
With more bottom-up thinking, solutions to problems can truly come from anyone, anywhere, in spite of company layoffs, venture funding downturns, and whether or not the boss is in a good mood.
Regardless of what’s happening from an economic or commercial perspective, humanity cannot afford for knowledge sharing to slow down. There are a lot of smart thinkers, everywhere in the world, whose brilliance has a place in steering our collective future.
To learn more about how leading technology companies, of all sizes and types, use Stack Overflow to support knowledge-sharing and problem-solving at high velocities, take a look at our customer stories.
The post Why governments need open source more than ever appeared first on Stack Overflow Blog.
Welcome to ISSUE #166 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: making sure your monitoring debt doesn’t drive you bankrupt, hiding malicious code within whitespace, and pondering the inevitability of numbers.
From the blogCoding 102: Writing code other people can read stackoverflow.blog
Bootcamp may have taught you to write code that works. But the next level is to write code that works with other people.
Serverless scales well, but most databases don’t stackoverflow.blog
The benefits that come from serverless computing can be lost if you have to spend your time provisioning hardware for your database.
Monitoring debt builds up faster than software teams can pay it off stackoverflow.blog
Today, it’s easier than ever for a team to monitor software in production. But it’s also easy to build up a lot of tech debt around monitoring.
You don’t have to build a browser in JavaScript anymore (Ep. 538) stackoverflow.blog
What’s new in Next.js 13, how growing demand for front-end applications has made the React codebase “ginormous,” and what’s required to support a sustainable community of open-source contributors.
A Beginner’s Guide to Getting Started in DevOps promotion
Get practical information about what DevOps is and how a collaborative culture will benefit your work and company. GitLab’s detailed list of resources and real-world examples provides you with opportunities for continuous learning.
Interesting questionsIs there a hash function that’s more expensive for an attacker than for the server? crypto.stackexchange.com
If you really want to season your hash, include both salt and random peppering.
Should serialization and deserialization be “atomic” transactions? softwareengineering.stackexchange.com
As in, either it works or it blows up.
How did the generic masculine emerge? linguistics.stackexchange.com
This is about noun and adjective forms, not basic bros.
Malicious code somehow hidden with whitespace? security.stackexchange.com
An actual code ninja spotted in the wild.
Links from around the webWhy does 0.1 + 0.2 = 0.30000000000000004? jvns.ca
Floating points, love ’em! …sometimes.
An engineering leader’s guide to tackling change leaddev.com
Change may be constant, but that doesn’t make it easy. The right engineering leader should have a plan to work with change!
The modern web’s underrated powerhouse github.com
CSS is an ever-evolving language that is a core building block of the web—and an underappreciated one!
How inevitable is the concept of numbers? writings.stephenwolfram.com
Numbers have been a core part of our culture since the beginning of recorded history. But are they inescapable?
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #166: Writing code for other people appeared first on Stack Overflow Blog.
The home team talks with Jaclyn Rice Nelson, cofounder and CEO of Tribe AI, about the explosion of hype surrounding generative AI, what it’s like to work at a startup after working at Google, and how Tribe is leveraging the power of a specialist network.
Episode notes:
Tribe is a distributed community of AI industry leaders, including ML engineers and data scientists, dedicated to helping companies apply machine learning to their business operations. Explore their case studies to see Tribe’s expertise in action.
Founder and CEO Jaclyn Rice Nelson formerly worked at Google, partnering with enterprise companies and incubating new ventures. As an early employee at CapitalG, Alphabet’s growth equity firm, she advised companies including Airbnb on scaling technical infrastructure, ensuring data security, and boosting growth with machine learning.
As we explored on our blog last year, the generative AI space has been expanding rapidly. Many of Tribe’s specialists have opted out of full-time employment, but are willing to provide companies without internal AI expertise with the skills they need to leverage this rapidly evolving technology inside their business.
Connect with Jackie on LinkedIn or Twitter.
Today’s Lifeboat badge winner is PM 2Ring for their answer to Sort a list to form the largest possible number.
TRANSCRIPT
The post ML and AI consulting-as-a-service (Ep. 541) appeared first on Stack Overflow Blog.
Cloud computing made it way easier for developers to make websites and apps without having to worry about managing their own hardware servers. Serverless computing is a new and cost-effective way that lets developers focus on code, but it can add a delay because of dynamic allocation of resources (cold starts) and the distance between end-users and data centers. Edge computing solves this problem by bringing the servers closer to the users through a distributed network of smaller server clusters, making everything faster for apps including real-time and IoT (Internet of things) applications.
Edge computing brings computation power and data storage closer to the end user, resulting in faster processing and response times. The concept of edge computing is not new; it has been used for many years in manufacturing, transportation, and oil and gas industries to process data locally and reduce dependence on centralized servers. It gained more attention as some cloud providers such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud and others, have introduced edge functions. As a result it is now possible for hobby developers to take advantage of edge computing using edge functions.
One of the key ways to take advantage of edge computing is through the use of edge functions. In this article, we’ll dive deep into the world of edge functions, exploring how they can be used to unlock the full potential of edge computing.
Edge functionsEdge functions are small, lightweight pieces of code that can be deployed at the edge of the network to perform specific tasks or functions—serverless functions deployed on the edge. They can be used anywhere to process data with low latency or trigger actions based on specific events or conditions. They allow for faster processing times, reduced latency, and improved reliability. Edge functions operate similar to a content delivery network (CDN), but they are able to run dynamic code rather than just static hosting.
Many cloud providers support edge functions in most programming languages, including JavaScript, TypeScript, Python, Java, Go, and PowerShell. However, the introduction of edge functions is not limited to cloud providers; many companies are developing and deploying their own edge functions to meet the specific needs of their industries. Each cloud provider has their own unique way of handling edge functions, so check out their documentation to learn how to take full advantage of your specific provider.
In the next sections, I’ll dive into some of the most common ways edge functions are being implemented in the software development and IoT industries, specifically with an emphasis on utilizing Netlify’s edge functions in JavaScript.
Serving static and localized contentEdge functions make it easy to serve up content like static files, HTML, and images using JavaScript. All you have to do is create a direct HTTP response from the edge function. In the example below, the edge function returns an HTTP text/html response for serving a static HTML page.
export default async (Request, Context) => {// render the page generated using JavaScriptconst html = generateHTML()// send our responsereturn new Response(html, {headers: { 'content-type': 'text/html' },})}
When you use edge functions, they’re deployed on the edge network, meaning the data you’re viewing comes from a server close to you. You can access the user’s approximate location from the geolocation data of the edge function. This is a great way to serve up localized content, like a translated version of your webpage, to the user. The following example uses the geolocation API to serve localized weather forecasts based on the location of the user.
export default async (request, context) => {// Retrieve geolocation data from context objectconst countryCode = context.geo?.country?.code || 'US'const countryName = context.geo?.country?.name || 'United States'// retrieve weather data from the APIconst weather = await getWeatherForecast(countryCode)return new Response(`The weather in ${countryName} is: ${weather}`, {headers: { 'content-type': 'text/html' },})}
Serverless backendEdge functions are great for building faster and more efficient serverless backend systems or API gateways that handle network requests. For instance, you can handle things like authentication, managing cookies, and A/B testing, which allows your main application to focus on providing a better user experience.
export default async (request, context) => {// Retrieve user data from request objectconst { email, password } = request.body// do the authenticationawait authenticateTheUser()return Response.json({ message: 'User authenticated', status: 'success' })}
Many cloud providers let you use Node.js (or its successor, Deno) functions to create your serverless backend, but it’s important to note that the functionality you have access to is limited. Most providers have their own APIs for common use cases, like geolocation.
Real-time data processing and analyticsEdge computing allows you to process data in real time by a server closer to the source of the data. Edge functions are really efficient when it comes to real-time data processing because of low latency and faster processing times. This has a wide range of applications, particularly in the IoT field. For example, you can use edge functions to analyze security video footage as it’s being captured.
export default async (request, context) => {// Get the video stream from the request objectconst video_stream = request.body// Perform video processingconst result = doSomethingWithData(video_stream)// Return the responsereturn Response.json({statusCode: 200,body: JSON.stringify({result: result,}),})}
Another great use case for edge functions is data analytics and security reinforcement. With the fetch API provided by Netlify, you can retrieve data from remote sources within the function itself, meaning you can process data and get insights in real time.
export default async (request, context) => {// Retrieve request dataconst source = new URL(Request.body.source)const data = await fetch(source)// Perform analysis on the dataconst result = doSomeDataAnalytics(data)// Return success responsereturn Response.json({statusCode: 200,result: result,})}
Process automationEdge functions are a powerful tool for automating processes in the industrial and manufacturing industry as they provide faster and more reliable automation of processes. They can be used for various applications such as quality control, maintenance, and automated decision-making. For instance, you can use the below edge function to keep an eye on inventory levels and send out alerts via email when stock is running low.
export default async (request, context) => {// Retrieve inventory data from databaseconst inventoryData = await retrieveInventoryData()// Loop through inventory data and check for low stock levelsfor (const item of inventoryData) {if (item.quantity < item.reorderThreshold) {// Send reorder alert emailsendEmail(item.name, item.quantity)}}// Return success responsereturn Response.json({statusCode: 200,body: 'Reorder alerts sent successfully',})}
While these are just a few examples, the possibilities are endless when it comes to utilizing edge functions for faster and more efficient processing.
The drawbacks of using edge functionsJust like any other technologies, edge computing and edge functions have their downsides, no matter how awesome they are for fast processing. Before you start using edge functions for your next project, here are a few things to keep in mind:
- Remote data source: A centralized database increases latency, complexity, and security concerns. If you need to fetch data from the database, the distance between the edge server and the database can slow down data retrieval and increase latency. In these cases, it might be more beneficial to opt for distributed database solutions such as AWS DynamoDB Global Table and Azure Cosmos DB Global Distribution, which replicate data to multiple regions, along with edge functions. Caching data locally at the edge can help to minimize the delay reducing the number of requests to the centralized database.
- Code and time limits: Edge functions are similar to CDN networks where identical pieces of code are deployed in different locations. So, the code size is limited based on the cloud provider. They’re not ideal for larger computational models or longer requests with response times limited to a few milliseconds.
- Vendor lock-in: Cloud providers have their own way of doing things regarding edge functions. If you switch to a different provider, you’ll probably have to rewrite your code to fit their way of handling things.
- Some security concerns: As edge computing and edge functions rely on a distributed network of servers, the number of potential attack vectors increases. This makes it more challenging to secure multiple servers and protect against cyber attacks when compared to centralized systems. But the security of edge functions mainly relies on the cloud provider you select.
Wrapping upIn conclusion, edge computing and edge functions are rapidly becoming popular in the technology industry because of their ability to provide faster and more reliable processing by bringing computation power closer to the end user. Edge functions, when implemented correctly, can significantly decrease latency, provide a more efficient serverless backend, automate processes, and improve performance in a variety of industries. As technology continues to advance and demand for edge computing increases, edge functions will become even more essential for businesses and developers looking to stay competitive in the industry. With the advancements in technology and the increasing demand for edge computing, it’s the perfect time for developers and cloud providers to explore and take advantage of the benefits of edge functions.
The post How edge functions move your back end close to your front end appeared first on Stack Overflow Blog.
SPONSORED BY MONGODBModern networked applications generate a lot of data—every business wants to make the most of that data. Most of the time, that means moving production data through some transformation process to get it ready for the analytics process. But what if you could have in-app analytics? What if you could generate insights directly from production data?
On this sponsored episode of the podcast, we talk with Stanimira Vlaeva, Developer Advocate at MongoDB, and Fredric Favelin, Technical Director, Partner Presales at MongoDB, about how a serverless database can minimize the distance between producing data and understanding it.
Episode notes:
Stanimira talked a lot about using BigQuery with MongoDB Atlas on Google Cloud Run. If you need to skill up on these three tools, check out this tutorial.
Once you’ve got the hang of it, get your data connected with Confluent Connetors.
With Atlas, you can transform your data in JavaScript.
Connect with Stanimira on LinkedIn and Twitter.
Connect with Fredric on LinkedIn. Congrats to Stellar Question winner SubniC for Get name of current script in Python.
TRANSCRIPT
The post Shorten the distance between production data and insight (Ep. 541) appeared first on Stack Overflow Blog.
Sam Scott, cofounder and CTO of Oso, joins the home team to talk about what makes authorization a challenge, the difference between authentication and authorization, and what zombies taught him about web development.
Episode notes:
Oso is authorization as a service. Check out the docs or explore use cases.
Sam’s post “Why Authorization is Hard” covered what makes authorization challenging, some approaches to solving it, and their associated tradeoffs. You can also watch Sam’s talk at PyCon US 2022. Since it’s impossible to address everything that makes authorization hard in just 5,000 words, Sam is currently at work on a follow-up article called “Why Authorization is Hard Part II.”
Sam first learned web development via Rails for Zombies, a beginner-level Rails course. In creating Oso, he tasked himself with “putting rails on authorization.”
ICYMI: Read Sam’s post about best practices for securing REST APIs or listen to his previous podcast appearance, where we talked about how Oso makes security easier for developers.
Find Sam on LinkedIn or GitHub.
Today’s Lifeboat badge winner is OscarRyz for their answer to I am trying to solve ’15 puzzle’, but I get ‘OutOfMemoryError’.
TRANSCRIPT
The post Authorization on Rails (Ep. 540) appeared first on Stack Overflow Blog.
For the better part of the last two decades, the move towards utilizing public cloud infrastructure seemed like an inevitable, one-way tidal wave. Cost to end users would fall as providers continue to scale and an array of ever more fine-grained services would allow startups to stay lean and quickly adapt to surges or disruptions in demand.
During my three years working on the Stack Overflow podcast and blog, I’ve gotten the chance to talk with lots of interesting folks working with a wealth of microservices and containers. I’ve seen the push to build infrastructure as code and the appeal of going serverless. At the same time, I’ve chatted with lots of folks in the areas of observability and service meshes, who have found a new business supporting the sprawl of interconnections that exists in modern applications.
Via https://mobile.twitter.com/forrestbrazeal/status/1612473738259316736Recently, however, I’ve noticed a new trend growing in parallel. Yes, adoption of public cloud continues to grow, with many companies still in the process of deciding what to migrate off local servers. Tons of folks gathereveryday to share knowledge about AWS, Azure, and Google Cloud across our Stack Overflow Collectives.
At the same time, however, a growing number of organizations are also carving out space to repatriate work from public providers to on-prem private clouds and, for the growing world of edge computing and machine learning, going back to the future of actually owning and operating their physical hardware on-site.
A cloud to call your ownAccording to a 2022 report by Bessemer Ventures, there has been a significant uptick in the adoption of virtual private clouds. The report suggests that, “it is becoming easier to package SaaS products and deploy them inside a customer’s virtual private cloud (VPC). This is due in part to the standardization around Kubernetes as the operating system of the cloud. This makes it easier for SaaS companies to serve a wider range of customers that may prefer to keep certain sensitive data or applications in a VPC.”
A lot of our customers using Stack Overflow for Teams Enterprise edition opt for this approach. We build and upgrade the platform for knowledge sharing and collaboration, but it’s installed in a private or on-prem location and the conversations about their proprietary code clients are discussing stay privates on-prem.
Tom Limoncelli, a technical product manager on our site reliability team, has strong opinions on this trend. “Here’s what’s really happening,” he wrote to me:
a. Running your own datacenter encourages bad practices due to lack of governance and other reasons.
b. The cloud forces/encourages better practices, such as strict governance, infrastructure as code, and fully automated CD/CD pipelines.
c. People are building on-prem clouds, which emulate those best practices because they got a taste of in the cloud.
Another way to say that is… People aren’t returning to the datacenter; they’re returning to on-prem clouds because datacenters can be frustrating.
The way Limoncelli sees it, a fully DIY approach encourages bad practices. Owners tend to treat servers more like pets than cattle, adding their own customization. After decades of that, you get a datacenter that is just one big mess of bad configuration ideas, mismatched technologies, and political barriers that prevent any of that from being fixed. The smart way to move to private cloud is to be strict about standardization. In other words, no, you can’t request a special machine with a weird ethernet connection because one person thinks it’s cool.
Cloud systems, on the other hand, provide an API to request new virtual machines in minutes, instead of a manual purchase process that took months. They install racks and racks of the same hardware configuration. They use standardized machine configs, guiding users away from bespoke configs. Costs are accounted for, which often doesn’t happen in datacenters. On the software side, the move to the cloud is an opportunity to adopt automation like a CI/CD pipeline, weaning people off of manual deployments.
Users acquire resources via an API, not by a purchase order. Governance and automation are established from the start. The combination of accessing resources by a standardized API and automatically enforced governance results in a system that is more maintainable and enforces more modern practices.
Containers will set you freeAs Nick Chase argues over at The New Stack, Kubernetes has been a powerful enabler for companies looking to gain more control over their usage of the cloud. It’s relatively agnostic about the real or virtual hardware you choose to employ because it can do a wealth of different things with the Linux kernel as its foundation.
Kubernetes was designed to make it simpler for a small group of people to manage a large constellation of applications by abstracting the underlying hardware. Barring a setup that confines your system to a scarce resource, it offers a level of resilience that customers ten years ago turned to public cloud providers for. Along with allowing users to update systems without going offline, it also offers capabilities for monitoring of services up and downstream, something that many microservice heavy organizations are now turning to third-party observability providers for.
“Kubernetes’ superpowers change the game in important ways,” writes Chase. “If you can deploy, scale and manage the lifecycle of Kubernetes, you can use it to pave over public and private cloud infrastructures, optimize costs and overheads aggressively, and treat everything underneath Kubernetes as a commodity.”
As my colleague Ryan Donovan pointed out during a recent conversation, “being able to abstract infrastructure has enabled a lot of cloud providers, but it’s also allowed folks to have those containers located anywhere — within a public cloud, on a prem server in Lithuania, or a private cloud replicated across multiple locations.” Just because your infrastructure has moved to the cloud doesn’t mean you don’t care about proximity to users and the advantages that might provide you in terms of cost or latency.
Stack Overflow has taken advantage of some of these superpowers. Max Horstmann, formerly a Staff Software Engineer at Stack Overflow, now a principal software engineer on the Azure Kubernetes Service (AKS), wrote in depth about why Kubernetes might be a good choice and how we took advantage of it inside our organization. You read his article on it or listen to his podcast below.
“If you’re starting a new project from scratch — a new app, service, or website — your main concern usually isn’t how to operate it at web scale with high availability,” writes Horstmann. “Hence, when it comes to choosing the right set of technologies, Kubernetes — commonly associated with large, distributed systems — might not be on your radar right now. After all, it comes with a significant amount of overhead.”
Despite all this, he sees value in adopting it from the start. “When you’re launching something new, your focus is typically to move fast and iterate quickly based on early feedback. Scaling is something for later. K8S is a tool that, in my view, allows you to do just that because it can accelerate your build/test/deploy loop, allows you to easily deploy and instrument different instances of your app, e.g. for split testing, customer demos etc.”
If you’re lucky enough to find product market fit and start to see a surge in customer demand, Kubernetes proves valuable in this area as well. “The problems that come with scale — fault tolerance, load balancing, traffic shaping — are already handled,” says Horstmann. “At no point will you hit that moment of being overwhelmed with success; you future-proofed your app without too much extra effort.”
This comment from a HashiCorp’s forum sums up the advantages well: “A Kubernetes cluster is a good example of an abstraction over compute resources: there are many hosted and self-managed implementations of it on different platforms, all of which offer a common API and common set of capabilities.”
A bridge between public and private cloudsThe Bessemer report cites another emerging technology trend that pairs increased cloud adoption with on-prem data. “Emerging middleware platforms are making it easier to bring the power of the cloud to the data, wherever it may be. This has played out in industries like financial services, where a wave of modern fintech infrastructure helped build bridges between the cloud and legacy banking systems. We are seeing similar bridges being built in other large industries like supply chain, logistics, and healthcare to bring the power of the cloud to these on-premise data sources.”
It’s important to define what we mean by “middleware” here. As Red Hat points out, the term dates back to a 1968 NATO conference on software engineering, where it referred to code that sat between the assembler/compiler at the bottom of the pyramid and the application logic at the top. In the world of hybrid cloud, middleware refers to an evolved version of this same idea. As Asanka Abeysiinghe, Chief Tech Evangelist at WSO2 explains in a blog, this can look like, “mega clouds that provide infrastructure as a service (IaaS)-enabled middleware capabilities via APIs, which have become the new DLLs. So, for example, message queues, storage and security policies are open for developers to consume in applications running on the IaaS (Infrastructure-as-a-Service).”
Outside the big public cloud providers, Abeysinghe sees other alternatives catching on. “Kubernetes addresses the issue of cloud lock-in by bringing an open standard to the cloud-native world, and it enables basic middleware capabilities as components. In addition, the Cloud Native Computing Foundation (CNCF) brings a rich set of Kubernetes-centric middleware, and you can find them in the CNCF technology landscape. However, if the middleware capabilities provided by Kubernetes and the CNCF are not enough for your application development, you can add custom resources by defining them in a custom resource definition (CRD) because Kubernetes is built using open standards.”
When I spoke with Abeysinghe for this article, he was quick to point out that there was no data to indicate a trend of companies moving fully away from the cloud, far from it. There are still more folks migrating onto the public cloud than off it. He estimates that 80 percent of activity is still focused on the traditional shift from local to public cloud, with another 20 percent moving in the opposite direction. But that 20 percent is important, precisely because it flows against the prevailing tide we’ve seen over the last decade.
Abeysinghe believes that there is a realization, especially at organizations with a lot of legacy hardware infrastructure, that they now have a lot of machinery sitting idle. If you’re a big bank with decades of mainframes at your disposal, utilizing only five percent of that doesn’t make much sense. “Kubernetes lets you run a private cloud that better utilizes your existing on-prem hardware.” Cloud bursting technology lets you shift to third party resources when your local hardware is maxing out.
Not to be left out of the game, public cloud providers now offer physical server racks to clients who have jobs that are more efficient on-prem, or need to remain in-house for security and compliance reasons. Companies that once helped to migrate companies off local hardware now offer server-racks-as-a-service bundled with your public cloud offering, a truly full circle moment for the evolution of compute.
Bringing AI models in-houseOne area where this trend seems particularly strong is among companies focused on artificial intelligence that work with large data sets and have created their own models. “Big cloud GPU compute is very expensive, whether it’s for training or for inference,” says Dylan Fox, founder and CEO at Assembly AI, a startup that provides AI-as-a-service to companies that are seeking natural language capabilities in their offerings but don’t want to build the models or hire a team in-house.
“We do most of our training in on-prem instances. We have a couple hundred A100 NVIDIA cards, and we recently just purchased like a couple hundred more that we have for on-prem instances used to train.” The crypto winter has been a blessing for this market, as a glut of GPUs has come onto the secondary market and prices for new and used hardware have fallen.
As David Linthcium wrote over at InfoWorld:
Companies are looking at other, more cost-effective options, including managed service providers and co-location providers (colos), or even moving those systems to the old server room down the hall. This last group is returning to “owned platforms” largely for two reasons.
First, the cost of traditional compute and storage equipment has fallen a great deal in the past five years or so. If you’ve never used anything but cloud-based systems, let me explain. We used to go into rooms called datacenters where we could physically touch our computing equipment — equipment that we had to purchase outright before we could use it. I’m only half kidding.
When it comes down to renting versus buying, many are finding that traditional approaches, including the burden of maintaining your own hardware and software, are actually much cheaper than the ever-increasing cloud bills.
Second, many are experiencing some latency with cloud. The slowdowns happen because most enterprises consume cloud-based systems over the open internet, and the multi-tenancy model means that you’re sharing processors and storage systems with many others at the same time. Occasional latency can translate into many thousands of dollars of lost revenue a year, depending on what you’re doing with your specific cloud-based AI/ML system in the cloud.
It’s not just small AI startups that want to crunch a lot of data at a low latency with homegrown models. Here’s an eye-opening quote from Protocol. “The on-prem trend is growing among big box and grocery retailers that need to feed product, distribution, and store-specific data into large machine learning models for inventory predictions, said Vijay Raghavendra, chief technology officer at SymphonyAI, which works with grocery chain Albertsons.”
Raghavendra left Walmart in 2020 after seven years with the company in senior engineering and merchant technology roles. “This happened after my time at Walmart. They went from having everything on-prem, to everything in the cloud when I was there. And now I think there’s more of an equilibrium where they are now investing again in their hybrid infrastructure — on-prem infrastructure combined with the cloud,” Raghavendra told Protocol. “If you have the capability, it may make sense to stand up your own [co-location data center] and run those workloads in your own colo, because the costs of running it in the cloud does get quite expensive at certain scale.”
Chick-fil-A had a similar experience. In a blog written by Brian Chambers, the company’s head of Enterprise Architecture, he noted that, “In researching tools and components for the platform, we quickly discovered existing offerings were targeted towards cloud or data center deployments. Components were not designed to operate in resource constrained environments, without dependable internet connections, or to scale to thousands of active Kubernetes clusters. Even commercial tools that worked at scale did not have licensing models that worked beyond a few hundred clusters. As a result, we decided to build and host many of the components ourselves.”
Their solution allowed a DevOps Team and Smart Device Support to deploy, build, and update to thousands of restaurants.
Cloud, with controlTotal spending on cloud computing is already enormous and still projected to grow over 20% this year, closing in on a half a trillion dollars. But it will be a far more varied and nuanced period of growth. “Cloud is the powerhouse that drives today’s digital organizations,” said Sid Nag, research vice president at Gartner. “CIOs are beyond the era of irrational exuberance of procuring cloud services and are being thoughtful in their choice of public cloud providers to drive specific, desired business and technology outcomes in their digital transformation journey.”
After a decade or more spent moving away from server racks, companies are finding there can be advantages to running local infrastructure for certain kinds of compute. There is also, perhaps, a generational shift at work. The engineers who cut their teeth building big public clouds inside large tech companies see now moving on to create startups or take senior roles at smaller companies that specialize in a subset of cloud offerings. What’s old is new again, but with a vast variety of new flavors and permutations to choose from.
The post Are clouds having their on-prem moment? appeared first on Stack Overflow Blog.
There’s enough of an overlap between people with ADHD (attention-deficit/hyperactivity disorder) and people who code for a living that programmers with ADHD have their own subreddit. Other subreddits abound with ADHD-related advice-givers and advice-seekers. We’ve also discussed ADHD and the broader topic of neurodivergency on the Stack Overflow Podcast, with co-host Ceora Ford describing her experience being diagnosed with ADHD and persistent misconceptions around neurodiversity in the tech community.
ADHD diagnosis rates are on the rise for both adults and kids, though as you might expect it’s tough to know whether this rise is attributable to a higher incidence of ADHD or simply an increase in the number of diagnoses made. Either way, more people are understanding their experiences and abilities through the lens of ADHD, and this includes many people who code. But is there really a connection between programming and ADHD? And could it be that people with ADHD are particularly well-suited to programming careers?
A perfect fit?Many developers with ADHD feel their job is a perfect fit for how they think and approach problems. “Coding can give ADHD brains exactly the kind of stimulation they crave,” explains full-stack developer Abbey Perini. “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.”
In addition to a revolving door of fresh challenges that can keep people with ADHD engaged, coding can reward and encourage a state of hyperfocus: a frequently cited symptom of ADHD that developer Neil Peterson calls “a state of laser-like concentration in which distractions and even a sense of passing time seem to fade away.” It’s easy to draw parallels between hyperfocus and the flow state, a distraction-free groove in which programmers, writers, musicians, artists, and other creators produce their best work (occasionally while forgetting to eat). Our paid platform, Stack Overflow for Teams, is popular with developers in large part because it helps them avoid distraction and protect the productive sanctity of their flow state.
But for every quality that makes coding perfect for people with ADHD (or vice versa), there’s another that could represent a particular hurdle. For instance, ADHD can make people more vulnerable to inattentive mistakes, missed deadlines, or unfinished projects. A perennial question on Reddit is some variation of “Programmers with ADHD, how do you stay on track?”
Combating stigma with candorThe reality is that while some forms of neurodivergence might lend themselves to certain careers (I’ve always thought that my obsessive-compulsive disorder makes me a better copyeditor, for example), individual results will continue to vary.
But it’s good news that many programmers with ADHD seem emboldened to share their experiences, offer advice, and ask for support and accommodation when they need it. And as we discussed on a recent podcast episode, more developers (and their managers) are having conversations about how to support the success of neurodiverse team members.
An open dialogue about ADHD and other forms of neurodiversity is a crucial step in dismantling the remaining stigma around neurodiversity in tech. These conversations happen best in psychologically safe environments—something for managers to take to heart, especially in a time when many of us are already feeling increased pressure thanks to industry-wide layoffs.
Making work and hiring more accessible to neurodiverse people benefits everyone in the organization. Neurodiverse people can contribute unique problem-solving approaches, an affinity for hard skills like data analysis, and a tendency toward perfectionism that can elevate overall quality, says Mariann Lowery, Product/UX Research Lead at Stack Overflow. And making the workplace more inclusive can increase employee engagement and give us a greater sense of purpose at work—whether we identify as neurodiverse or not.
The post Developer with ADHD? You’re not alone. appeared first on Stack Overflow Blog.
Welcome to ISSUE #165 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: talking quantum computers with a materials scientist, taking constructive criticism better, and tasking yourself with writing better tech specs.
From the blogThe nature of simulating nature: Q&A with IBM quantum computing research stackoverflow.blog
We chat with Dr. Jeannette (Jamie) Garcia, Senior Research Manager of Quantum Applications and Software at IBM Quantum, about their 433 qubit quantum computer and what the real-life applications of quantum computing are today.
Three layers to secure a software development organization stackoverflow.blog
This affects the individual developer writing insecure code, the engineering team blindly trusting their dependencies, and the organization thinking that their best bet is to roll their own security controls.
Engineering’s hidden bottleneck: pull requests stackoverflow.blog
CI/CD needs a CM—continuous merge—to get the SDLC moving smoothly.
The AI that writes music from text (Ep. 535) stackoverflow.blog
The home team discusses why it seems like everybody needs subtitles now, the AI that generates music from text, and a list of open-source data engineering projects for you to contribute to.
Introduction to Data Modeling Virtual Event with MongoDB promotion
Uncover the most important factors to consider when setting up your data model in MongoDB. Learn more by attending MongoDB’s free webinar on February 22nd at 11am ET.
Interesting questionsWhat do you do when you’re stuck? mathoverflow.net
When you’re missing a piece in a math proof, add it as an assumption and continue.
How to get better at taking constructive criticism? workplace.stackexchange.com
It’s not about you, it’s about your job.
Is it possible to tell the difference between a young star that is just “big” and an older red giant? physics.stackexchange.com
The color gives it away.
How can lossless compression ever exist? softwareengineering.stackexchange.com
You can losslessly compress some of the inputs some of the time, but you can’t compress all the inputs all of the time.
Links from around the webReinventing search with a new AI-powered Microsoft Bing and Edge, your copilot for the web blogs.microsoft.com
Will Bing move on up in search engine popularity with the new AI changes?
How to build a magazine layout with CSS grid areas www.smashingmagazine.com
CSS Grid can be challenging to work with, but it’s powerful!
It’s the future — you can stop using JPEGs daniel.do
The future of images is here. Check out the new formats!
Writing an effective tech spec yougotthis.io
Understanding what to build and how to build it is some of the most challenging work in software engineering. Here’s a great chat about doing just that!
If you’re curious about our other products: How to get started with Stack Overflow for Teams.
The post The Overflow #165: Your new favorite band is an AI appeared first on Stack Overflow Blog.
David Hsu, founder and CEO of Retool, joins Ben to talk about low-code and no-code tools: why some folks love to hate them and whether they really help devs work faster or just allow those of us who aren’t programmers to muck everything up. Or both! Plus: How David’s philosophy degree shaped his approach to business.
Episode notes:
Retool is a development platform that lets users—95% of whom are engineers—build internal tools quickly with a drag-and-drop interface.
Read David’s account of how Retool won early sales deals in the company’s Operator Playbook series.
Connect with David on LinkedIn.
Today we’re shouting out Stellar Question badge winner ahajib for asking How to convert a list to a dictionary with indexes as values?.
TRANSCRIPT
The post Because the only thing worse than building internal tools is maintaining them (Ep. 539) appeared first on Stack Overflow Blog.
If we are to believe the stories we hear, software teams across the industry have modern monitoring and observability practices. Teams get alerted about potential issues before they hit customers—and are able to pull up crime-show-worthy dashboards to find and fix their issues.
From everything I’ve seen these last few years, few software organizations have achieved this level of monitoring. Most teams I’ve encountered have told me they do not have the monitoring coverage they would like across the surface area of their app. I’ve seen many startups go surprisingly far with almost no monitoring at all. To those who still struggle with the monitoring basics: you are in good company.
Today, it’s easier than ever for a team to monitor software in production. There are more monitoring and observability tools available than ever before. We’re also seeing more collective understanding about monitoring and observability best practice across the industry. So why is there such a gap between monitoring ideals and monitoring reality?
What’s happening is that teams are falling into monitoring debt more quickly than they are able to pay it back. In this article, I’ll talk about what monitoring debt is, why it’s easier than ever for teams to build towards monitoring bankruptcy, and what there is to do about it.
What is monitoring debt?Most software engineers are familiar with the concept of technical debt, a metaphor for understanding how technical tradeoffs have long-term consequences. People typically talk about tech debt in terms of how the cost of refactoring, redesigning, or rewriting tomorrow allows a team to ship faster today. Tech debt, like financial debt, can be taken judiciously and paid off responsibly.
In some ways, monitoring debt is analogous to tech debt: teams can choose to underinvest in monitoring at the time of shipping code at the cost of having to go back and invest in monitoring later. From a technical perspective, monitoring debt behaves similarly to tech debt. It costs more to clean up later and requires intimate knowledge of a system that a developer may have context-switched out of. And this is assuming the same developer is around to pay back the debt!
The costs of monitoring debt are even more insidious. When a team chooses to ship code without thorough monitoring, here are the the immediate costs:
- The team needs to accept limited ability to catch issues ahead of customers, meaning the customer is the monitoring plan. This may work for some tools, but may wear on the patience of paying customers.
- The team has chosen to give up at least partial ability to quickly localize issues when they arise, meaning they are less likely to be able to fix issues quickly. This means that customers could be waiting for up to hours or days for their issues to get resolved.
What’s worse, paying back monitoring debt is often harder than paying off technical debt, since it requires both intimate knowledge of the code (what kind of behavior is normal; what are the highest-priority events to monitor for), as well as facility with the monitoring tools (how to find and fix the issues of interests given what the tools support?).
Often, the reasons teams decide to take on monitoring debt—not enough expertise; not enough time—cause them to fall deeper and deeper into debt.
Why it’s easier than ever to build towards monitoring bankruptcyToday, there are a few reasons it’s easier than ever for teams to quickly and build towards monitoring bankruptcy.
Monitoring is a highly-skilled activityMonitoring a system requires a nontrivial amount of knowledge about both the system under monitoring and how that system should be monitored using the tools.
- Setting up monitoring and observability requires knowledge of the underlying system. If you’re using something like Datadog APM, it can look like all you need to do is include a library, BUT this may often involve updating other dependencies. Even in our ~1-year-old code base with three microservices, it took an extremely senior engineer a week to hunt down the dependencies across multiple languages. And even after we set it up, though, my developers don’t have the bandwidth to set up all the dashboards we need to properly use this data. We are perpetually behind!
- The tools themselves have a learning curve. Many tools require some understanding of how to use the tools: how to instrument; how to customize the graphs. Using OpenTelemetry outside a framework that provides automatic instrumentation support has a decently high learning curve because you have to learn how to implement spans. Other observability tools advocate writing code to anticipate that you will consume the logs or traces, which requires understanding and discipline on the part of the developer. Tools that require custom dashboards often require developers to understand how to access the data they need and which thresholds mean something is wrong. Like manual transmission cars, most monitoring and observability tools today trade ease of use for control and flexibility; these tools require some facility and basic understanding of both clear monitoring goals and the underlying monitoring mechanisms.
Monitoring is best done freshThe longer a piece of software goes without monitoring, the exponentially harder it gets to monitor. First, hooking up the monitoring tool is harder for a system that is not completely up-to-date and paged-in. Any monitoring system that requires the use of a library means that there are likely compatibility issues—in the very least, somebody needs to go around updating libraries. More high-powered tools that require code changes are even harder to use. It’s already hard to go back to old code to make any updates. Context-switching it back in for tracing is just as tricky!
Second, consuming “old” monitoring data is tricky. Even if you can rely on your framework to automatically generate logs or add instrumentation, what is considered “normal behavior” for a system may have gotten paged out or left the company with past team members.
Finally, with software teams being more junior than ever before and experiencing more churn than in recent history, the chances are increasing that a different, more junior developer may be tasked with cleaning up the debt. These developers are going to take longer just to understand the codebase and its needs. Expecting them to simultaneously pick up skills in monitoring and observability, while retrofitting logging and tracing statements onto a code base, is a big ask.
Better tools have made it easier to take on monitoring debtFinally, the rise of SaaS and APIs have made it a lot harder to monitor systems. Monitoring is now no longer about seeing what your own system is doing, but how your system is interacting with a variety of other systems, from third-party payment APIs to data infrastructure. I would also say that a legacy subsystem nobody on the team completely understands also falls in this category. While traditional monitoring and observability practices made sense for monoliths and distributed services completely under one organization’s control, it is unclear how to adapt these practices when your distributed system has components not under your team’s control.
What teams need to pay off monitoring debtMy take: let’s get new tools. But in the meantime, let’s also rethink our practices.
Today’s monitoring tools are built for a world in which the developers who built well-contained systems of manageable size can get high-fidelity logging across the entire thing. We live instead in a world where software services run wild with emergent behaviors and software engineering is more like archaeology or biology. Monitoring tools need to reflect this change.
To meet software development where it is, monitoring tools need debt forgiveness. My proposed improvements:
- Make it easier to set up monitoring and observability black-box. I know, I know: the common wisdom about finding and fixing issues is that you want to understand the inner workings of the underlying system as well as possible. But what if there’s too much code in the underlying system to make this possible? Or if there are parts of the system that are too old, or too precariously held together, to dive in and add some new logs to? Let’s make it easier for people to walk into a system and be able to monitor it, without needing to touch code or even update libraries. Especially to make it possible to set up new monitoring on old code, we want drop-in solutions that require no code changes and no SDKs. And with more and more of system interactions becoming visible across network APIs and other well-defined interfaces, blackbox monitoring is getting closer to reality.
- Make it easier for teams to identify what’s wrong without full knowledge of what’s right. Today’s monitoring tools are built for people who know what they’re doing to do exactly what they need to do to fix what is wrong. Teams should not need to understand what their latency thresholds need to be, or what error rates need to be, in order to start understanding how their system is working together. The accessible monitoring and observability tools of the future should help software teams bridge knowledge gaps here.
Across monitoring and observability, we have great power tools—but what don’t we need in a “for dummies” solution? This is something we’ll need to think about collectively across the industry, but here are some starting ideas:
- We’re not building for teams that are optimizing peak performance. They’re trying to make sure that when load is high, the system does not fall over. Answering the basic questions of “is anything errors?” and “is anything too slow?” often does not require precise machinery.
- Being able to precisely trace requests and responses across the system is great, but it’s usually not necessary. For a point of reference: a friend once told me that less than five Principal Engineers at his FAANG-like company used their tracing tools.
- What is the minimum information we need for monitoring? When root causing issues, is it simply enough to get a unique identifier on which process the issue came from? I would love to see more discussion around “minimum viable information” when it comes to finding and fixing issues.
Talking more about the answers to these questions can help establish minimum, rather than ideal, standards for monitoring using the existing tools.
Bringing down the debtIn order to help teams pay off monitoring debt, we need a mindset shift in developer tools. We need more tools that are usable in the face of tech debt, monitoring debt, and very little understanding of the underlying system or tools.
Today, it would be a heroic feat for a new junior person to join a team and successfully address an incident. But we’re already seeing accounts of this in the news—and tech workplace dynamics mean we should only expect more of this to happen. Why not make it easier for a junior dev to handle any incident?
The post Monitoring debt builds up faster than software teams can pay it off appeared first on Stack Overflow Blog.
SPONSORED BY MONGODBFor applications aiming for high availability without the hassle of managing infrastructure issues, serverless computing has emerged as the next level of hardware abstraction.
Cloud computing and containers virtualized the physical servers that web and mobile apps ran on, but you still needed to provision those resources and manage how they scaled. While serverless doesn’t eliminate the server (obviously) it does mean that you don’t have to think about how your infrastructure will have to scale to support your application’s fluctuating traffic, allowing for faster development cycles by lessening the management burden.
Serverless technology is most commonly implemented via serverless functions, or functions as a service (FaaS), which are used to run business logic in stateless containers. But if you’re building an application that needs to persist data, you’ll need to connect your serverless functions to a database.
The benefits that come from serverless computing can be lost if you have to spend your time provisioning hardware or worrying about capacity planning and management as your application scales. In fact, traditional databases, (even fully-managed DBaaS), are generally not well-suited for managing the frequent yet disposable requests that come from serverless functions.
Fortunately, there are some databases that can handle the sort of workload that a serverless application produces, as they themselves are built to operate in a serverless manner.. In this article, we’ll dive into the perils of working with a database that isn’t serverless and just how much difference the right database makes for running serverless applications.
What is serverless?With all the buzz about serverless, it’s a good idea to step back and make sure that we’re talking about the same thing. Serverless is an umbrella term. At its core, it’s a computing model where you don’t need to think about the underlying infrastructure: you don’t provision resources, you don’t manage scaling, and you don’t worry about high availability. All that happens automatically.
With serverless, you only pay for resources that you use while your requests are being handled. When demand increases during periods of high traffic, the resources available scale accordingly. When traffic drops, you no longer pay for those resources. Alternatively, a pre-provisioned cloud-based service can run up your bill sitting idle and listening for requests. You can still encounter high bills with serverless computing, but only because you’ve had unexpectedly high usage. Serverless has a lot of benefits for applications with variable or sparse workloads. Think about a betting company that allows live wagers during the World Cup, as an example. During a match, bets may come in at any time, but you can assume that the number of new bets will spike when one team scores. Unfortunately you can’t predict when a goal is going to be scored. With serverless, the infrastructure behind the betting application would instantly auto-scale to support the traffic. In the absence of auto-scaling, you would need to manually monitor your resource consumption to determine when it was necessary to scale up — assuming you have the available resources to do so.
Serverless databases essentially work the same way. When you send them data, the databases automatically scale to handle increased connections and storage requirements. You pay for the read/write traffic and the storage that the data occupies. That’s it.
The challenges with traditional RDBMS and serverless computingWhen you mix a serverless compute platform with a traditional relational database (RDBMS), you’re likely to run into some issues. The most obvious (although not limited to relational databases alone) are around provisioning infrastructure resources. While you’re saving time by using serverless computing, you still need to worry about infrastructure for your database. Even if the database is hosted on a managed platform, you still need to provision those resources — the “managed” part refers to the infrastructure that it’s hosted on, not necessarily the resources available. Databases will grow over time as new data is stored, so your storage resources, in addition to compute, also need to be able to grow with it.
Another common challenge is the risk of overwhelming the database with too many connections. In a standard database interaction, a service or application opens a connection to a database, maintains it to read and write data, then destroys the connection when finished. Serverless functions may spin up a new connection for every request, creating dry connections: open connections that aren’t sending or receiving data, but add to the number of total open connections and can potentially block new connections. Choosing a serverless database eliminates this challenge entirely and will simply scale (up or down) in accordance with your application needs without any work required on your part.
You can pool connections to improve performance and avoid running dry connections, but you still risk read/write conflicts if multiple connections are accessing the same data. A database built for serverless typically has pooling or some form of load balancer built in to help mitigate this problem.
Document-model databases work better with serverless The biggest drawback to selecting a relational database for your serverless architecture is the structural rigidity of the database schema. In an RDBMS, each record stored must conform to the structure that the table implements without exception. All data must be written to a table, and every table has a set number of columns. If you have data that has values that don’t fit into any of those columns, you’ll need to add a new column. Each piece of data already entered into the table will require an update to include a value for that column and indexes will need to be refactored.
The cost of schema changes makes it harder to iterate on and evolve your database structure alongside your application logic. You lose out on one of the core values of serverless —– speed to market.
Instead, opting for a document model database deployed on the cloud, like MongoDB Atlas lets you store data as it comes to you.. Whereas relational databases impose strict data structures, document model databases define the structure of each document separately, giving you a great deal of flexibility while you develop.
For fast moving products, change happens often. If you’re locked into a specific data schema, that limits the kinds of changes that you can make. Document databases allow any new document structure you want to apply to exist alongside all previous structures. If you need to adjust existing records, you can backfill data or modify the structure as a separate process. This makes it easy to iterate on and evolve your data model as you develop.
Achieving serverless-style scalability from a databaseBeyond just the benefits of the data model, MongoDB Atlas also removes much of the pain associated with provisioning and scaling infrastructure. Our fully managed data platform makes it easy for you to get the database resources you need when you need them, with automatic, elastic scaling to take the burden off of development teams. This is especially important when working with serverless compute services (or any serverless architecture for that matter) when you need your database to be reactive to unexpected spikes in traffic.
This type of scaling can be achieved with an Atlas dedicated cluster with compute and storage auto-scaling enabled, which will give you more control over setting minimum and maximum scaling thresholds, or you can opt to deploy a serverless database. A serverless database in Atlas, referred to as a serverless instance, is an on-demand endpoint that scales automatically to meet your application needs without any upfront provisioning or capacity management required. They are based on an operations-based pricing model that charges only for the resources and storage used and will scale down to zero if there is no traffic – giving you the full benefits of building on top of serverless infrastructure.
However, as with serverless computing, a sudden spike in traffic can sometimes lead to a surprisingly large bill. To minimize this sticker shock, we’ve implemented a tiered pricing system for read operations in which each tier is progressively less expensive. You still pay for what you use, but you’ll pay less for that traffic the more traffic you get.
Getting started with a serverless database in MongoDB AtlasBecause all infrastructure is provisioned and all scaling is handled, getting started with a serverless database is a matter of naming the database instance and pointing it to your cloud provider of choice (available in regions on AWS, Google Cloud and Azure). Seriously:
All you need to do is pick your provider, region, and desired backup option, then give your instance a name you’ll use to refer to it in your application. That instance name is probably the most important part of this setup; you’ll need to include it in the database connection string that opens a connection to a database, so make it memorable and manageable.
In contrast, creating a database on a dedicated server requires you to select the infrastructure requirements and a host of other configuration options that have been abstracted in serverless, helping to save you time.
“Thanks to Atlas serverless instances we are spending less time wrestling with infrastructure and configuration and more time developing solutions for our customers.” – CEO, Small Business Computer Services Company. Build full-stack serverless applications with MongoDB Atlas + Google Cloud RunIf you’re looking to get started with a serverless compute and database stack, we’ve found good results running MongoDB Atlas with Google Cloud Run. It’s a fully-managed serverless solution that performs seamlessly with our database instances.
Cloud Run’s automatic scalability, combined with MongoDB Atlas’s fully managed and highly available database, allows for a seamless and cost-effective way to handle incoming traffic. As Cloud Run automatically spins up additional containers to handle the load, your serverless database will also provide more resources to handle the database load. This ensures that your application is always able to handle incoming traffic, even during periods of high and unexpected usage, without you having to worry about managing the underlying infrastructure. So you can focus on developing and deploying your application, instead of worrying about maintaining servers or databases.Both Cloud Run and MongoDB Atlas are pay-per-use services, which means that you only pay for the resources you actually use. Depending on your use case, this may help you save on cost as you are not paying for resources that you don’t need.
Finally, Cloud Run’s stateless and event-driven nature and MongoDB Atlas’s automatically scaling and highly available database make them a great fit for a wide variety of use cases, from simple web applications to complex microservices architectures. Developers can take full advantage of serverless technology across the entire stack, making their development process more streamlined and cost-effective.
Move fast and don’t worry about infrastructureFor individuals or organizations looking to get a cloud-based application up and running quickly without having to worry about provisioning and scaling infrastructure, serverless has emerged as a solid option. But you could miss out on the full benefits of serverless if part of your stack — your databases — aren’t optimized for flexibility and scale.
If you’re looking to improve your efficiency and take advantage of the added benefits of a serverless database, sign-up for MongoDB Atlas on Google Cloud Marketplace to try Atlas serverless instances today. After signing up and completing the setup wizard, you’ll be ready to start storing data within minutes. If you’re not quite ready for that, you can also visit our website to learn more about how to build serverless applications with MongoDB Atlas to make sure you’re prepared when your next project arises.
The post Serverless scales well, but most databases don’t appeared first on Stack Overflow Blog.
Ben is joined by Kyle Mitofsky, a Senior Software Engineer on Stack Overflow’s public platform; Kelsey Hightower, Principal Developer Advocate at Google Cloud; and Guillermo Rauch, cocreator of Next.js. They cover what’s new in Next.js 13, how growing demand for front-end applications has made the React codebase “ginormous,” and what’s required to support a sustainable community of open-source contributors.
Episode notes:
We talk about how Next is bringing image components, server components, and in-house analytics via split bee—and bundling them all together with Turbopack, powered by Rust, our Developer Survey most loved language of 2022
Guillermo Rauch is the CEO and cofounder of Vercel and cocreator of Next.js, an open-source React framework that helps developers build fast, lightweight web applications. The most recent version is Next.js 13. You can find Guillermo on LinkedIn.
We previously talked with Guillermo about the security risks of laziness, how Next.js mixes static site and SPA functions, and the front-end trends that get him excited.
Kelsey Hightower is the Principal Developer Advocate at Google Cloud. Find him on Twitter or GitHub, or read about his very personal history with Kubernetes.
Kelsey has also distinguished himself on our podcast before.
Kyle Mitofsky is a Senior Software Engineer at Stack Overflow. Find him on Twitter or GitHub.
TRANSCRIPT
The post You don’t have to build a browser in JavaScript anymore (Ep. 538) appeared first on Stack Overflow Blog.
We’re all coders nowIn the 1980s, personal computers became common in the workplace. With the release of the Apple II in 1977 and the IBM PC four years later, a tool once reserved for scientists and the military proliferated in accounting offices, universities, and hospitals. You no longer had to be an engineer to use a computer.
Something similar has happened with programming over the past decade. In everyday offices, classrooms, and laboratories, code is now being written and maintained by people who don’t think of themselves as programmers.
The good news is that it’s easier than ever to write code that works. There’s no shortage of beginner-friendly programming tutorials, and high-level languages today are more readable than ever. So, if someone at work hands you a Python script to run over some data, between Stack Overflow and Codecademy you can probably figure out how to get it to work.
The bad news is that after you write the code you just learned to write, someone is going to have to read it (that someone might be you in six months). To a beginner, getting a working solution is the finish line. To a developer, it’s only the starting line. And since more of us are writing and collaborating on code than ever before, it’s becoming crucial to write better code.
There’s a lot to learn about basic programming beyond “making it work.” For professional developers, writing maintainable code is fundamental to the job. But these practices aren’t usually discussed in “Coding 101”. Beginner tutorials usually focus on syntax.
So we’ll assume you already know how to pull together a working solution — it’s time to level up to Coding 102: writing code with and for other humans.
PrerequisitesWe’ll keep our examples short and simple and write them in pseudocode (which should seem familiar if you’ve written in a popular language). This post is aimed at people who’ve spent time writing code, but don’t write it professionally full-time. It helps if you are familiar with variables, functions, and if/else statements.
Why writing better code mattersThere’s an adage in programming that maintaining code is 75% of its total cost. Once you write the code, other people (including future you) will invest two to three times as much time, on average, in reading, updating, and fixing it. This doesn’t mean your code was badly written or buggy! Requirements evolve, other parts of the code change, and sometimes… well, yeah, sometimes there are bugs.
At one of my first (non-programming) jobs, I wrote a script that switched between browser tabs with user accounts and pasted in discount codes. At the time, this task was done by hand for hundreds of users each month.
I hacked the script together in a few hours, and, to my manager’s delight, it pasted hundreds of codes in a few minutes. But the following week, the script went haywire and applied the code to 300 wrong accounts. It took me two hours to code the script, but eight hours to undo the damage it caused and fix my convoluted code. That’s the maintenance cost.
Good design “reduces the cost of future changes.” Let’s say my company changed the layout of the discount code page. How long would it take someone to update my script to work with the new layout? If another developer offered to help, how long would it take them to get up to speed on my work? That depends on how well the code was designed.
In order to make code easy to maintain, update, and fix, it should be modular, easy to follow, and easy to reason about. Writing “clean” code (as it’s often called) will help you think through the problem. If other people you work with can embrace these practices, you’ll spend less time struggling and more time collaborating productively.
Coding 102Now that we understand why maintainable, clean code matters, let’s talk about how to write it.
- Write small functionsAim to write small functions that do one thing. Let’s say you’re writing a function that takes a list of widget prices and returns some text with the average of those prices. For example, you give it [13, 28, 17, 143, 184, 72.3] and it should return “The average price for 6 widgets is $72.22.”
A first attempt at this code might be a function called get_price_average(data) that:
- Takes some data
- Gets the length of the number list
- Gets the sum of the prices
- Divides the sum by the number of widgets to get the average
- Rounds the average
- Assembles all the stats into a string of text and prints it
Depending on the language, some of these operations might be built in. You put these steps in one function, and it works. This is a fine, typical first version.
On the plus side, the code is cohesive: everything we’re doing related to the stats text is in one place. So if you need to change anything having to do with this text, you know where to look.
The problem is that if you do need to make a change (add a stat, clarify which numbers should be averaged, or change the decimal points on the average), you’ll need to read and understand the whole function. And adding the change will just balloon it further.
The solution is to break our oversized get_price_average(), which does many things, into several small functions that each do one thing. A good guideline is:
A function should be small, do just one thing, and ideally shouldn’t impact anything outside the function
Let’s try to see this by example. Here’s how we might break the function up.
get_widget_price_stats(data): we’re renaming our wrapper function,get_price_average(). It now takes some data, extracts the relevant stat and returns texts with that stat. We’ll talk about names shortly!get_max(list_of_numbers): gets the largest number in a list. Depending on the language you use, this might be part of the standard library.get_min(list_of_numbers): gets the smallest number in a list. Depending on the language you use, this might be part of the standard library.get_sum(list_of_numbers): gets the sum in a list of numbers.get_average(list_of_numbers, decimal_points): takes a list of numbers and returns the average, rounded todecimal_points.
Did you find some of those function descriptions obvious? For example, it might be pretty clear that get_max(list_of_numbers) gets the largest number in a list. Good! That’s by design. When you write small functions that have clear single responsibilities, you can give them names that clearly convey what they do. Then, your future readers don’t have to read all the code in the function to understand what it does.
How does this design respond to changes? Let’s say instead of the average, you need to return the standard deviation. In the initial version, we’d need to find the section of the code that calculates the average and overwrite it with a standard deviation calculation.
In the small-function version, we could create a new function, get_standard_deviation(list), then go into get_widget_price_stats() and replace the call to get_average() to get_standard_deviation().
To recap, the functions we break out should be small, self-contained, and do one thing. This makes it much easier to read and change your code. This practice alone will improve your code significantly.
- Pick names carefullyThere’s a running joke that “there are two hard things in computer science: cache invalidation and naming things.” We’re going to leave cache invalidation for another post and focus on naming things.
A related idea is that “good code is self-documenting.” In essence, this means that good code conveys what it does. Names are a big part of this: a good name is precise, easy to understand, and gives the code context without having to read every line.
Here are some good naming practices:
- Describe intent: Try to describe the variable or function you’re naming as specifically as you can. For example, the function we looked at above was called
get_price_average. However, since the string we’re returning is actually an average of widget prices, we could name the function more precisely:get_widget_price_average(). Later, we wanted it to serve as a wrapper function that returned some stat, so we renamed it toget_widget_price_stats()From this function, we extracted a generalaveragefunction that takes a list of any numbers and returns the average.
Try to avoid general names like date, slice, part, numbers. Instead, depending on context, date might become created_at, slice might become outdated_prices, part might become part_to_be_fixed, and numbers might become current_row.
2. Be consistent: Whichever convention you decide to use, stick with it. If the codebase uses get_ for functions that return values, each function should be get_[stat]: get_average, get_max, etc. If you name a function that returns standard deviation standard_deviation, another dev will wonder how it’s different from all the get_[stat] functions.
3. Give the right amount of information. A variable called first_name conveys a good amount of information. The alternative, name is too vague (first? last? middle? full?) and n or fn is downright indecipherable. These are examples of under-explaining; it’s not clear what the variable does.
It’s also possible to over-explain: user_first_name doesn’t offer any additional information, since user is fairly generic, and it’s not clear what the alternative is (does the app have bots with first names?) Similarly, first_name_for_user_record, or get_price_average_by_dividing_prices_by_quantity offer redundant information.
Deciding on the right level of specificity is a skill you’ll build over time. It requires you step back and think deeply about what the variable is doing. This’ll make your code better in the long run and make you a better developer with it.
Speaking of how you shouldn’t call your variable fn, here’s a list of naming practices to avoid:
- Don’t include type: Focus on the purpose of the variable, not its implementation. Common names that break this rule are
array,number/num,list,word,string. Syntax is usually clear from the code, so you don’t need to addfunctionor the type to the variable name:get_average_functionorarray_of_prices. As a general rule, your name shouldn’t include the type of the variable (this is called “Hungarian notation”). If you need to sayadmission_numbers, keep looking for a better name (daily_admissions.) - Don’t use abbreviations: Is
det“detail”, “detrimental”, “deterministic”, “Detroit”, or something else? Our earlierfnfalls into this category. - Don’t use one-letter names: These are abbreviations on steroids—they’re completely incomprehensible! Instead, describe what the variable’s purpose is.
There are a few uncommon exceptions to this:
1. Loops, where it’s common to refer to the index as i.
2. Scientific and mathematical conventions, as long as you’re certain they’ll be clear to other developers.
3. Domain-specific conventions (for example, in JavaScript, webpage events are often referred to as e instead of event).
These are exceptions—99% of your variables should have descriptive, multi-letter names!
- Avoid reassigning variablesThe following problematic function takes some
input, transforms it withseasonal_multiplier, adds a mystical 14, and returnsresult.
function get_result(list, seasonal_multiplier) {int result = list;result = list.sum / list.length;result = result * seasonal_multiplier;result = result + 14;return result;}
Putting aside the opaque variable names, result represents four different things during the course of this function. It starts out as the input, then becomes input per participant, then input per participant adjusted for the seasonal multiplier, and is then finally returned with a magical 14 tacked on. It’s doing too much work!
Most languages allow you to assign a new value to a new variable. In practice, this is usually not a great idea. A variable should represent one thing, and change its identity during its lifespan. When you look at a variable name, you should have a good sense for what its purpose is.
There are two ways to clear up this code:
1. Be clear about what the changes are. A better way is to be explicit about what each transformation is, declaring a new variable at each step. This might seem like over-explaining at first, but it makes the function much easier to comprehend.
function get_result(list, seasonal_multiplier) {output_per_participant = list.sum / list.length;seasonal_output_per_participant = output_per_participant * seasonal_multiplier;adjusted_seasonal_output_per_participant = seasonal_output_per_participant + 14;return adjusted_seasonal_output_per_participant;}
As a final step, I’d probably rename the function get_adjusted_seasonal_output_per_participant().
2. Combine the math into one line. You can avoid this problem altogether by combining all the steps into one calculation. The reader then has to follow a lot of math at once, but at least the intent of the variable is clear, and one variable has one meaning throughout the function
function list, seasonal_multiplier(input) {adjusted_seasonal_output_per_participant = list.sum / list.length * seasonal_multiplier + 14;return adjusted_seasonal_output_per_participant;}
You might also wonder what that 14 represents. That’s what we call a magic number.
- Avoid magic numbersA number used without any context is called a “magic number,” and it makes the code harder to comprehend. Here’s a bit of incomprehensible code:
int yearly_total = monthly_average * 12 + 67.3;
monthly_average * 12 probably refers to the number of months in a year (we deduce from the better named yearly_total). But we shouldn’t have to deduce. And what the heck is 67.3? It might have made perfect sense to the code’s author, but we’re left to scratch our heads.
A better approach is to assign numbers to well-named variables, then use those in calculations.
int total_at_beginning_of_year = 67.3;int months_per_year = 12;int yearly_total = monthly_average * months_per_year + total_at_beginning_of_year;
5. Use few parametersFunctions take inputs (referred to as “parameters” and “arguments”). In most languages, the order of the inputs matters. Let’s say you have a function that takes a fruit, a country, and a year, and tells you the average price for this fruit in that country and year.
function getAverageFruitPrice(fruit, country, year) { // get and return the price}
This seems good so far. To get a price, you can call get_average_fruit_price(“peach”, “Albania”, 2007). But what if we want to narrow the price further by adding an option to only count fruit sold industrially (for example, to juice companies)?
No problem! We can just add a new boolean parameter, function get_average_fruit_price(fruit, country, year, sold_to_industry). But remember, we’ll need to pass in the arguments in the right order, and that’s an easy thing to mess up. We’ll need to check the function definition every time we want to call it! If you mess up and write get_average_fruit_price(“peach”, 2007, “Albania”, false), year is now “Albania”!
A good general rule is to keep your input count to two to three at the most. This way, developers building on top of your code don’t have to constantly check for the correct orders, and are less likely to make mistakes.
There are two ways to improve a function that takes too many inputs:
- Break it up into smaller functions. Too many parameters could be an indicator that your function is doing too much.
- Use an options object. If you can pass the parameters in an object (called a hash or a dictionary in some languages), you don’t have to worry about property order. This object is often called
optionsand referred to an “options object.” The downside to this approach is that it’s less explicit about the expected parameters. Here’s how this looks in practice:
function get_average_fruit_price(options) { // use options.fruit, options.country, options.year, options.sold_to_industry}
6. Write good commentsThere are a lot of great, thorough rules around code comments, but we’ll focus on the low-hanging fruit…
Use comments sparingly to explain code that’s not otherwise clear. If you can improve the code instead, do that! Here’s an example of a bad comment covering up for unclear code:
int f = 75; // f is the temperature in Fahrenheit
Let the code speak for itself by renaming f to temp_in_farenheit!
You won’t always have time to improve the hard-to-comprehend code you see. You might also write code you’re not thrilled with due to time constraints. Consider whether the code will need to be “touched” (read or modified) by someone else. Be honest — you don’t want to pass on code that’s hard to maintain!
If the code isn’t likely to be modified by anyone else, you can leave a comment explaining what a particularly challenging bit of code does. Ideally, your function and variable names should already do this. But when the functions contain logic that’s hard to comprehend and the function name doesn’t help, leave a comment!
- Don’t repeat yourselfThe DRY principle stands for “don’t repeat yourself.” If you find yourself using the same code in multiple places, see if you can pull it out into a variable or a function.
string company_description = “Fruit Trucking & Shipping International ships fruit on our modern fleet of trucks and ships, anywhere in the world!”
string company_slogan = “Fruit Trucking & Shipping International: where the best fruits get on the best ships”
string company_name = “Fruit Trucking & Shipping International”
string company_description = company_name + “ ships fruit on our modern fleet of trucks and ships, anywhere in the world!”
string company_slogan = company_name + “: where the best fruit gets on the best ships”
If the company ever changes its name (for example, if it decides to only ship apples…) we can now do this in one place. Conversely, if you don’t follow DRY, you’ll need to find all the places you have duplicated code and remember to make changes in each of them.
Here’s another example: let’s say all your input temperatures are in Farenheit, but you need your output values to be in Celsius. Everytime you work with a temperature, you’ll need to F - 32 * 5/9. If you find out your organization now uses Kelvin , you’ll have to update this to F - 32 * 5/9 + 273.15 every place you reference a temperature.
A better solution is to pull this conversion into a function:
function fahrenheit_to_celsius(temp_in_farenheit) { return temp_in_farenheit - 32 * 5/9;}
Now to switch to Kelvin, you can update the calculation in one place. In this particular example, you could probably just create a new (small, single-purpose) function called fahrenheit_to_kelvin(), and all the calls to fahrenheit_to_celsius() to fahrenheit_to_kelvin(). Now it’s very clear where you’re updating (you don’t have to look for mentions of “temperature” all throughout your code.)
It’s possible to overdo DRY. You don’t want to over-optimize too early, so a good alternative to DRY is WET, or “write everything twice”. If you need to write some code a third time, it’s probably a good idea to try and pull this out into its own function or variable. Over time, you’ll develop judgment for when to reuse the same piece of code over and over (like the example above) and when a few repeated lines are a part of separate processes.
Next stepsReading about good coding practices is like reading about working out. You have to follow the practices to reap the benefits!
Just because you learned about all the muscles doesn’t mean you need to exercise them all right away. Start small: the next time you code, try to be precise with your names. Then, try to write smaller functions. Then, reference this article to see what else you might have missed! Think of it like starting your fitness regimen with a few exercises a week.
Remember, we’re writing code for our future colleagues, and, importantly, our future selves. We don’t need to be dogmatic about the rules; we just need to focus on being as clear as we can.
You’ll quickly find that writing clean code involves making tradeoffs. For example, if you’re under time pressure writing a one-off script to parse some data and are confident nobody will see the script again, you can invest less time into writing clear code. But over time, thinking about code maintainability and readability will empower you to solve problems more effectively and will set you apart from many beginner developers..
By implementing some basic software dev principles, you’re leveling up from someone hacking through code to someone maintaining and building software. And that’s something to be proud of!
The post Coding 102: Writing code other people can read appeared first on Stack Overflow Blog.
Welcome to ISSUE #164 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: This week: We decipher what’s going on from the latest waves of layoffs, trace the historical importance of breakfast, and figure out how to animate SVGs with ease.
From the blogIs software getting worse? stackoverflow.blog
With all the advancements in software development, apps could be much better. Why aren’t they?
CEO update: Eliminating obstacles to productivity, efficiency, and learning stackoverflow.blog
It was a busy and successful quarter, so although our first CEO update of 2023 takes place in a fundamentally different environment than the first of 2022, our optimism for the future has not changed. It’s simply joined by a dose of pragmatism.
Announcing more ways to learn and grow your skills stackoverflow.blog
Now you can discover relevant online courses from Pluralsight® and Udemy® on Stack Overflow.
What do the tech layoffs really tell us? (Ep. 533) stackoverflow.blog
The home team convenes to talk about how tech layoffs are reshaping the industry, where to look for software engineering jobs beyond tech, the brain-computer interface that speeds up communication for people experiencing paralysis, and Ben’s million-dollar game idea (free for the stealing).
A faster, easier, and more flexible database-as-a-service. promotion
Couchbase Capella DBaaS is flexible, full-featured and fully managed – with built-in access via K/V, SQL and full text search. It’s blazing fast, yet surprisingly affordable. Try Capella today for free.
Interesting questionsHow can a grain of sand be “spaghettified” when nearing a black hole? physics.stackexchange.com
This is all speculation since we can’t really run experiments with black holes.
Does the meme “breakfast is the most important meal of the day” come from a 1944 cereal marketing campaign? skeptics.stackexchange.com
Breakfast is so important that it’s mentioned in foundational religious texts.
What’s the rationale behind allowing sudo -u root but disallowing sudo -u security.stackexchange.com
Welcome to policy jungle, we’ve got confusing rules. You can impersonate any user you like, so long as you got root.
Does a query that is suspended due to an ongoing ASYNC_NETWORK_IO cause blocking? dba.stackexchange.com
As a senior engineer would say: “It depends.”
Links from around the webWorld Wide Web – Wikipedia en.wikipedia.org
The World Wide Web is the world’s dominant software platform. Do you know its history? Did you know it once even had a logo?
Easy SVG customization and animation: A practical guide www.smashingmagazine.com
Customizing and animating SVGs can be intimidating, but it doesn’t have to be.
The State of WebAssembly – 2022 and 2023 platform.uno
WebAssembly has come a long way! Take a look at where it’s been and where it’s going.
Refraction, dispersion, and other shader light effects blog.maximeheckel.com
We all like pretty lights! There’s a whole lot to learn about them, and this blog touches on the nitty gritty details of shaders (and more) in the browser.
Three must-listen podcasts for software developers medium.com
Finally, forgive us the self link, but we can’t help it when folks put our podcast in such fine company.
A blast from the past: Most developers believe blockchain technology is a game changer.
The post The Overflow #164: Is software getting worse? appeared first on Stack Overflow Blog.
Emery Berger, Professor of Information and Computer Sciences at the University of Massachusetts at Amherst, joins Ben for a conversation about the impact of AI on academia. As a young sci-fi fan, he was fascinated by computers that could spit out solutions (a fascination that survived exposure to BASIC and COBOL). Now his CS students are using Copilot to do the same thing. How can educators (and students) adapt?
Episode notes:
Professor Emery Berger is a systems builder who studies “programming languages, runtime systems, and operating systems, with a particular focus on systems that transparently improve reliability, security, and performance.”
AI giveth and AI taketh away: an incredible tool for developers is creating new challenges for CS educators and students. Read Emery’s 2022 essay “Coping with Copilot.”
You can also find Emery on GitHub or Twitter.
Today’s Lifeboat badge winner is mbcrump for their answer to How do I generate a random integer in C#?.
The post Does your professor pass the Turing test? (Ep. 537) appeared first on Stack Overflow Blog.
Every year, universities, colleges, and bootcamps around the world graduate brand new software developers who have never taken a course on secure coding or application security. In fact, they may not have been taught anything about security at all.
This lack of security understanding has implications for software development on three layers: the individual developer writing insecure code, the engineering team blindly trusting their dependencies, and the organization thinking that their best bet is to roll their own security controls. In this article, I’ll talk about each of these layers, how a lack of security knowledge affects it, and how individuals and organizations can create software that follows security best practices.
Hello (insecure) worldFrom the very first lesson, we are taught to code insecurely and incorrectly. The first thing we do in the famous ‘hello world’ lesson is to put data on the screen: “Hello world!” The second thing is we ask the user for their name: “What is your name?” The user enters their name, we take that data and reflect it back to the screen to say “Hello
If we added more to the lesson, validating the input (and rejecting it if it was bad) and then output encoding the data before mirroring it to the screen, then we would be teaching every new coder how to avoid cross-site scripting (XSS). But we don’t teach that as part of the lesson. We show them how to do it insecurely. I suspect this is part of the reason that XSS is so prevalent across the internet: we’ve been drilling it into new coders how to create this vulnerability from the very first day.
Secure coding best practicesIf everyone is learning the wrong way from the start, how can we fix this? There are several things, but let’s start with how we build software: the system development life cycle (SDLC).
Some common security activities that can be added to the SDLC include:
- Security requirements: The measures that need to be put in place for the application to be considered secure. You’re building a serverless app? Cool! Here’s a list of security requirements we need you to add to your project’s requirements document to ensure it’s safe enough to put it on the internet.
- Threat modeling: A brainstorming session that includes at least one security professional, a product owner and/or business representative, and a member of the technical team. The goal is to identify as many potential threats to the product as possible, then work to mitigate the ones that seem the most damaging or dangerous. This is often done in the design phase, but it could be done at any point afterwards if you didn’t have time earlier in the SDLC.
- Code scans: During the coding phase, you could scan your own code with a static application security testing tool (SAST) or a software composition analysis tool (SCA) or throw your app on a dev server and scan it with a DAST tool.
- Break it early: During the testing phase, you could hire a penetration tester to perform thorough automated and manual testing of your entire system.
- Protect code in production: During the release phase, you could set up monitoring, logging, and alerting for your application. You could install it behind a runtime application security protection (RASP) or web application firewall (WAF).
All the items listed above are just the beginning: you can organize your secure SDLC in any way that works for your organization and teams. You can use some of these or none of these; the key is finding activities and tooling that work for your organization.
We can create a secure SDLC by adding security activities throughout out processes. That said, we have to follow the security steps every time, not just sometimes or when it’s convenient if we want to reliably produce secure software.
If you add one single security step or verification to your SDLC, you will create more secure applications. If you add more than one step, you will create even better applications. Software is always a tradeoff: we don’t want to spend a million dollars on security for an application that will only earn h a couple thousand dollars worth of value. We do want to ensure we are protecting our systems such that they meet the risk tolerance of our organization. In more plain language, we should work with the security team to decide exactly how much security is required, but generally it’s safe to assume that ‘more is more’ when it comes to security.
Zero trust, but not the marketing versionQuite often when designing systems, we create ‘implied trust’; that is, one or more parts of the system don’t verify something they should or could. When someone logs into a system, a security control verifies the user’s identity (via the username and password combination) and then grants them access to the parts they are allowed to access. In programming, we generally call the first part authentication (who are you?) and the second part authorization (should you be here?). If we skip this step, we are creating implied trust. We don’t care who the person is and are assuming that the person is allowed to be there.
Zero trust means never, ever, having any implied trust. Every single possible part of a system is locked down and only opened if it must be. This means closing all ports except the ones you need. It means blocking all connections except the ones you know you need. It means always verifying everything before using it. No trust in anything at all, even the other systems you have as dependencies.
Although zero trust is quite a lot of work to implement, it works. And it works well.
Examples of zero trust that you could implement in programming:
- Validating, sanitizing, and escaping all inputs (in that order)
- Each API, serverless, container, and app is an island; treat them like that. They should not trust each other!
- Authentication and authorization for everyone! Every single integration, even with systems built and maintained by your team, requires authentication and authorization, for every single connection.
- Output encoding, because you never know if someone changed something. Do not trust your user’s input or input that may have been tampered with!
I have never seen an organization implement every single possible variation of zero trust, but that’s okay. Applying zero trust principles to as many systems as possible is good enough.
Buy, borrow, then buildBuilding security controls is hard. They are complex in nature to build, they are tested far more often and more aggressively than any other feature (thanks to malicious actors), and there are few public examples to work from due to companies wanting to protect their intellectual property. This puts us in a situation where building our own custom security control ends up being expensive, time consuming, and potentially even dangerous.
With this in mind, security professionals (and software architects, for that matter) often recommend we go in this order when we decide if we will use a pre-existing component or write our own:
- Buy it if we can afford it with the budget we have. The reason for this is that it’s available immediately, we don’t need to assign resources to create and thus they are free for other work, we don’t need to maintain it ourselves (which is almost always the reason custom software costs more than buying it), and it is very likely to have had significantly more security testing performed against it (big customers demand intensive testing and high security assurance). Although the price tag may seem steep, when you calculate the risk, the wait, and the long-term cost of maintaining the system, it is almost always cheaper to buy than build.
- Borrow it. This can mean open source software, online examples, code from other teams, using the features in your framework, or even having an entire system supplied (this happens in government and nonprofit organizations more often than for-profit/private). Borrowing it is more of an expression than a reality, we mean ‘use code that is open source or other code you can use for free, but that you did not write’. The advantages of this are similar to the ‘buy’ section: the borrowed code is available immediately, it’s free, and we don’t have to maintain it ourselves. That said, if it’s given for free, it might not have had any security testing on it, meaning you should verify that it’s secure before using it if at all possible.
- If neither of those is an option, we build it.
This saves our organizations money, time and risk, despite the fact that building our own from scratch is usually way more fun.
With this in mind, whenever possible, use the security features found within your programming framework, such as: encryption, authentication, and session management. They are tried, tested, and true!
Next, use third-party components (libraries, packages, gems, etc.), as they have (usually) been tested quite thoroughly. Verify third-party code and components via a software composition analysis (SCA) tool and reverify often.
To summarize the buy/borrow/build philosophy: don’t write your own security features unless you absolutely have to. It’s hard to get right!
In closing, although we may not have been taught it in school, we can start with the steps above to begin creating more secure applications and code. By creating a secure system development lifecycle, avoiding implied trust within the systems we build, and only creating our own security controls when it is absolutely necessary, we will reduce the risk to our organizations in a consistently positive way. The organizations we work for are counting on us to be their first line of defense, and with these new strategies, you should be up to the task!
The post Three layers to secure a software development organization appeared first on Stack Overflow Blog.
With companies taking a long look at developer experience, it’s time to turn that attention on the humble pull request. The folks at LinearB took a look at a million PRs — four million review cycles involving around 25,000 developers — and found that it takes about five days to get through a review and merge the code. CI/CD has done wonders getting deployments down to a day or less; maybe it’s time for continuous merge next.
On this sponsored episode of the podcast, we chat with COO Dan Lines and CEO Ori Keren, co-founders of LinearB, about why PRs are the chokepoint in the software development lifecycle, uncovering and automating the hidden rules of review requests, and their free tool, gitStream, that’ll find the right reviewer for your PR right now.
Episode notes:
So why do reviews take so long? Context switches, team leads who review everything, and the bystander effect are top contenders.
Dan and Ori hope their gitStream tool can reduce the time PRs take by automating a lot of the hidden rules for reviews. Check it out at gitstream.cm or linearb.io/dev.
Dan Lines hosts his own podcast: Dev Interrupted. Check out this episode with Stack Overflow’s very own Ben Matthews.
Connect with Dan Lines and Ori Keren on LinkedIn.
Shoutout to Rudy Velthuis for throwing a Lifeboat to the question Why should EDX be 0 before using the DIV instruction?
TRANSCRIPT
The post Engineering’s hidden bottleneck: pull requests appeared first on Stack Overflow Blog.
The home team discusses why it seems like everybody needs subtitles now, the AI that generates music from text, and a list of open-source data engineering projects for you to contribute to.
Episode notes:
It’s not just you: We all need subtitles now.
Google introduces MusicLM, a model that generates music from text. The examples are pretty-mind blowing and raise big questions about licensing and copyrights for non-AI creators.
Taking the uncanny valley to a new low? Nvidia’s streaming software now includes a feature that deepfakes eye contact.
Beware the potentially dangerous intersection of AI and stan Twitter.
Thanks to Siavash Kayal, a fan of the show and data engineer at Cleo, who sent along a great list of open-source data engineering projects folks can work on.
Today we’re shouting out Stellar Question badge winner Paragon for asking how to Open two instances of a file in a single Visual Studio session.
TRANSCRIPT
The post The AI that writes music from text (Ep. 535) appeared first on Stack Overflow Blog.
Quantum computing may be the next big breakthrough in computing, but the general conception of it is still in the realm of hype and speculation? Can it break every known crypto algorithm? Can it design new molecules that will cure every disease? Can it simulate the past and future so well that Nick Offerman can talk to his dead son?
We spoke with Dr. Jeannette (Jamie) Garcia, Senior Research Manager of Quantum Applications and Software at IBM Quantum about their 433 qubit quantum computer and what the real life applications of quantum computing are today.
The Q&A below has been edited for clarity. If you’d like to watch the full conversation, check out the video of our conversation.
Ryan Donovan: How did you get into quantum computing?
Jamie Garcia: I am actually a chemist by training—I hold a PhD in chemistry. I came to IBM because I was very interested in some of the material science work that was going on there at the time and started doing some research in that space. I think most experimentalists will tell you if you get a weird outcome from an experiment, one of the first things you need to do is try to figure out why, and that involves a lot of the theory. I was running down the hallway to talk to my computational colleagues to help elucidate what was going on in my flask that I couldn’t actually see.
As a part of that process, I got very interested in computation as a whole and the simulation of nature and trying to use computation towards that end. I realized that there were some real challenges with using classical computers for certain reactions. I would ask my colleagues and they would tell me it was impossible. And I was like, why ?
RD: Can you give an example?
JG: For me, they were surprising examples—small molecules that were really reactive.
You think of radicals, for example, that wreak all sorts of havoc in our bodies, but also turn up in batteries too, which I was studying at the time. The reaction was so high energy and there were so many different things that had to happen with the chemistry that classical computers couldn’t model it even though they were small molecules. It’s just O2 size.
When I was at Yorktown Heights one day walking down the hallway, I saw one of my colleagues had a poster and it had chemistry on it, which caught my eye. You don’t see that all that often at IBM . It turns out that he was using quantum computers to study a certain property of a molecule.
It stopped me in my tracks, and I realized this is a whole new tool for chemistry. Now we’ve expanded beyond chemistry. We’re looking at all sorts of different things, but that was what got me hooked and interested from the very beginning.
RD: We’ve talked to a few folks in quantum computing, but I think it’s valuable to kind of get the basics here. What exactly is a qubit?
JG: A qubit is our analog to a classical bit. At IBM we use superconducting qubits. These have to be cooled down to around 15 millikelvin. You may have seen photos of our big dilution refrigerators that cool our qubits down to that level. They’re made out of superconducting materials.
What you’re doing when you’re programming a qubit is you’re using the materials properties of those superconductors, you’re able to move electrons into different energy states. That basically allows you to program a quantum computer. One of the biggest challenges is keeping them in those states. And I have a feeling we’ll talk about that.
One of IBM’s dilution refrigerators. Photo via IBM Research. RD: Especially with your material science background.That seems like that’s a big part of the ball game.
JG: But they’re fundamentally a kind of different beast too, because we’re now using and leveraging quantum mechanics to program the qubits and the quantum computers and be able to perform algorithms on them. So it has a different flavor to it than a classical bit.
In fact, you can use quantum mechanical properties such as superposition and entanglement. Those are new knobs to turn when you’re thinking about algorithms. In certain instances, it can be complementary to classical devices. But it really is a whole new area to explore.
RD: I’ve heard that cubits aren’t exactly stable. You have them super cooled and are trying to keep them in this particular state. To produce one qubit, do you need a lot of redundancy and error correction?
JG:When we’re talking about 433 qubits, it’s all on one chip, right? So when you program them, a lot of times, we leverage two qubit gates where you need to entangle two qubits together.
You set it up and map your circuit onto the qubits in a very specific way in order to get an answer. Now, the stability piece that you’re referring to—qubits are inherently sensitive. We have to cool the qubits that we use down to 15 millikelvin because of exactly what you said.
You’re trying to basically hold the qubit in this state for as long as possible so you can run the calculation that you need to run. Basically, you need to have enough time to perform the gate operations for your circuit.
Qubits are susceptible to noise. Sometimes we know where that noise comes from and sometimes we don’t. When we think about how we arrange the qubits on the chip, we’re doing it in a way that minimizes noise most of the time. We use what’s called a heavy hex architecture. That limits the crosstalk between qubits to minimize the noise so you’re able to have as long coherence times as possible to run the circuits and do a practical calculation within hours, not in a lifetime.
We’ve also developed a lot of other techniques to manage the noise. Error correction is something that our teams are working towards and developing out the theory for certain error correction that will include having a fault tolerant device and error rates low enough that we can actually run some of those codes.
But we’re also looking at error mitigation, which leverages classical post-processing methods and can capture the noise regardless of whether we know where it comes from or not, to be able to account for the noise and then correct for it so that we can get out as accurate results as maybe even in an error corrected regime.
There’s active research ongoing and software tools that are being developed so that we can leverage these techniques as they are developed in real time and use them for our applications research and run algorithms and circuits that are interesting to us.
One of the things that we’ve recently released, which you can actually access through Qisket runtime is something called probabilistic error cancellation. What this essentially does is when you run a circuit, it runs the inverse of certain parts of the circuit, and you effectively are able to learn where the noise is that way. Then the post post-processing divides it into smaller circuits and you can pull it all back together and account for the noise.
There are opportunities for machine learning, certainly. We’re thinking very seriously about how AI and quantum intersect. Especially since we just announced our System Two and the plans for that. We’re thinking very carefully about how all these things will play together and where AI can help quantum and where quantum can help AI.
RD: What’s the rough equivalent of 433 qubits to classical computing?
JG: This is a tough question to answer. We think of the qubits in terms of state. If you just do a rough back of the envelope calculation, people will usually say it’s two to the n. So two to the 433 [states] is a lot. Huge. I think two to 275, that’s more than the number of atoms in the universe. So it’s absolutely massive.
But there’s a lot of nuance that goes into that, especially when we’re talking about actually programming a quantum computer and using it to look at a chemistry problem or a problem in finance or anything like that. In addition to that, you have to take into account the noise that you have present in the system.
So it’s hard to say about what the computing power today is of a device that has 433 qubits. If you project out to where someday we have error rates that are as close to zero as possible, then that’s where you start talking about this two to the n and harnessing the power of the universe. You know, all these things.
That’s the potential that it brings to us in terms of compute.
RD: That two to the n is what exactly?
JG: It’s basis states.
You can use the examples of molecules. Water might use somewhere around 14 qubits. If you have 14 qubits, then that’s 10 to the four classical bits, right?
You can calculate it out that way. But again, there’s a lot of nuance here. We need to carefully consider the types of problems that quantum will be good for. It’s not necessarily all the same problems that you can think of classical being good for. That’s my caveat, but it kind of gives you a rough idea.
RD:Some crypto algorithms are trying to be quantum safe, while others like Shor’s Algorithm are uniquely suited for quantum computing. Why is that?
JG: Shor’s is an algorithm that is in that long-term error corrected regime, right? You would need to use error correction for it. A lot of the famous algorithms that you’ve heard of that show exponential speed up with quantum computers, typically what we’re talking about are in that regime. There are some algorithms that are famous for chemistry, like quantum phase estimation.
That said,we’re, we’re doing a lot to bring bring algorithms closer to near term and error mitigation—and maybe even error mitigation combined with error correction—in these early days will allow us to start solving problems that I don’t think we would’ve thought that we would’ve been able to solve before as early as as this.
Shor’s algorithm definitely leverages quantum devices that have these sort of ancilla qubits. When you think of the back of an envelope calculation for what you would need to be able to run Shor’s algorithm or crack RSA or something like that, you’ll see numbers that are in the millions of qubits. You have to account for that overhead that comes with the error correction.
The asterisk is we’re doing things earlier than we thought. I think that that’s part of the reason that we’re talking about quantum safe now. We don’t know what the timeline is exactly, but we do have methods to address this that are available today. For example, our zSystems are quantum safe systems already. It’s definitely something to start considering now. If you had asked me the same question like two years ago, I would’ve said that’s so far away.
And now I’m like, Hmm. Start planning now.
RD: What other tasks or applications is quantum computing suited to?
JG: We think about it in three big buckets. The simulation of nature is one of them. That includes not just molecular simulations, but physics falls into this category. Material science falls into this category. You can think of this as being a space that’s interesting because nature is quantum mechanical. So if you are then leveraging a device that is also quantum mechanical—there’s some obvious connection there. In addition to that,there’s been theoretical proofs that show that there should be at least more than polynomial speed up possible with quantum computers with certain problems such as dynamics, energy states, ground states, and things of that nature.
The second category is generally mathematics and processing data with complex structures. This is where quantum machine learning comes in. We talked about Shor’s and factoring. That fits into this category. There are algorithms that have been shown for quantum machine learning that imply that there should be an exponential speed up possible in certain cases.
We try to focus on these two areas in particular we think hold a lot of promise because they have this greater than polynomial potential associated with them for using a quantum computer. Those are really obvious areas to look at.
The last category is search and optimization. So Grover’s falls into this category. These are areas that we don’t necessarily have theoretical proofs yet that there could be super polynomial speed up or greater than polynomial or exponential speed up. But we know that it promises probably somewhere around quadratic, maybe more. We’re still researching and looking, so you never know what you’re gonna find.
There are certain algorithms like amplitude estimation and amplification that we think could act as accelerators for the other two areas that I talked about. Regardless of what kind of speed up, we would expect that it could still help in these other areas as well.
You can imagine it’s almost two to the n number of use cases that map onto those areas and it encompasses a lot of different things. We’re exploring a lot of different areas with partners and coupling it and tying it to things that are really valuable and hard classically.
That’s key, right? If something’s really easy classically, you could argue why look at quantum for it. Something that’s hard classically is where we think that quantum can lend some kind of advantage or some kind of speed up. In the long run, those are the areas that we’re exploring.
RD: Speaking of hypothetical use cases, have you seen the TV show Devs?
JG: No, what was the use case?
RD: Simulating the past and future.
JG: Oh my goodness. Okay…Well, there is prediction, right?
RD: Sure. I mean, simulating nature, right?
JG: No, it’s not that far.
RD: Okay. Oh, no.
Because you are helping people process quantum jobs, are there any adjustments they need to make for their algorithms or data to be suitable for quantum computing?
JG: It depends on how you want to use quantum computers, right? A lot of our discussions are around—as we’re pointing to the next generation of these quantum-centric supercomputing centers and where you really have classical HPC next to a quantum device—how do you best leverage the workloads between those?
There’s a lot of things that we’ve been thinking about in terms of how you ideally would approach a problem. How would you set it up in such a way that you have the right parts of the problem being addressed classically and then other pieces with a quantum computer.
But the algorithms that we do and the circuits that we run are inherently different from classical ones. Again, it really comes down to how you divvy up the problem, and which pieces you want to put where. At a very high level, that’s what would need to be taken into consideration.
Something to point out here is that quantum computers aren’t big data types of devices. That’s another area that we think that there’s a lot to be done from the classical standpoint. But if you want to look at something that has a high complexity, high interconnectivity, or is by virtue dynamic, those are the kinds of things that the quantum computer handles really well.
If you were to run something on a quantum computer, you want to make sure that it’s the right circuit that’s going into it and the algorithm that you’re using.
RD: Is there anything else you wanted to cover that we didn’t talk about?
JG: In general, thinking about the different use cases and the different areas is really important to do as a field, right? This is a very multidisciplinary area, and we need to have folks that are coming from all points of view. Whether it’s software development, engineering, architects, and even those that are on more of the classical side.
Learning about quantum and bringing that lens has really pushed us forward in a truly unique way for this field. It has to do with the fact that it’s an emerging area. It’s all hands on deck and we’re all kind of learning together.
The post The frontier of computing: Q&A with IBM quantum computing research appeared first on Stack Overflow Blog.
Welcome to ISSUE #163 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: how hackers are going after vulnerabilities in AI and ML apps, why salt (NaCl) is so prevalent in the ocean, and how you can optimize your code reviews.
From the blogAI applications open new security vulnerabilities stackoverflow.blog
Your ML model and AI-as-a-service apps might open new attack surfaces. Here’s how to mitigate them.
Comparing tag trends with our Most Loved programming languages stackoverflow.blog
And how does learning to code play into these stats?
How chaos engineering preps developers for the ultimate game day (Ep. 531) stackoverflow.blog
In complex systems, you usually want to minimize chaos. Unless you’re trying to find weak spots. In that case, chaos is your friend.
The less JavaScript, the better (Ep. 532) stackoverflow.blog
Convert unused JavaScript into lightweight HTML…oh that feels so good.
JetBrains Space On-Premises Is Out promotion
A complete and secure software development platform, fully managed on your side. It provides Git hosting, code reviews, CI/CD, packages, issue tracking, team chats, and fully integrates with JetBrains IDEs. Start with a free plan for up to 10 users.
Interesting questionsWhy is NaCl so hyper-abundant in the ocean? earthscience.stackexchange.com
And with so much of it sloshing around, how come our rivers aren’t turning salty?
How large would a tree need to be to provide oxygen for 100 people? worldbuilding.stackexchange.com
Like people, trees are most productive in middle age.
Do cows get blown through the air by tornadoes? skeptics.stackexchange.com
Does this mean the movie Twister isn’t scientifically accurate, only scientifically awesome?
I announced my resignation…and was completely ignored. What to do? workplace.stackexchange.com
When you stop coming in to work, they might get the hint.
Links from around the webHow to optimize your code reviews github.com
Code reviews are one of your biggest opportunities for knowledge-sharing!
Dreamy blur yuanchuan.dev
Want to recreate a photo effect? Why use a photo editing software when you can use CSS?
Hello, PNG! www.da.vidbuchanan.co.uk
You’ve seen PNGs all over the internet. But did you know that their specification was updated as recently as a few months ago?
Why we all need subtitles now www.youtube.com
Sound engineering has changed, which has changed how we hear words on the big (and little) screen.
A blast from the past: CSS in SVG in CSS: Shipping confetti to Stack Overflow’s design system.
The post The Overflow #163: Most Loved vs. most questions appeared first on Stack Overflow Blog.
John Abel, Technical Director of Google Cloud’s Office of the CTO (OCTO), joins the home team to discuss what a typical day looks like for him. We discuss what he learns from his customers and why his enterprise customers are prioritizing developer experience through platform engineering and managed services in 2023. Plus: The BBC’s surprising history in computing.
Show Less
Episode NotesJohn spent 25 years at Oracle before joining Google Cloud’s Office of the CTO (OCTO), a team that’s been called the company’s “secret weapon” in collaborating with major customers to solve their tech problems and drive long-term deals.
For more on his approach to tech and business, you can read this article he wrote on the seven points of driving lasting innovation
Learn more about OCTO from Business Insider.
Settle down for a good read: the full story of how the BBC’s microcomputer changed history.
Connect with John on LinkedIn or Twitter.
Today’s Lifeboat badge winner is vscjones for their answer to:
How can I find the number of business days in the current month with JavaScript?
TRANSCRIPT
The post Why developer experience is the key to better software, straight from the OCTO’s mouth (Ep. 534) appeared first on Stack Overflow Blog.
Today, technology is changing and evolving faster than ever. As a result, we are always looking for opportunities to learn a new skill or sharpen our existing skills. During my session at our first Flow State conference last September, I talked about the expanded direction for Stack Overflow. We want to evolve the platform to empower technical communities to learn, share, and grow together.
But learning something new isn’t always easy or straightforward. Our research shows that the first, and often most difficult challenge in a learning journey is figuring out where to start, and then finding appropriate, trusted resources for your needs.
As we evolve the Stack Overflow experience , we want to make that process easier and more efficient by providing all the resources you need in one place. This may include helping you discover more trusted, quality content and resources; finding, building, and sharing learning paths; creating more focused, connected communities; and presenting you with opportunities for hands-on learning.
We are very excited about our evolution from collective knowledge to collective learning, but it will take time. You’ll see us begin to introduce new capabilities on the platform for you to try, and we’ll update you as we leverage community feedback and user research throughout. Today, we’re pleased to introduce online course recommendations.
When you visit question pages on Stack Overflow, you may now see relevant course recommendations from two popular online learning platforms, Udemy® and Pluralsight®. These course recommendations will appear as an ad module on the right side of the page, where the job recommendations used to be, and won’t impact the existing Q&A experience. Based on your cookie preferences, the courses you see will either be tailored to content you’ve visited on Stack Overflow, or courses selected based on the content of the page you’re visiting, or will be trending courses.
Through our most recent Annual Developer Survey, we learned that the Stack Overflow community is already turning to Udemy and Pluralsight for online learning. These companies are also committed to making trusted learning opportunities accessible to both professional and aspiring technologists, which aligns with our goal of empowering technical communities to learn, share, and grow together.
“We share in Stack Overflow’s mission to empower developers and technologists through learning and skill development in the flow of work and look forward to helping the community take the next step in their educational journey,” says Seth Hodgson, VP of Engineering at Udemy. “The new online course recommendation ad will help Stack Overflow users easily access specialized and relevant courses from our extensive catalog—right when they need them.”
“Learning technical skills and keeping them sharp is critical for developers to build better and faster while also growing their careers,” said Chris Tonas, Chief Technology Officer at Pluralsight. “We look forward to partnering with Stack Overflow to provide online course recommendations for our developer communities, so they can discover purpose-built and immersive learning experiences to develop the skills they need to thrive.”
Online Course Recommendations is an additional step on our path to providing all the resources technologists need in one place, and we look forward to continuing to share new ways for users to learn and grow on Stack Overflow.
The post Announcing more ways to learn and grow your skills appeared first on Stack Overflow Blog.
Over the last quarter, we’ve expanded our cloud and edtech partnerships, watched Stack Overflow for Teams become more and more embedded in the developer experience, and made great strides on our path to profitability. We’ve also had many internal discussions as a leadership team about ChatGPT and other generative AI tools as they’ve rapidly entered the mainstream. We’re excited about the possibilities Generative AI may hold for the public platform as it matures, and we look forward to experimentation around it.
Overall, it was a busy and successful quarter, so although my first update of 2023 takes place in a fundamentally different environment than my first of 2022, my optimism for the future has not changed. It’s simply joined by a dose of pragmatism.
Productivity and efficiency: Twin themes of the new yearIn today’s economic environment, productivity and efficiency are more important than ever. For many companies, these are the themes of the new year, and our goal is to provide productivity and efficiency to customers through Stack Overflow for Teams, to technologists through our public platform, and to our employees through smarter processes and ways of working.
At a recent dinner with senior technology executives in San Francisco, it was clear this focus on productivity is widely shared. Every CIO and CTO present spoke of their need to increase productivity, and most rightly view developer experience as a key lever in that effort.
When it comes to dev experience, few initiatives are more impactful than those that encourage cross-org information sharing and reduce toil — the manual, repetitive administrative work that hampers creativity and innovation.
One Stack Overflow for Teams customer in the retail space, for example, estimates that its cloud team could free up 20-30% of its time by eliminating the need to answer duplicative questions. This customer recently went through a complex merger and said Stack Overflow for Teams connected employees from the less technologically transformed part of the organization with their new, more tech-savvy peers. Ultimately, more efficient knowledge reuse helped it save nearly 10,500 hours over the last 12 months and drove meaningful progress in unifying and codifying critical institutional knowledge.
That’s an enormous boost to developer productivity, which we know drives developer happiness and retention in turn. In fact, happiness and productivity are inextricably linked; our data shows that feeling unproductive is the top driver of developer unhappiness at work — and currently, a team of 50 devs loses between 333 and 651 hours per week on average searching for answers and solutions.
Stack Overflow for Teams — “A revolution to IT” As I reflect on the quarter behind us and look forward to what’s likely to be a volatile year ahead, I firmly believe developer experience is one of the most effective ways for organizations to accelerate tech modernization while dealing with tighter budgets, scarcer resources, and greater scrutiny on investments. Anecdotally, it seems technology leaders agree.
I am excited about this growing realization and about the many organizations who are using Stack Overflow for Teams as the basis of that experience. With Stack Overflow for Teams, companies are onboarding developers faster. Their employees are avoiding roadblocks by more efficiently finding the answers they need when they need them. And overall, companies that leverage Stack Overflow for Teams are reducing toil and driving innovation by minimizing interruptions and ensuring common problems only have to be solved once.
The importance of these attributes cannot be overstated. They’re why Stack Overflow for Teams was recently recognized in G2’s Winter 2023 report as a Leader in the Knowledge Management, Q&A Platforms, and Knowledge Base categories.
I’m proud of the Stack Overflow team for their continued impact and grateful they’re being recognized for it. I especially love browsing our G2 review page and hearing from people like Mahbub who called Stack Overflow for Teams “a revolution to the IT world.”
More efficiently find the cloud resources you needOur work with Stack Overflow for Teams is one part of our overall vision to become the most valuable destination for the world’s current and next generation of technologists. Our public platform is the other key piece of this vision. In the last quarter, we redoubled our efforts here, with a particular focus on bringing to life our core values of Learn, Share, Grow; Keep Community at Our Center; and Be Flexible and Inclusive.
First, we expanded our relationship with the big three cloud providers. Today, AWS, Microsoft Azure, and Google Cloud all have Collectives on Stack Overflow. This is an important step in our long-term evolution to allow users to self-select into smaller communities of practice that can more efficiently learn, share, and grow together.
It’s an important moment for our customers, too. AWS, Azure, and Google Cloud (in addition to our other Collectives clients) can now meet their customers where they already are and build a trusted, bilateral connection through which to share accurate, cutting-edge information and updates. That includes announcing new releases, offering direct customer support, endorsing answers to user questions, and reviewing product feedback from the community.
Combined, Stack Overflow already has 1.6 million AWS, Azure, and Google Cloud related questions and answers. We’re excited to see that number grow with the new Collectives.
Learn and grow via Stack Overflow’s new Online Learning partnersWith Collectives, we’re making it more efficient for users to find the support and knowledge they need. Today’s launch of Online Course Recommendations has a similar goal.
Stack Overflow research found the first and often most difficult challenge in a technologist’s learning journey is figuring out where to start. Our Chief Product Officer, Teresa Dietrich, spoke about this challenge in depth during her Flow State talk, and as Stack Overflow evolves the platform to empower technical communities to learn, share, and grow together, we wanted to prioritize this important community need.
“Everything moves so fast and the source of truth changes often and things that are old can just be actively bad to learn.”
Anonymous Developer, Stack Overflow qualitative research
With today’s Online Course Recommendations launch, you’ll begin to see relevant courses from two popular online learning platforms, Udemy® and Pluralsight®. These course recommendations will appear as an ad module on the right-hand side of question pages on Stack Overflow. We hope this makes it easier for technologists — 70% of whom are learning a new technology at least once a year — to find appropriate, trusted resources. Udemy and Pluralsight were chosen as launch partners for exactly this reason; our 2022 Developer Survey found many respondents are already turning to these providers for their online learning needs.
Online Course Recommendations and our new Collectives are additional steps on our path to providing all the resources you need in one place. In the future, we may expand on them by helping the communities on Stack Overflow and the Stack Exchange network discover more trusted quality content and resources; find, build, and share learning paths; create even more focused, connected communities; and have access to hands-on learning opportunities.
A year of continuous improvementAs we focus on driving productivity and efficiency with all our products, we are doing the same internally. The goal is continuous improvement in the year ahead, and we are constantly soliciting feedback across our public platform and paid products with that in mind. Based on user feedback and our own qualitative and quantitative research, we’re investing in areas where there’s a clear opportunity to solve developer and technology problems.
The Staging Ground is a great example. This new public platform feature (which will initially be found only on Stack Overflow) will allow new askers to receive guidance from more experienced community members before posting their first questions publicly.
We believe Staging Ground will make our community more welcoming and inclusive by making it easier for first-timers to learn Stack Overflow’s norms and best practices. An expanded beta is coming soon and an MVP later this calendar year.
In addition to Staging Ground, we’re also closely monitoring ChatGPT and other generative AI tools, and we’re thinking through their impact on the community and products. Generative AI is evolving rapidly, and new use cases and risks appear each day. The community is certainly engaged on the issue; we saw a 20% year-over-year spike in questions and answers with AI-related tags following ChatGPT’s release, which reversed an overall AI-related tag decline of 12% YoY.
We share the community and world’s excitement about the potential of generative AI. Our Product and Engineering teams are exploring all possibilities, and as usual, we will update and find opportunities to bring you into the conversation whenever possible.
Stack Overflow has always been built by the community for the world. I want to take a moment to highlight the critical role of our moderators on big issues like ChatGPT and on countless smaller day-to-day occurrences. In 2022, our ten most active moderators (out of 600 total) responded to over 440,000 content flags (requests for moderator action) — and our most active moderator of that group dealt with 104,000 flags alone.
Stack Overflow’s success is in a large part due to their tireless contributions, and in this year’s edition of Stack Gives Back, we are pleased to donate over $54,000 on behalf of our moderators to Doctors Without Borders, the Electronic Frontier Foundation, Girls Who Code, the International Rescue Committee, and UNICEF.
Our path to profitabilityThe next 12 months will inevitably bring more surprises and disruptive innovations. However, we are well-positioned for FY2024 regardless of what happens in the world around us. The community is strong and growing; our Stack Overflow for Teams product is increasingly mission critical; our company surpassed 500 Stackers for the very first time; and our path to profitability is clear.
In fact, at the Prosus and Naspers Capital Markets Day in December, I walked through that path and highlighted the key role of Stack Overflow for Teams on it. That’s not to say our Ads and Employee Branding businesses aren’t important. Rather, it’s a sign of how strong Stack Overflow for Teams’ performance has been.
In the first half of FY23, more than 50% of Stack Overflow revenue came from Stack Overflow for Teams — a SaaS product that only launched in 2018. We believe Stack Overflow for Teams is a powerful, sustainable, and all-weather growth engine for this company.
2022 was about investing in that engine and in the company as a whole. 2023 is about the pivot from growth towards becoming profitable again — just as we were in 2018, 2019, and 2020.
Despite the economic volatility around us, there will always be a market for organizations who help customers succeed in their technology transformations. We look forward to driving productivity, efficiency, and transformation for our customers and users in the year ahead.
The post CEO update: Eliminating obstacles to productivity, efficiency, and learning appeared first on Stack Overflow Blog.
The home team convenes to talk about how tech layoffs are reshaping the industry, where to look for software engineering jobs beyond tech, the brain-computer interface that speeds up communication for people with paralysis, and Ben’s million-dollar game idea (free for the stealing).
Episode notes:
Naturally, tech layoffs are top-of-mind for many of us. Despite comparisons to the dot-com bubble, what we’re seeing right now is different. Here’s what the tech and media layoffs really tell us about the economy.
In praise of analog technology: why Millennials and Gen Z are springing for paper maps.
Make Time, a way of “rethinking the defaults of constant busyness and distraction so you can focus on what matters every day,” was developed in response to always-on Silicon Valley culture.
Wifi routers can now be used to detect the physical positions of humans and map their bodies in 3D. Terrifyingly dystopian or interestingly practical? Why not both?
In recent accessibility news, a brain-computer interface (BCI) that converts speech-related neural activity into text allows a person with paralysis due to amyotrophic lateral sclerosis (ALS) to communicate at 62 words per minute, nearly 3.5 times faster than before. From the abstract: “These results show a feasible path forward for using intracortical speech BCIs to restore rapid communication to people with paralysis who can no longer speak.”
Shoutout to Lifeboat badge winner Holger for their answer to Sort an array containing numbers using a ‘for’ loop.
TRANSCRIPT
The post What do the tech layoffs really tell us? (Ep. 532) appeared first on Stack Overflow Blog.
I recently stumbled upon “Software disenchantment,” a post by Nikita Propokov. It called to mind Maciej Cegłowski’s post “The Website Obesity Crisis” and several others in the same vein. Among people who write about software development, there’s a growing consensus that our apps are getting larger, slower, and more broken, in an age when hardware should enable us to write apps that are faster, smaller, and more robust than ever. DOOM, which came out in 1996, can run on a pregnancy test and a hundred other unexpected devices; meanwhile, chat apps in 2022 use half a gigabyte of RAM (or more) while running in the background and sometimes lock up completely, even on high-end hardware.
The aforementioned posts on this subject come across as about 80% fair and reasonable criticism, 20% out-of-touch grumbling. Or in other words:
Most developers know better than to say things like “it’s a smartphone OS, how hard can it be?” or “my spreadsheet app in the 90s was 10 kilobytes, how come Factorio is a full gigabyte?” If you weren’t there when it was built, you can’t reliably estimate all the hard knocks and complexity that went into it.
But that doesn’t mean there’s no room for objective criticism. Apps are slower than they used to be. And exponentially larger without a corresponding increase in value. At the very least, there are optimization opportunities in almost any modern app. We could make them faster, probably by orders of magnitude. We could remove code. We could write tiny, purpose-built libraries. We could find new ways to compress assets.
Why don’t we?
Propokov’s answer is “software engineers aren’t taking pride in their work.” There’s some truth to that. But I strongly believe it’s the natural human state to work hard and make excellent things, and we only fail to do so when something repeatedly stops us. So instead of relying on the myth of laziness to explain slow and buggy software, we should be asking “what widespread forces and incentives are creating an environment where it’s hard for software engineers to do their best work?”
I have a few answers to that.
Speed is a feature, reliability is nothingSoftware is envisioned by engineers as networks of interacting components, inputs, and outputs. This model is both accurate and useful. However, it’s not the way software is packaged, marketed, or sold. To businesspeople and customers, software is a list of features.
Take an inventory management app as an example. Its marketing materials will consist of several high-res stock photos, a bold color palette, and statements like the following:
- Tracks inventory across multiple warehouses
- Integrates with Delivery Pro, Supply Chain Plus, and Super Point-of-Sale systems
- Weekly and monthly reporting at multiple levels
- Fine-grained access and security controls
- Instant updates across all terminals
- Runs on Windows, MacOS, and Linux
These are falsifiable statements; either the software does these things or it does not. They can all be proven in a one-hour product demo. And only one deals with speed. The software may in fact be very slow, taking several seconds to respond to a button click, without making the “instant updates” claim a lie.
We can all agree that speed affects a user’s entire experience of an app. It’s an important marker of quality. But it’s difficult to sell. If you spend your time optimizing a core process while your competitor develops a new type of report, you’ll lose eight of your next ten sales over it. If you poll your existing customers about what you should work on next, they’re going to ask for features, not speed—unless the software is so slow it borders on unusable. And god forbid any red-blooded board of directors would allow the company to take a six-month detour from its product roadmap to work on technical debt. The pressure is always on us to build features, features, features.
Programmers want to write fast apps. But the market doesn’t care.
You may notice reliability isn’t on the list at all. How exactly would you say that? “Bug-free?” There’s no way to ensure that, let alone prove it in a product demo. “90% unit test coverage and a full suite of integration tests?” Nobody knows what that means and if you explained it to them, they’d be bored. There’s no way to express reliability in a way customers will both believe and care about. The Agile age has taught them that bugs will inevitably exist and you’ll fix them on an ongoing basis. And since there’s no comprehensive way to measure defects in software (surely if we knew about them, we would have already fixed them?) it’s not a feature that can be compared between products. We can invest time to test, refactor, and improve, but it’s entirely possible no one will notice.
Programmers want to write bug-free apps. But the market doesn’t care.
Disk usage isn’t on the list either, though occasionally it appears in small, low-contrast print below a “Download” button. And of everything here, this one is perhaps least connected with competitiveness or quality in customers’ minds. When was the last time you blamed a developer (as opposed to yourself or your computer) when you ran out of disk space? Or chose between two video games based on download size? Probably never. You can find people who complain about the size of the latest Call of Duty, but the sequels still make a billion dollars the week they come out.
Shrinking an executable or output bundle is thankless work. And it’s often highly technical work, requiring an understanding of not just the app one is building but the hundreds of lower-level libraries it depends on. Furthermore, it’s actively discouraged (“don’t reinvent the wheel”), partially because it’s a minefield. You may not know what a line of code is for, but that doesn’t mean it’s useless. Maybe it’s the difference between a working app and a broken one for the 0.01% of your customers that use Ubuntu on a smartphone. Maybe it’s the one thing keeping the app from crashing to a halt every four years on Leap Day. Even the smallest utility function eventually develops into an artifact of non-obvious institutional knowledge. It’s just not worth messing with.
Some programmers want to write smaller apps. But the benefits aren’t there for the market or for us.
Consumer software is undervaluedIt’s not hard to distribute an app. That’s more or less what the Internet is for. But selling an app is like pulling teeth. The same general public who will pay $15 for a sandwich or a movie ticket—and then shrug and move on if they didn’t like it—are overcome by existential doubt if an app they’re interested in costs one (1) dollar. There are only two demographics that are willing to pay for good software: corporations and video gamers. We’ve somehow blundered our way into a world where everyone else expects software to be free.
This expectation has been devastating to the quality of consumer apps. Building an app costs anywhere from 50,000 to half a million dollars. If you can’t get people to pay on the way in, you have to recoup costs some other way. And herein are the biggest causes of bloat and slowness in both web and native applications: user tracking, ads, marketing funnels, affiliate sales, subscription paywalls, counter-counter-measures for all the above, and a hundred even-less-reputable revenue streams. These things are frequently attributed to greed, but more often they’re a result of desperation. Some of the most popular websites on the Internet are just barely scraping by.
It’s hard to overstate the waste and inefficiency of a system like this. You publish a unique, high-quality app for what you believe to be a fair price. It sits at zero downloads, day after day. You rebuild it on a free trial/subscription model. It gets a few hundred downloads but only a handful of users convert to a paid plan, not nearly enough to cover your costs. You put ads in the free version, even though it breaks your UI designer’s heart. You find out that ad views pay out in fractions of a cent. You put in more ads. Users (who, bafflingly, are still using the app for free) complain that there are too many ads. You swap some ads for in-app purchases. Users complain about those, too. You add call-to-action modals to encourage users to pay for the ad-free experience. You find out most of them would sooner delete the app. You add analytics and telemetry so you can figure out how to increase retention. You discover that “retention” and “addiction” might as well be synonyms. The cycle goes on, and before long you no longer have an app; you have a joyless revenue machine that exploits your users’ attention and privacy at every turn. And you’re still not making very much money.
We could avoid all of this if people were willing to pay for apps. But they’re not. So apps are huge and slow and broken instead.
Developers don’t realize the power they haveLest I be accused of blaming everyone but myself, let’s examine the role of software developers. There has to be something we can do better.
Even in a recession, developers have an extraordinary amount of leverage. We can insist on working with (or not working with) specific technologies. We can hold out for high salaries, benefits, and equity. We can change the culture and work environment of an entire company by exercising even the slightest amount of solidarity. Good programmers are hard to come by. Everyone knows it, and we know they know it.
That’s our power, and we can do more with it.
We should set aside time in every sprint to resolve technical debt. We should procrastinate feature work now and then when there’s an especially promising opportunity to optimize and improve our code. We should persuade our employers to sponsor open-source projects. We should create the expectation that we won’t always be working on the product roadmap; our code and our industry expect more of us.
Most of the time there won’t be any negative consequences. We’re not asking too much. Every other industry has professional standards and requirements that transcend any one job description. Why do we so often act like software development doesn’t?
The only caveat is that the incentives aren’t in our favor. It’s an uphill battle. Some managers won’t be comfortable with us spending time on things they don’t understand. Some salespeople will worry that our software isn’t competitive. Investors may threaten to outsource our work to more pliable developers. It will be a while before customer attitudes and market forces shift. But if changing the state of modern software is a worthy goal, then it’s worth the effort.
Will it get better?It’s hard to be optimistic about the future of software. Programmers were allowed to build tiny, highly-optimized apps in the 90s because there was no other choice. Their customers had 32 megabytes of RAM and a 200 megahertz single-core processor. If an app wasn’t as lean as possible, it wouldn’t run at all. Today, a two-year-old base-model Macbook Air has 250 times as much memory (not to mention faster memory) and a quad-core processor with several times the speed on any one core. You can get away with a lot more now. And we do. We ship apps that are 90% dead weight. We don’t optimize until someone complains. We package a full web browser installation with apps for sending messages, taking notes, even writing our own code (I’m using one right now).
The last two decades have been dedicated to making software development faster, easier, and more foolproof. And admittedly, we’re creating apps faster than ever, with more features than ever, using less experienced developers than ever. It’s not hard to see the appeal from a business perspective. But we’re paying the price—and so are our customers, the power grid, and the planet.
Things won’t change overnight, probably not even in the next five years. But there are reasons to be hopeful.
The latest wave of web programming languages and technologies (like WebAssembly, ESBuild, SWC, Bun, and Yew) is enabling new levels of speed and reliability, both at compile-time and runtime. Rust, noted for delivering the performance of C and the developer-friendliness of higher-level languages, is gaining popularity on web servers. Lightweight Electron alternatives like Tauri are poised to take over as the web developer’s cross-platform framework of choice. Tree-shaking is something we’ve come to expect from compilers and bundlers.
In terms of the market, several popular video games (like Dead Cells and The Binding of Isaac) have made their way to mobile platforms as paid downloads. There’s still a lot of work to be done, but this is promising headway towards reeducating smartphone users, the world’s largest group of technology consumers, about the cost of software.
If the last 20 years have been about making us more productive—sacrificing efficiency and financial sustainability in the process—perhaps the next 20 will be about tackling our collective technical debt, reclaiming efficiency, and improving economic exchange without losing the productivity that’s made software omnipresent in our lives.
The post Is software getting worse? appeared first on Stack Overflow Blog.
Welcome to ISSUE #162 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: writing guardrails for dynamic programming languages, parenting in the face of boring stories, and spotting the bots in the fediverse.
From the blogMicrosoft Azure joins Collectives on Stack Overflow stackoverflow.blog
There’s now a destination on Stack Overflow for all things Azure.
Minimizing the downsides of dynamic programming stackoverflow.blog
Dynamic languages allow for a lot of flexibility in typing — sometimes too much. Here’s how to add some guardrails to your code.
How Intuit improves security, latency, and development velocity with a service mesh stackoverflow.blog
There are lots of interesting features a mesh can automatically add to service architecture.
Flake it till you make it: how to detect and deal with flaky tests (Ep. 528) stackoverflow.blog
But it works on my machine at least half the time!
Need SAML auth? Use WorkOS promotion
WorkOS makes it fast to build enterprise features like SAML & SCIM. Integration is a breeze with beautiful API docs and SDKs. Join hundreds of companies using WorkOS—including Vercel, PlanetScale & Webflow—and make your app Enterprise Ready today.
Interesting questionsWhen was the term ‘directory’ replaced by ‘folder’? retrocomputing.stackexchange.com
It changed to reflect the way using computers evolved.
Is every feature of the universe logically necessary? philosophy.stackexchange.com
You’ll want to sit down for this one, hence, a chair.
How can I handle kids telling me extremely boring stuff? parenting.stackexchange.com
Listen, don’t blame this on kids. Anyone talking to you about playing video games in detail is boring.
Was the shot-on-the-ISS movie “The Challenge” ever released or is there a release date? space.stackexchange.com
It’s not on the schedule yet. They don’t have any more space.
Links from around the webWhy not document.write()? csswizardry.com
Using document.write() will almost always work in the browser, but it’s not recommended.
SSSVG: An Interactive SVG Reference fffuel.co
SVG is a deep technology to learn. Here’s a great reference guide to help you along the way.
What kind of bots are posting in the fediverse? botwiki.org
As the fediverse grows, the bots have found their way in as well.
A blast from the past: How to prevent scope creep when managing a project from home.
The post The Overflow #162: The great testing flake off appeared first on Stack Overflow Blog.
Cassidy and Ceora are joined by Ben Holmes and Nate Moore, developers on the core Astro platform, to talk about the new features they’re working on, what they love about docs, and the role of open source in their work.
Episode notes:
Astro is a site builder that lets you use the frontend tools you already love (React, Vue, Svelte, and more) to build content-rich, performant websites. Astro extracts your UI into smaller, isolated components (“islands”) and replaces unused JavaScript with lightweight HTML for faster loads and time-to-interactive (TTI).
Ben and Nate explain why Astro’s compiler was written in Go (“seemed like fun”).
To learn more about Astro, start with their docs or see what people are doing with the framework.
Connect with Ben on LinkedIn, GitHub, or via his website.
Connect with Nate on GitHub.
Shoutout to Lifeboat badge winner Aurand for their answer to How to convert list to queue to achieve FIFO.
TRANSCRIPT
The post The less JavaScript, the better (Ep. 532) appeared first on Stack Overflow Blog.
It’s 2023 (we made it!) and after joining Stack Overflow in September 2022, one of my first tasks as a senior research analyst was to pull together statistics for our year-end wrap-up, and to which the natural follow-up question was asked of me, “is this what we expected to see?”
I didn’t know, so I dug into two of Stack Overflow’s exceptional data sources: the annual Developer Survey results and stackoverflow.com’s website data. For research, marrying qualitative and quantitative sources is key in order to validate assumptions and explore the story in the gray area between explicit and implicit behavior.
The 2022 Developer Survey collected responses from Stack Overflow users around the world to find out what programming languages and software development tools are the most popular. And because we’ve been doing this survey for 10+ years, we can see trends in growing (or declining) popularity. We can then use our website data to validate the survey sentiment by looking at what users ask about most.
In this article, we will take a look at what the recent past tells us about what developers will be loving and/or questioning in 2023.
First, I’ll look at what proxies we could use to quantify programming language popularity. Then, I’ll compare this to trends for questions posted about programming languages, using a simple regression analysis in order to elucidate and explain possible relationships between stated popularity and questions asked on Stack Overflow.
Most popular and according to whomNo source of information is better at tapping into developer sentiment than our own Developer Survey. What languages did the developer community tell us they loved in 2022?
In the survey results for Most Loved, we categorize everything so it’s easier to compare like-to-like (i.e. languages vs. frameworks vs. libraries, etc.). I’m going to take a cue from the survey and focus on programming languages for this question; drawing comparisons within types makes sense and avoids introducing another layer of complexity.
Rust, Elixir, Clojure, Typescript,and Julia are at the top of the list of Most Loved Programming Languages. However, in looking at the last three years, we see a bit of movement.
Most Loved Rank in Developer Survey
In 2022, we added a drill-down to specifically show popularity amongst those learning to code. Because Stack Overflow is a learning resource, I would expect that popularity amongst those specifically learning would be a good indicator of current and future programming language popularity.
There is an interesting pattern in comparing Most Loved and Learning to Code Popularity: people learning to code aren’t using the most loved languages. The difference between these two measures of popularity will be important in distinguishing both as possible explanatory variables for trends in question posts. Less than 1% of those learning responded they were using either Clojure or Elixir:
- 1.2% are using Julia
- 7.1% are using Rust
- and 15.1% are using Typescript.
How else might we set up expectations for trends amongst the many programming languages being asked about on Stack Overflow? I found two good sources that are worthy proxies for popularity: Google and GitHub.
For web searches, I’m using the already established PYPL index, which is an aggregated source for Google Trends data specifically for programming language tutorial search history. From this dataset, we will focus on annual trends in programming languages share of search.
GitHub publishes statistics on public repositories for anyone to use as a handy public dataset within Google BigQuery, and although we lose the information from private repositories, we can assume the public accounts speak more directly to popularity as they are tied to learning initiatives, portfolios, and open-source collaboration, which are mostly self-directed rather than mandated by existing business rules. From this dataset, we will focus on the annual trend in public repo pull requests by language.
Looking at the basic relationship between Most Loved percent and annual rank in questions asked, we see a slight relationship over the years, but not a strong one. The simple regression here shows 2022 has the strongest correlation in the last three years and that only 7% of the variation in ranking for 2022 questions asked can be explained by 2022 Dev Survey results for most loved programming languages.
This graph shows that being loved (via the Developer Survey) is not related to generating more questions on Stack Overflow. And this makes sense: posting questions most likely speaks to friction with coding, a friction that may lead to loving a programming language less.
When we add in our additional proxy variables for language popularity, usage percentage among those learning to code in the 2022 Developer Survey, the trend in PYPL from 2021 to 2022, and the trend in Github pull requests from 2021 to 2022, we get better regression results. Using just Learning to Code Popularity gets us a better regression that explains 67% of the variation in ranking for 2022 questions. A logical conclusion here is that Stack Overflow questions are more susceptible to the preferences of those using the site as a learning tool rather than those of more advanced developers.
Adding in the other popularity proxies and loved percentage gains us additional regression power (75% variation explained!) and we have landed on our final answer: trends in the number of questions posted about a programming language on Stack Overflow can be explained by what more developers learning to code are using (most significantly of all factors) along with Google search trends, GitHub public pull requests, and the Developer Survey Most Loved percentage (less significantly of all factors). Our latest Developer Survey showed us that ~32% of programmers have been professionally coding for four years or less, a significant amount of people who are most likely involved in learning programming languages. That is, beginner-friendly languages get the most questions and popularity, but the Most Loved languages make veteran developers happy.
A peek into the last three yearsLet’s look at the top tags from questions asked in 2022 and how they line up with what we would expect from the regression model above.
We counted the number of questions associated with each unique tag; each can have up to five tags, so questions will get counted more than once. Python and JavaScript are solidly positioned in their respective top spots, Reactjs and Java show competing question counts starting towards the end of 2021, and ultimately Reactjs takes the lead with consistently more questions tagged in 2022. HTML and C# switch spots monthly in 2021, though C# moves ahead in 2022 with consistently more questions. In the lower ranks, Pandas sees three years of growth, R increases rank in 2021 and holds, nodejs breaks into the top 10 in 2021 and holds, while both PHP and C++ decline.
Compared to our learning to code popularity metric, Python, JavaScript, and Java are inline with expectations being at the top of both lists. According to the same metric, we would expect more questions about SQL and PHP. This shows that there is more to the trend than just measurable popularity. The factors that lead up to searching for tutorial on Google or GitHub pull requests from public repositories, for example, could be influenced by content creation in the academic and online learning spaces, which in turn could be influenced by nuances in tech evolution (e.g. Python-3.x as a short-lived top-ranked tag before it became the standard version). The next Developer Survey will be the canary in the coalmine illuminating any changes in expectations for the types of questions being asked on Stack Overflow.
The post Comparing tag trends with our Most Loved programming languages appeared first on Stack Overflow Blog.
SPONSORED BY INTUITIn complex service-oriented architectures, failure can happen in individual servers and containers, then cascade through your system. Good engineering takes into account possible failures. But how do you test whether a solution actually mitigates failures without risking the ire of your customers? That’s where chaos engineering comes in, injecting failures and uncertainty into complex systems so your team can see where your architecture breaks.
On this sponsored episode, our fourth in the series with Intuit, Ben and Ryan chat with Deepthi Panthula, Senior Product Manager, and Shan Anwar, Principal Software Engineer, both of Intuit about how use self-serve chaos engineering tools to control the blast radius of failures, how game day tests and drills keep their systems resilient, and how their investment in open-source software powers their program.
Episode notes:
Sometimes old practices work in new environments. The Intuit team uses Failure Mode Effect Analysis, (FMEA), a procedure developed by the US military in 1949, to ensure that their developers understand possible points of failure before code makes it to production.
The team uses Litmus Chaos to inject failures into their Kubernetes-based system and power their chaos engineering efforts. It’s open source and maintained by Intuit and others.
If you’ve been following this series, you’d know that Intuit is a big fan of open-source software. Special shout out to Argo Workflow, which makes their compute-intensive Kubernetes jobs work much smoother.
Connect on LinkedIn with Deepthi Panthula and Zeeshan (Shan) Anwar.If you want to see what Stack Overflow users are saying about chaos engineering, check out Chaos engineering best practice, asked by User NingLee two years ago.
TRANSCRIPT
The post How chaos engineering preps developers for the ultimate game day (Ep. 531) appeared first on Stack Overflow Blog.
Application security has come a long way these past couple of decades. In the early 2000s, SQL injection and Cross Site Scripting (XSS) attacks were a nightmare for cybersecurity teams as attackers easily bypassed network firewalls through attacks at the application layer. Since traditional network firewalls at that time were not application-aware, these attacks proved a blind spot allowing attackers to compromise web applications easily.
The industry quickly bounced back, however, and web application firewalls (WAF) and source code security reviews became a standard part of most cybersecurity checks. Now we have DevSecOps, who automate these checks within CI/CD pipelines to and allow security at speed with dynamic application security testing (DAST) and static application security testing (SAST) solutions becoming commonplace.
However, a new trend is growing that has the potential to be another blind spot like the SQL injections of the previous decades unless controls are put in place.
These are attacks targeting AI and machine learning systems.
AI and machine learning systems AI and machine learning is easily one of the most disruptive technologies of recent years and is being adopted across the globe by companies and governments alike. Even cybersecurity products are now boasting the “powered by AI” label as they adopt machine learning algorithms to boost their capabilities and stop cyberattacks in real-time without human input.
These models are trained on data to build up their decision-making abilities, similar to how a human being learns from trial and error. Basically, the more data a machine learning model is trained on, the more accurate it becomes. Once deemed fit for production, these models are placed behind applications that typically expose public APIs, which can be queried for results.
However, the adoption of these applications in sensitive industries like hospitality, medicine, and finance, along with their access to sensitive training data, makes them prime targets for attackers. As a result, a new breed of attacks is developing that are targeting the workings of machine learning applications.
Why AI is a blind spot in cybersecurity Cybersecurity teams typically assess an AI application via traditional security processes such as hardening, patching, vulnerability assessments, etc. These are carried out at the infrastructure and application levels. While this is all good practice, these assurance processes do not cover AI specific attacks such as data poisoning, membership inference, model evasion, etc.
In these types of attacks, cybercriminals are not interested in compromising the underlying infrastructure or carrying out SQL injections but in manipulating the way in which AI and machine learning applications reach decisions.
This allows them to:
- Interfere with the workings of AI applications and make them reach the wrong decisions.
- Find out how the model works so they can reverse engineer it for further attacks.
- Find out what data the model was trained on, revealing sensitive characteristics they are not supposed to know.
These attacks have been growing in number and have been successfully carried out against production-based AI applications listed here.
Let us take a look at some of the most common attacks, like inference, evasion, and poisoning and how we can harden our ML applications against them.
Inference attacks During inference attacks on AI applications, an attacker attempts to discover the inner workings of a model or what type of data was used to train it. The APIs exposed by ML models may provide responses as confidence scores and give stronger scores if the data they are fed matches the data they were trained on. With access to this API, the attacker can start running queries and analyzing the responses from the machine learning model. In one example, attackers could reconstruct the faces used to train a machine learning model by analyzing the confidence rate of different images submitted to it. By submitting multiple, random images and looking at the responses, the attackers were able to reconstruct the training images with up to 95% accuracy.
This sort of attack can result in the AI model disclosing highly sensitive data, especially in industries that deal with personally identifiable information. Most companies do not build machine learning models from scratch and usually rely on pre-built models, which are hosted on cloud platforms. A successful attack against one of the models can enable the attacker to compromise multiple AI applications in a supply chain attack.
Poisoning attacks Another attack can occur on the actual training data itself, where the attacker can essentially “pollute” the data on which the model is being trained to tamper with its decision-making. Like pre-built models, most companies again do not want to create training data from scratch and often leverage pre-built training data, which they run through their machine learning models. If an attacker can compromise this data repository via a security vulnerability and inject his own data into this store, then the machine learning model will be trained to accept a malicious input right from the start. For example, an attacker can input data into a self-driving vehicle’s data store that trains it to recognize objects when driving. By changing the labels of the data, the actual working of the vehicle can be tampered with.
Attackers usually bide their time and wait for the data store to reach a certain level of market acceptance before trying to “poison” them. Model training is also not a one-time activity. A data store might be completely fine in the beginning and then later polluted by an attacker further down the road once they are confident they will not be detected.
Evasion attacks Another attack on AI systems is evasion attacks, in which attackers attempt to trick models by providing subtly changed data. It has been proven that making small changes to an image that are not noticeable to a human can result in dramatically different decisions being made by machine learning models. This data type is referred to as an adversarial sample and can trick AI-powered systems such as facial recognition applications or self-driving cars.
For example, simply putting pieces of tape onto a stop sign can result in a machine learning model not recognizing it, which could cause car accidents. Or tricking a medical system for the purposes of committing fraud
The way forward AI-based attacks are becoming more and more common, and cybersecurity teams need to upskill to understand this new breed of application attacks. In this year’s Machine Learning Security Evasion Competition (MLSEC 2022), it was demonstrated that it was trivially easy to evade facial recognition models via minor changes.
Cybersecurity teams need to be skilled and made aware of these attacks so they can be proactively highlighted in the initial design reviews. Resources like MITRE ATLAS, which describes itself as a knowledge base of attacks against machine learning models, are a great resource for teams to get up to speed quickly.
As mentioned before, traditional cybersecurity controls will not protect against these vulnerabilities, and new types of controls need to be put in place. Similar to how application security evolves and emerges as a separate domain within cybersecurity, AI security needs to do the same quickly. AI applications are already involved in critical decision-making in industries such as healthcare, financial institutions, and law enforcement and present a prime target for cyber attackers.
Given that there is no quick patch to fix these issues, a culture of AI security needs to be developed so that these controls are implemented at multiple levels. Some of the key controls that can be implemented are:
- Threat modeling of machine learning models should be carried out and made a standard practise before choosing any new or pre-built model. Guidelines like the UK’s National Cyber Security Centre have resources like “Principles for the security of machine learning” are a great reference point.
- Detection controls need to be updated to alert if a particular attacker is repeatedly querying a particular machine learning API. This could be indicative of an inference attack.
- Models should be hardened to sanitize confidence scores in their responses. A balance between usability and security needs to be struck with developers possibly being provided full confidence score details while end users only need a summarized score. This would greatly increase the difficulty for an attacker to assess the underlying logic or data that the model was trained on.
- Machine learning models should be trained on adversarial samples to assess their resilience to such attacks. By subjecting the model early to such samples, companies can quickly identify gaps in their learning and remediate the same.
- Data stores being used to train machine learning models should undergo rigorous security testing to make sure they do not contain vulnerabilities that may allow attacks to gain access to their data and poison them. Similarly, the data that was “clean” at one time might get poisoned at a later stage, hence it is essential to verify that a model is working correctly every time it refreshes its training data or is trained on new data. Quality teams should subject the model to various tests and verify previous results to make sure it is still working optimally and no “poisoning” has occurred.
- Lastly, companies should have a policy around using public or open-source data for training. While they are easier to use for training models, a compromise of the data store could lead to the model being corrupted in its training.
It is clear that AI attacks are only poised to increase with time, and awareness amongst cybersecurity teams is currently lacking. Unless proper technical controls and governance are implemented, these attacks will create the same havoc as SQL injections did a few decades back.
The post AI applications open new security vulnerabilities appeared first on Stack Overflow Blog.
The team talks about voice-to-code features, how game developers built accessibility into God of War, and why lab-grown meat is officially safe to eat (hail seitan!). Plus: this YouTube channel is a strong contender for the most entertaining robotics content on the internet.
Episode notes:
In a win for accessibility, GitHub Copilot now responds to voice commands, allowing developers to code using their voices.
Speaking of accessibility, learn how Santa Monica Studio worked with disabled gamers and the community to build accessibility into God of War Ragnarök.
The US Food and Drug Administration (FDA) has determined that lab-grown meat is safe to eat.
Looking for some high-quality entertainment content? Look no further than Simone Giertz’s YouTube channel, where she builds robots to (among other things) wash her hair and wake her up with a slap in the face.
Blast from the past: Listen to our episode with MongoDB CTO Eliot Horowitz.
Shoutout to Lifeboat badge winner ralf htp for their answer to How to listen for and react to Ace Editor change events.
TRANSCRIPT
The post From your lips to AI’s ears (Ep. 530) appeared first on Stack Overflow Blog.
The home team talks about how engineering blogs create real value for software companies, a game-changing accessibility controller for PS5, and how to build a universal computation machine using Tetris. Plus: Is this podcast responsible for Instagram’s decision to boot the shopping tab from the home feed? Maybe!
Episode notes:
First, some self-administered back-patting for the Stack Overflow editorial team: great engineering blogs give tech companies an edge (The New York Times says so).
Hiring aside, engineering blogs are fresh sources of knowledge, insight, and entertainment for anyone working in tech. You can learn a lot from, for instance, blog posts that break down an outage or security incident and detail how engineers got things up and running again. One classic of the genre: Amazon’s explanation of how one engineer brought the internet to its knees. And here’s an example from our own blog.
When you’ve finished catching up on the Stack Overflow blog, check out those from Netflix and Uber.
Good news for late-night impulse shoppers: Instagram is removing the shopping tag from the home feed, reports The Verge. Is this a response to widespread user pushback, and does this herald the end of New Instagram? We can hope.
Sony announces Project Leonardo, an accessibility controller kit for PS5.
Did you know? Using only Tetris, you can build a machine capable of universal computation.
Developer advocate Matt Kiernander is moving on to his next adventure. If you’re looking for a developer advocate or engineer, connect with him on LinkedIn or email him.
One of Matt’s favorite conversations on the podcast was our episode with Mitchell Hashimoto, cofounder and CEO of HashiCorp. It’s worth a (re)listen.
TRANSCRIPT
The post How to build a universal computation machine with Tetris (Ep. 529) appeared first on Stack Overflow Blog.
Welcome to ISSUE #161 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week, we celebrate our annual tradition of giving to charity in our moderators’ names, astronauts wonder how tall you need to be to fly to the moon, and the Furby source code lets you plot your own M3gan scenario.
From the blogBeyond Git: The other version control systems developers use stackoverflow.blog
Our developer survey found that 93% of developers use Git. So what are the other 7% using?
Stack Gives Back 2022! stackoverflow.blog
Let’s start the year on a high note! We’re excited to announce our 14th Stack Gives Back.
Taming multiple design system with a single plugin stackoverflow.blog
Intuit shares their platform-based approach to managing a design system and how they’re using AI to keep the brand consistent.
From CS side project to the C-suite (Ep. 525) stackoverflow.blog
Find out why your users were rage clicking, once and for all.
Beginner’s Guide to Getting Started in DevOps promotion
Get practical information about what DevOps is and how a collaborative culture will benefit your work and company. GitLab’s detailed list of resources and real-world examples provides you with opportunities for continuous learning.
Interesting questionsWhat type of abrasive grit was used to grind lenses for telescopes? hsm.stackexchange.com
How accurate do you want your Galileo cosplay to be?
Why was there a minimum height for astronauts? space.stackexchange.com
Just like rollercoasters, astronauts need to “be this tall” to ride.
Travel in western Ukraine: how safe / unsafe is it? travel.stackexchange.com
A traveler asks about seeing the beauty in the world in a time of war and violence—what’s the right thing to do?
CPU temperature often reaches 100°C unix.stackexchange.com
Idea: let your CPU boil water for your tea (just kidding, don’t try this at home).
Links from around the webFurby 1998 source code: David Hampton, Wayne Schulz archive.org
If only there was a way to relive the 90s via code…oh wait, there is! Now if someone could code some flannel CSS themes.
3D in CSS garden.bradwoods.io
This is a fun, handy guide to visualizing 3D concepts in CSS!
Implementing CSS style inheritance in React Native www.builder.io
Styling certain things doesn’t always work in React Native. But with the right know-how and some CSS cascading magic, this case study shows how to fix the problem.
Facts and Figures 2022: Latest on global connectivity amid economic downturn www.itu.int
Being on the computer all day means that we spend a lot of our lives in bubbles (and take internet access for granted). Here are some mind-expanding statistics about the digital divide.
A blast from the past: How developers can be their own operations department.
The post The Overflow #161: Git isn’t the only game in town appeared first on Stack Overflow Blog.
Many moons ago, the majority of software development was done using statically typed and compiled languages, the most popular ones being C, C++, and then Java. When dynamic languages began to take off, at first they were derided as “toy” languages, an epithet most commonly associated with JavaScript. Over time, the advantages of interpreted, dynamic programming began to win the hearts of the community.
Today, especially in the web app world, you’re as likely to work with a dynamic language as with a static one. JavaScript and Python are consistently within the top five popular languages today, with others such as PHP and Ruby always in the mix.
Dynamic programming languages come with a host of benefits, including:
- They are interpreted rather than compiled, which means there is no additional process to run or time to wait when executing the code.
- The code itself is typically much more concise, since you don’t spend as much time defining and casting types.
- You can create domain specific languages (DSLs), where you can define application routes or configuration in a much more natural-looking way.
- You can typically “open up” or “monkey patch” types at runtime and make changes to them, allowing you to easily add functionality even to objects owned by third-party libraries.
- You can have mixed-type collections such as arrays and dictionaries, something which is hard or impossible to do with statically typed languages.
- Type coercion is typically less painful—rather than having to override a function many times with the different permutations of input parameters, you can have one function definition that takes an argument of any type and coerce it to whichever one you need.
- Metaprogramming frees you from the stricture of third-party code and allows you to make minor changes to it without having to wait for the fork/pull request/merge flow, which can take months or years depending on the project.
The astute among you will likely have noticed that pretty much every single item on this list can be interpreted as a downside as well as an upside. Taking these one at a time:
- Interpreters won’t catch as many problems as compilers.
- Being less precise about types introduces additional errors.
- DSLs can be confusing and add to the mental load you’ll be carrying for the application and language.
- If anyone can open up a type, they can easily misuse what should be internal code.
- Mixed-type collections tend to be used incorrectly and confusingly.
- A single function definition for many types can get messy.
- Monkey patching third-party classes can result in stale code and difficulty upgrading.
As dynamic languages have grown more popular, practitioners have had spirited discussions as to how to solve many of these problems. My own feelings about dynamic languages have slowly tempered my excitement about the freedom they provide with a strong dread of the pitfalls.
My primary work language at the moment is Ruby, which is possibly the “most dynamic” of the popular dynamic languages. However, even in Ruby, I’ve found a set of practices which I feel can help mitigate some of the downsides of dynamic programming.
Type hints exist. Use them.Over the past decade, every one of the major dynamic programming languages have introduced some kind of type hint capability. The most famous and widely-used is probably TypeScript, which is essentially a superset of JavaScript that requires a transpiler to turn the code into “regular” JavaScript. Both Python and PHP have introduced type hints as part of their standard library, and even Ruby has experimented with the RBS and Sorbet projects (sadly, there doesn’t seem to be a torrent of support for either).
Type hints are the most obvious way to make a dynamic language more static. In effect, you get the best of both worlds: you can write dynamic code but are required to be more careful about what types you expect to get and use at any point.
Good type hint systems are ironically much more complex than static languages’ type systems usually are. In Java, you can’t declare that an object’s property can be an integer or a string—but TypeScript makes this dead easy with union types:
printLabel = (label: string|number) => string { console.log(`Please fill out ${label}`);}
This is because type hint systems don’t try to turn dynamic languages into static languages; they merely provide a way for you to document your expectations in a way that machines can understand and enforce, either at compile-time or runtime.
Finally, most type hint systems allow gradual typing, where you can turn the hints on for one file at a time, rather than have to convert your entire codebase at once. You can make use of this to slowly move your code over to your type system rather than require a multi-month project to do it all together.
Dictionaries are for unknown dataA common pattern in dynamic languages is to use a dictionary or hash as a way of representing unstructured data. When returning data from a function or passing options to a function, dictionaries often are the method used:
def configure(options={}) self.logger = options[:logger] self.host_name = options[:host_name]end
or:
return { count: 5, average: 10}
These dictionaries can provide no type hints because they are meant for arbitrary key-value pairs. Using them to represent known data makes it harder to infer types or to find errors. In the first example, if you accidentally pass :loger instead of :logger, it will simply set your logger to null rather than throw an error (which is what you really want, since it’s a mistake in the calling code rather than the data).
For type hint systems that support interfaces or duck typing, such as TypeScript, you can continue to make use of this feature:
interface CountResult { count: number; average: number;}getCount : CountResult = () => { return { count: 5, average: 10} };
For languages that don’t support this, use structs or data classes. This is a simple type, often immutable, that contains a set of fields:
ConfigurationOptions = Struct.new(:logger, :host_name)def configure(options=ConfigurationOptions.new) self.logger = options.logger self.host_name = options.host_nameend
The simple move from index-notation to dot-notation introduces a level of type safety that you can get without any type hint system at all. If the method doesn’t exist, an error will be thrown and you’ll know it right away.
Even if you’re not using a type hint system, you can document your fields. Many IDEs will pick up on these comments and will help you with auto-completion. This might make for a more verbose definition, but it’s much easier to reason about:
class ConfigurationOptions # @return [Logger] attr_accessor :logger # @return [String] attr_accessor :host_name
Limit your frameworksWhat’s the difference between a framework and a library? There probably isn’t an accepted definition, but in my mind, a framework takes over your code. You’re no longer writing Ruby, you’re writing Ruby on Rails. You’re no longer writing Python, you’re writing PySpark. The code has its own look and feel that differs from your vanilla language. Libraries, by contrast, are something that you call when you need them and don’t look significantly different from your own code.
Frameworks exist in static languages, of course—Java with Spring Boot looks very different from plain Java. In dynamic languages, though, the existence of DSLs means it practically looks like you’re writing a completely different language entirely. Here’s how you define routes in Rails, for example:
Rails.application.routes.draw do resources :users, only: [:show] do post :log_in endend
My strong feeling in this area is that you should limit the number of frameworks in your app. Typically you’ll use one “big” framework (like Rails or Spark)—once you have that big framework, try not to include other dependencies that will make your code look even more different, especially if they try to be “smart” and do metaprogramming or reflection to act on your application’s code.
I’ve been guilty of this even very recently, by writing a configuration library that defines a DSL rather than a more explicit way of interacting with the configuration options. Since then I’ve come further down on the side of being explicit. Speaking of which…
Be more explicit than you need to beStatic languages enforce explicitness, often to the point of rigidity. If you want to know what a piece of code is doing, it’s easy: you ctrl-click into it and follow the call stack down. There is no “magic” involved.
For dynamic languages (and in this case I’m including languages like C that allow for defining macros), it becomes much harder to do. Dynamic languages often fail the “grep test”—if I see a method or a particular syntax, can I find where it’s defined by searching the codebase and/or dependencies? If not, it’s doing too much metaprogramming.
The only real things that should ever be doing metaprogramming or reflection are frameworks themselves. You can design your own internal framework—that’s totally fine! If it’s meant to solve a common problem unique to your team or company, that’s the sweet spot for frameworks. But don’t assume that people know every warp and weft of the effects of what you’re providing them if it’s not explicit.
How do you know if you’re not being explicit? If you look at a problem and think, “I can solve this really concisely, or I can take the time to lay out all the bits and pieces so they’re visible, and I don’t want to spend time doing that,” nearly always, you should spend time doing that.
Here’s another example. In our Rails app, there are a number of job types associated with a flyer. One way to define these associations is by looping over the job types:
JOB_TYPES = [:process_image, :upload_image, :process_tagging]JOB_TYPES.each do |type| has_many "#{type}_jobs"end
This works! But if I see flyer.process_image_jobs somewhere in my codebase, how on earth am I going to know where it comes from?
It’s more work—but more informative—to be explicit:
has_many :process_image_jobshas_many :upload_image_jobshas_many :process_tagging_jobs
In general, try not to violate the Principle of least astonishment. This means:
- Don’t monkey patch or change behavior of objects that aren’t yours, especially base types.
- Don’t create methods programmatically; make sure you can search your codebase for whatever you write.
- Try not to use implicit state (like the
thiskeyword in JavaScript outside the scope of a class). Be explicit about what object is being worked on. - Don’t wire up code automagically (e.g. by reading a particular file structure—StimulusJS does this and it’s one of the things I don’t like about an otherwise really nice package).
There is definitely a time and a place for being fancy. Choose your spots wisely!
Don’t be temptedDynamic languages give you plenty of freedom—enough rope to hang yourself, as they say. Enjoy the freedom, but try to think more statically when you can.
The post Adding structure to dynamic languages appeared first on Stack Overflow Blog.
SPONSORED BY INTUITAt an SaaS company like Intuit that has hundreds of services spread out across multiple products, maintaining development velocity at scale means baking some of the features that every service needs into the architecture of their systems. That’s where a service mesh comes in. It automatically adds features like observability, traffic management, and security to every service in the network without adding any code.
In this sponsored episode of the podcast, we talk with Anil Attuluri, principal software engineer, and Yasen Simeonov, senior product manager, both of Intuit, about how their engineering organization uses a service mesh to solve problems, letting their engineers stay focused on writing business logic. Along the way, we discuss how the service mesh keeps all the financial data secure, how it moves network traffic to where it needs to go, and the open source software they’ve written on top of the mesh. This is the third episode in our series with them.
Episode notes:For those looking to get the same service mesh capabilities as Intuit, check out Istio, a Cloud Native Computing Foundation project.
In order to provide a better security posture for their products, each business case operates on a discrete network. But much of the Istio service mesh needs to discover services across all products. Enter Admiral, their open-sourced solution.
When Intuit deploys a new service version, they can progressively scale the amount of traffic that hits it instead of the old version using Argo Rollouts. It’s better to find a bug in production on 1% of requests than 100%.
If you want to learn more about what Intuit engineering is doing, check out their blog. Congrats to Great Question badge winner, HelpMeStackOverflowMyOnlyHope, for asking Detect whether input element is focused within ReactJS
The post How Intuit improves security, latency, and development velocity with a service mesh appeared first on Stack Overflow Blog.
Cloud technologies are constantly evolving and modernization has become an always-on IT endeavor. Developers are central to this journey. As builders and innovators, they need tools to learn and keep their skills sharp as they help navigate their organization’s digital transformation.
Cloud leaders, such as Microsoft Azure, understand the importance of empowering developer communities with the knowledge and resources they need to progress through these modernization workstreams. With today’s launch of the Microsoft Azure Collective, there’s now a destination on Stack Overflow for all things Azure.
This dedicated space builds upon an already robust set of Azure developer resources that make it easier to find what they need to build on their terms for on-premises, hybrid, multi-cloud, or edge environments, and with best-in-class tools, popular open-source frameworks and languages, and a platform that supports continuous collaboration and delivery.
Users who join the Microsoft Azure Collective will find more than 190,000+ questions and other relevant content using 350+ tags, such as azure-functions, azure-storage, azure-active-directory, azure-sql-database, and azure-cosmosdb. Developers and technologists can engage with subject matter experts on all Microsoft Azure products, including Compute, Containers, Identity & Security, Databases, Analytics, web, mobile, and more.
“At Microsoft, our mission is to empower every person and organization on the planet to achieve more. Stack Overflow is a trusted platform for developers where they share knowledge and learn from each other. We’re committed to taking their experience to a whole new level by bringing Azure experts and developers together. We look forward to contributing even more to this vibrant community!” says Saloni Singh, General Manager – Azure Modern Support Experience.
“Collectives creates a community around specific areas of technical focus, where technologists of all skill levels can contribute, learn, and grow,” says Stack Overflow Chief Product Officer Teresa Dietrich. “We’re thrilled to have Microsoft engage and support the Stack Overflow community to help them build and innovate with its products and technology.”
The curated, centralized community resources available through the new collective will help users discover the most up-to-date answers, including those recommended or written by Azure subject matter experts, technical articles such as how-to guides, and Bulletins for upcoming events and releases. Members can keep tabs on where they rank on the leaderboard, and they can be promoted to Recognized Member status based on their contributions. The Microsoft Azure Collective will help the community continue to learn, share, and grow by bringing knowledge and users together.
To join the Azure Collective as a member, visit https://stackoverflow.com/collectives/azure
To learn more about Collectives on Stack Overflow, visit https://stackoverflow.com/collectives
Take a tour of Collectives on Stack Overflow, check out https://stackoverflow.co/collectives
The post Microsoft Azure joins Collectives™ on Stack Overflow appeared first on Stack Overflow Blog.
On today’s episode we chat with Prof. Gregory Kapfhammer, Associate Professor in the Department of Computer Science at Allegheny College, and a specialist in the subject of flaky tests. He breaks down his definition of what makes a test flaky, how you can solve for it, and automated solutions that take some of the guesswork and busywork out of avoiding them altogether.
Episode NotesThere is a ton of great research to be found on Prof. Kapfhammer’s website, including:
- Flaky Tests: Finding and fixing unpredictable and harmful test cases
- Database Testing: Automatically testing relational database schemas
- Web Testing: Detecting and repairing poor responsive web page layout
We’ve written a bit about how Stack Overflow is upping its unit testing game and how you can evaluate multiple assertions in a single test.
Thanks to our lifeboat badge winner of the week, Survivor, for answering the question: Is it possible to find out if a value exists twice in an arraylist?
TRANSCRIPT
The post Flake it till you make it: how to detect and deal with flaky tests (Ep. 528) appeared first on Stack Overflow Blog.
Welcome to ISSUE #160 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. Our new year’s resolution is to get you the best tech links, like a conversation on what it feels like going from prison to Python, a question about whether code or chips make better computer chess grandmasters, and a collection of fine 80s-inspired designs.
From the blogThe Winter/Summer Bash 2022 Hat Cafe is now closed! stackoverflow.blog
We had fun celebrating Winter/Summer Bash 2022, sponsored by Splunk, with you all! While we’ve closed our cafe, let’s look at a few highlights and hat-wearing avatars that brought us joy this holiday season.
Getting your data in shape for machine learning stackoverflow.blog
Machine learning uses data structures that don’t always resemble the ones used in standard computing. You’ll need to process your data first if you want efficient machine learning.
The future of software engineering is powered by AIOps and open source stackoverflow.blog
Hear how Intuit is using AI to help its dev teams ship faster.
From life without parole to startup CTO (Ep. 522) stackoverflow.blog
Ever wondered what it’s like learning to code from an XML file of raw Stack Overflow data?
Ask Me Anything Live Virtual Event with MongoDB on January 18th promotion
Want to learn more about MongoDB, but aren’t sure where to begin? Are you familiar with MongoDB Atlas, but still have questions? Join MongoDB for an Ask Me Anything (AMA) Live Virtual Event on Wednesday, January 18 at 11am EST. Register today and ask away.
Interesting questionsHow long would humanity survive if a sudden eternal night occurred? worldbuilding.stackexchange.com
For preppers looking for a bigger challenge.
What’s the difference between “detonate” and “explode”? ell.stackexchange.com
Depends on whether the bomb is the subject or the direct object.
Computers chess programs: Does hardware or software matter more? chess.stackexchange.com
Is it more important to play chess well or quickly?
What’s the difference between a bare metal hypervisor and an operating system? cs.stackexchange.com
Are you looking to support a human or a virtual machine?
Links from around the webHow we improved our documentation medusajs.com
Treating documentation as a product is not always intuitive, but it’s important for creating better software
The 80s are back, baby eyeondesign.aiga.org
Neon, tight typing, and more: designs inspired by 1980s advertising are on the rise!
Seven scientific discoveries from 2022 that may lead to new inventions www.smithsonianmag.com
Science is incredible! Check out some really cool discoveries that might change how we live in the future.
Top Pens of 2022 on CodePen codepen.io
The top 100 Pens of 2022 are out!
A blast from the past: Incremental Static Regeneration: Building static sites a little at a time.
The post The Overflow #160: Looking back at Hat Cafe 2022 appeared first on Stack Overflow Blog.
Juri Strumpflohner of Nrwl joins the home team to talk all things monorepos, how he balances his roles as Director of Developer Experience (Global) and Director of Engineering (Europe), and the perennial question of how to monetize open source.
Episode notes:
Juri is currently Director of Developer Experience (Global) and Director of Engineering (Europe) at Nrwl, founded by former Googlers/Angular core team members Jeff Cross and Victor Savkin.
Nrwl has compiled everything you need to know about monorepos, plus the tools to build them, here.
Connect with Juri on LinkedIn or explore his website.
Shoutout to Lifeboat badge winner penguin2718 for their answer to Storing loop output in a dataframe in R.
TRANSCRIPT
The post Commit to something big: all about monorepos (Ep. 527) appeared first on Stack Overflow Blog.
We have many great traditions on the Stack Exchange network. Among the most loved by us is Stack Gives Back. Stack Gives Back is a yearly initiative where we donate $100 on behalf of moderators to the charity of their choice (from our list of five charities). We are pleased to share that we donated $54,000 USD on behalf of 540 Stack Exchange moderators. Here is how the money was distributed.
$21,303 to Doctors Without Borders (Médecins Sans Frontières)
Doctors Without Borders is an independent, global movement providing medical aid where it’s needed.
$12,139 to Electronic Frontier Foundation
The Electronic Frontier Foundation is the leading nonprofit organization defending civil liberties in the digital world.
$7,679 to Girls Who Code
Girls Who Code aims to support and increase the number of women in computer science by equipping young women with the necessary computing skills to pursue 21st-century opportunities.
$7,182 to International Rescue Committee
The International Rescue Committee responds to the world’s worst humanitarian crises and helps people to survive and rebuild their lives.
$5,697 to UNICEF
The United Nations Children’s Fund provides long-term humanitarian and developmental assistance to children and parents in developing countries
We would like to thank everyone who has helped create or maintain the community knowledge base. It’s our pleasure, at this time of year, to make these financial contributions on behalf of the volunteer moderators, who give freely of their passion, time, and leadership in the communities that make up the Stack Exchange network. This is just one more way in which we can, together, have a positive impact on the world—online and offline.
The post Stack Gives Back 2022! appeared first on Stack Overflow Blog.
SPONSORED BY INTUITAny large organization with multiple products faces the challenge of keeping their brand identity unified without denying each product its own charisma. That’s where a design system can help developers avoid reinventing the wheel every time, say, a new button gets created
On this sponsored episode of the podcast, we talk with Demian Borba, Principal Product Manager, and Kelvin Nguyen, Senior Engineering Manager, both of Intuit. We chat about how their design system is evolving into a platform, how AI keeps their brand consistent, and why a design system doesn’t have to solve every use case.
Episode notesTreating a design system as a platform means providing a baseline of tokens—colors, typography, themes—and allowing developers to deviate so long as they use the right tokens.
Alongside a company-wide push towards greater AI usage, Intuit’s design system team is beginning to leverage AI to help developers make better design decisions. As an example, they’re including typeahead functionality to suggest possible solutions to design decisions.
The team is using a Figma plugin to manage a lot of the heavy lifting. Their presentation at Config 2022 built a lot of excitement for what’s possible.
Congrats to RedVelvet, who won a great question badge for The most efficient way to remove first N elements in a list?
Find Kelvin and Demian on Linkedin.
The post Taming multiple design systems with a single plugin (Ep. 526) appeared first on Stack Overflow Blog.
The team talks to Matt Arbesfeld, cofounder and CEO of LogRocket, about the most challenging problems he’s solved for customers, how machine learning is shaping the next generation of LogRocket solutions, and why side projects that teach you how to experiment and make mistakes are just as (or even more) important than formal CS curricula.
LogRocket helps software teams create better experiences through a combination of session replay, error tracking, and product analytics.
LogRocket’s machine-learning layer, Galileo, cuts through the noise generated by conventional error monitoring and analytics tools to identify critical issues affecting users.
LogRocket is hiring, so check out their open roles or connect with Matt Arbesfeld on LinkedIn. You can also give LogRocket a free trial.
Are you looking for demos and innovative use cases on how to build smarter and more reliable automations with built-in connectors, low-code, integrated AI, and more? Explore the UiPath Dev Dive Series here.
TRANSCRIPT
The post From CS side project to the C-suite appeared first on Stack Overflow Blog.
At my first job out of college (pre-Y2K), I got my first taste of version control systems. We used Microsoft’s Visual SourceSafe (VSS), which had a repository of all the files needed for a release, which was then burned onto a disk and sent to people through the mail. If you wanted to work on one of those files, you had to check it out from the repo—literally, like a library book. That file would be locked until you checked it back in; no one else could edit it. In essence, VSS was a shield on top of a shared file folder.
Microsoft discontinued VSS in 2005, coincidently the same year as the first release of git. While technology has shifted and improved quite a bit since then git has come out as the dominant choice for version control systems. This year, we asked what version control systems people used, and git came out as the clear overall winner.
But it’s not quite a blow out; there are two other systems on the list: SVN (Apache Subversion) and Mercurial. There was a time when both of these were prominent in the market, but not everyone remembers those days. Stack Overflow engineering has used both of these in the past, though we now use git like almost everybody else.
This article will look at what those version control systems are and why they still have a hold of some engineering teams.
Apache SubversionSubversion (SVN) is an open-source version control system that maintains source code in a central server; anyone looking to change code accesses these files from clients. This client server model is an older style, compared to the distributed model git uses, where changes can be stored locally then distributed to the central history (and other branches) when committed to the main repo. In fact, SVN build on historical version control—it was initially intended to be a mostly compatible successor to CVS (Concurrent Versions System), which is itself a front end and expansion to Revision Control System (RCS), initially released way back in 1982.
This earlier generation of version control worked great for the way software was built ten to fifteen plus years ago. A piece of software would be built as a central repository, with any and all feature additions merged into a trunk. Branches were rare and eventually absorbed into the mainline. Important files, particularly large binaries, could be “locked” to prevent other developers from changing them while you worked on them. And everything existed as directories—files, branches, tags, etc. This model worked great for a centrally located team that eventually shipped a release, whether as a disc or a download.
SVN is a free, open-source version of this model. The paid version, Perforce (more on this below), had some traction at enterprise-scale companies, notably Google, but for those unwilling to pay the price for it, SVN was a good option. Plenty of smaller companies (including us at the beginning) used centralized version control to manage their code, and I’m sure plenty of folks still do, whether out of habit or preference.
But the ways that engineering organizations work has changed pretty drastically in the last dozen years. There is no longer a central dev team working on a single codebase; you have multiple independent teams each responsible for one or more services. Stack Overflow user VonC, our newest million reputation man, has made himself a bit of a version control expert and has guided plenty of companies away from SVN. He sees it a technology built for a less agile way of working. “It does get in the way, in term of management, repository creation, registration, and the general development workflow. As opposed to a distributed model, which is much more agile in those aspects. I suspect the recent developments with remote working will not help those closed environment systems.”
The other reason that SVN grew less used was that git showed how things could be better. Quentin Headen, Senior Software Engineer here at Stack Overflow, used SVN early in his career. “In my opinion, the two biggest drawbacks of SVN are that first, it is centralized, which requires a the SVN server to be up for you to commit changes. If your internet is down, you can’t commit at all. Second, the branching is very heavy. Once a branch is created, you can’t delete it (if I remember correctly). I think there is a command to remove, but it stays in history regardless. Git branches are cheap and can be deleted easily if need be.”
Clearly, SVN lost prominence when the new generation of version control arrived. But git wasn’t the only member of that generation.
MercurialGit wasn’t the only member of the distributed version control generation. Mercurial first arrived the same year as Git—2005—and became the two primary players. Early on, many people wondered what differences, if any, the two systems had. When Stack Overflow moved away from SVN, Mercurial won out mostly because we had easy access to hosting through Fog Creek Software (now Glitch), another of our co-founder Joel Spolsky’s companies. Eventually, we too gave in to Git.
Initially, Mercurial seemed to be the natural fit for developers coming from earlier VC systems. VonC notes, “Mercurial was certainly the most easy to use and more familiar to use because it was a bit like using SVN, but in a distributed fashion. But it’s the story of VHS versus Betamax.”
I reached out to Raphaël Gomès and Pierre-Yves David, both Mercurial core developers, about where Mercurial fits into the VC landscape. They said that plenty of large companies still use Mercurial in one form or another, including Mozilla, Facebook (though they may have moved to a Mercurial fork ported to Rust called Eden), Google (though as part of a custom VC codebase called Piper), Nokia, and Jane Street. “One of main advantages of Mercurial these days is its ability to scale on a very large project (millions of commits, millions of files). Over the years, companies have contributed performance improvements and dedicated features that make Mercurial a viable option for extreme scale monorepos.”
Ry4an Brase, who works at Google and uses their VC, expanded on why: “git is wed to the file system. Even GitHub accesses repositories as files on disk. The concurrency requirements of very large user bases on a single repo scale past filesystem access, and both Google and Facebook found Mercurial could be adapted to a database-like datastore and git could not.” However, with the recent release of Git v2.38 and Scalar, that advantage may be lessened.
But another reason that Mercurial may stay at these companies with massive monorepos is that it’s portable and extendable. It’s written in Python, which means it doesn’t need to be compiled to native code, and therefore it can be a viable VC option on any OS with a Python interpreter. It also has a robust extension system. “The extension system allows modifying any and all aspects of Mercurial and is usually greatly appreciated in corporate contexts to customize behavior or to connect to existing systems,” said Gomès and David.
Mercurial still has some big fans. Personally, I had never heard of it until some very enthusiast Mercurialists commented on an article of ours, A look under the hood: how branches work in Git.
babaloomer: Branches in mercurial are so simple and efficient! You never struggle to find the origin of a branch. Each commit has the name of its branch embedded in it, you can’t get lost! I don’t know how many times I had to drill down git history just to find the origin of a branch.
Scott: Mercurial did this much more intuitively than Git. You can tell the system is flawed when the standard practice in many workflows is to use “push -f” to force things. As with any tool, if you have to force it something is wrong.
Of course, different developers have different takes on this. Brase doesn’t think that Mercurial’s branching is necessary better. “Mercurial has four ways to do branches,” he said, “and the one that was exactly like git’s was called ‘bookmarks’, which the core developers were slow to support. What Mercurial called branches have no equivalent in git (every commit is on one and only one branch and it’s part of the commit info and revision hash), but no one wanted that kind.” Well, maybe not no one.
Mercurial is still and active project, as Gomès and David attest. They contribute to the code, manage the release cycles, and hold yearly conferences. While not the leading tool, it still has a place.
Other version control systemsIn talking to people about version control, I found a few other interesting use cases, primarily around paid version control products.
Remember when I said I’d have more on Perforce? It turns out that several people mentioned it even though it didn’t even register on our survey. It turns out that Perforce has a strong presence in the video game industry—some even consider it the standard there. Rob Oates, an industry veteran who is currently the senior director of technology and partnerships at Exploding Kittens said, “Perforce still sees use in the game industry because c video game projects (by variety, count, and total volume of assets) are almost entirely not code.”
He gave four requirements that any version control system would need to fulfill in order to work for video game development:
- Must be useable by laypersons – Artists and designers will be working in this system day-to-day.
- Must lock certain files/types on checkout – Many of our files cannot be conceptually or technically merged.
- Must be architected to handle many large files as the primary use case – Many of our files will be dozens or hundreds of megabytes.
- Must avoid degenerate case with delta compression schemes – Many of our large files change entirely between revisions.
Perforce, because of its centralized server and file locking mechanism, fits perfectly. So why not separate the presentation layer from the simulation logic and store the big binary assets in one place and the code in a distributed system that excels at merging changes? The code in video games often depends on the assets. “For example, it would not be unusual for a game’s combat system to depend on the driving code, the animations, the models, and the tuning data,” said Oates. “Or a pathfinding system may depend on a navigation mesh generated from the level art. Keeping these concerns in one repo is faster and less confusing when a team of programmers, artists, and designers are working to rapidly iterate on the ‘feel’ of the combat system.”
The engineers at these companies often prefer git. When they have projects that don’t have artists and designers, they can git what they want. “Game engines and middleware have an easier time living on distributed version control as their contributors are mostly, if not entirely, engineers,” said Oates. Unfortunately for the devs on video games, most projects have a lot of people creating non-code assets.
Another one mentioned was Team Foundation Version Control (TFVC). This was a Microsoft product originally included in Team Foundation Server and still supported in Azure DevOps. It’s considered the spiritual successor to VSS and is another central server style VC system. Art Gola, a solutions architect with Federated Hermes, told me about it. “It was great for its time. It had an API, was supported on Linux (Team Foundation Everywhere) and tons of people using it that no one ever heard from since they were enterprise devs.”
But Gola’s team is actively trying to move their code out of the TFVC systems they have, and he suspects that a lot of other enterprise shops are too. Compared to the agility git provides, TFVC felt clunky. “It requires you to have a connection to the central server. Later versions allow you to work offline, but you only had the latest version of the code, unlike git. There is no built in pull request type of process. Branching was a pain.”
One could assume that now that the age of centralized version control is waning and distributed version control is ascendant, there is no innovation in the VC space. But you’d be mistaken. “There are a lot of cool experiments in the VCS space,” said Patrick Thomson, a GitHub engineer who compared Git and Mercurial in 2008, “Pijul and the theory of patch algebra, especially—but Git, being the most performant DVCS, is the only one I use in industry. I work on very large codebases.”
Why did Git win?After seeing what the version control landscape looks like in 2022, it may be obvious why distributed version control won out as the VC of choice for software developers. But it may not be immediately obvious why Git has such a commanding share of the market over Mercurial. Both of them first came out around the same time and have similar features, though certainly not one to one. Certainly, many people prefer it. “For personal projects, I pick Mercurial. If I was starting another company, I’d use Git to avoid having to retrain and argue with new hires,” said Brase.
In fact, it should have had an advantage because it was familiar to SVN users and the centralized way of doing things. “Mercurial was certainly the most easy to use and more familiar to use because it was a bit like using subversion, but in a distributed fashion,” said VonC. But that fealty to the old ways may have hurt it as well. “That is also one aspect which was ultimately against Mercury because just having the vision of using an old tool in a distributed fashion was not necessarily the be best fit to develop in a decentralized way.”
The short answer why it won comes down to a strong platform and built-in user base. “Mercurial lost the popularity battle in the early 2010s to Git. It’s something we attribute in large part to the soaring rise of GitHub at that time, and to the natural endorsement of Git by the Linux community,” said Gomès and David.
Mercurial may have started out in a better position, but it may have lost ground over time. “Mercurial’s original fit was a curated, coherent user experience with a built-in web UI,” said Brase. “GitHub gave git the good web UI and coherent couldn’t beat the feature avalanche from Git contributors and the star power of its founder.”
That feature avalanche and focus on user needs may have been a hidden factor in pushing adoption. Thomson, in his comparison nearly fifteen years ago, likened Git to MacGyver and Mercurial to James Bond. Git let you scrape together a bespoke solution to nearly every problem if you were a command-line wizard, while Mercurial—if given the right job—could be fast and efficient. So where does Thomson stand now? “My main objection to Git—the UI—has improved over the years (I now use an Emacs-based Git frontend, which is terrific), whereas Mercurial’s primary drawback, its slow speed on large repositories, is still, as far as I can tell, an extant problem.”
Like MacGyver, Git has been improvising and adapting to fit whatever challenges come its way. Like James Bond, Mercurial has its way of doing things. It works great for some situations, but it has a distinct point of view. “My favorite example of a difference in how git and Mercurial approach new features is the config command,” said Brase. “Both git config and hg config are commands to edit settings such as the user’s email address. The git config command modifies ~/.gitrc for you and usually gets it right. The Mercurial author refused all contributions that edited a config file for you. Instead hg config launched your text editor on ~/.hgrc, saying ‘What is it with coders who are intimidated by text-based config files? Like doctors that can’t stand blood.’”
Regardless, it seems that while Git feels like the only version control game in town, it isn’t. Options for how to solve your problems are always a plus, so if you’ve been frustrated with the way it seems that everyone does things, know that there are other ways of working, and commit to learning more.
The post Beyond Git: The other version control systems developers use appeared first on Stack Overflow Blog.
Welcome to ISSUE #159 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. Happy new year everybody! Here’s the five most popular articles from last year as well as fresh questions and links about hot new technologies like COBOL and Assembly language!
From the blogYou should be reading academic computer science papers stackoverflow.blog
You read documentation and tutorials to become a better programmer, but if you really want to be cutting-edge, academic research is where it’s at.
Remote work is killing big offices. Cities must change to survive stackoverflow.blog
If your office is where you live now, would you live in your old office?
The Great Resignation is here. What does that mean for developers? stackoverflow.blog
Nearly three years into the pandemic, many Americans are still reevaluating their relationship with work.
Picture perfect images with the modern element stackoverflow.blog
You may not think about images as part of your web dev work, but they can affect your web app’s performance more than any other part of your code.
Why the number input is the worst input stackoverflow.blog
Think that web form has got your number? If you used input type=“number”, you may be surprised to find that it doesn’t.
Accelerate business success with Developer Experience Engineers promotion
Ensure developers have the right tools, processes, and environment to maximize productivity and create the greatest business value possible.
Interesting questionsWhat is the purpose of hiding spam links in some obscure forum posts? security.stackexchange.com
Consider them offerings to the mighty search engine gods.
Would a machine learning classifier algorithm be able to determine whether a number is odd vs even? stats.stackexchange.com
If by “machine learning” you mean “divide by two” then sure.
References for the complexity of the COBOL language retrocomputing.stackexchange.com
You want proof, eh? Don’t all the articles complaining about it count?
Feeling burnt out and like I need to leave but feeling guilty as there’s no one to replace me workplace.stackexchange.com
To thine own self be true. Especially when a company is overworking you.
Links from around the webThe joys of home-cooked apps blakewatson.com
Building something for yourself is the often most satisfying thing to do, because you are your own customer!
Taking the stress out of design system management www.smashingmagazine.com
Design systems can get unruly, but there’s ways to tame that.
A book teaching assembly language programming on the ARM 64 bit ISA. github.com
If you want to try your hand at assembly language programming, perhaps now’s the best time!
Finding language in the brain thereader.mitpress.mit.edu
The combination of neuroscience and linguistics is a powerful, and somewhat new field. Language isn’t only math…but it’s pretty close.
A blast from the past: Testing software so it’s reliable enough for space.
The post The Overflow #159: Our top blog posts (part 2) appeared first on Stack Overflow Blog.
The home team reflects on the last year, talks through tech news, and recommends some good reads for 2023.
Episode notes:
Adobe closed out 2022 and celebrated 40 years with an employee-only Katy Perry concert. Related: Ceora makes the case for virtual concerts.
DeepMind is teaching AI to play soccer, which naturally makes us think of QWOP.
ICYMI: Ghost calls out Substack and Substack responds.
BeReal is the iPhone app of the year. But not even Resident Youth Ceora knows anyone who actually uses it.
Some 2023 recommendations from the team:
Ceora recommends Realworld (not to be confused with BeReal), an app that guides you through tasks and decisions big and small, from deciding on health insurance to improving your credit.
Cassidy recommends Bird by Bird: Some Instructions on Writing and Life, by Anne Lamott.
Matt suggests fellow side hustlers check out The Freelance Manifesto: A Field Guide for the Modern Motion Designer by School of Motion founder Joey Korenman.
Ben recommends Tomorrow, Tomorrow, and Tomorrow, a terrific novel about a love triangle between indie video game creators, especially fun if you grew up with Oregon Trail, Myst, and Super Mario.
TRANSCRIPT
The post Our favorite apps, books, and games of 2023 (Ep. 524) appeared first on Stack Overflow Blog.
As they say, all good things must come to an end. Winter/Summer Bash 2022 has concluded, but we hope everyone had an excellent time.
Before we share some fun highlights from the event, we want to give a big thank you to this year’s Winter Bash 2022 sponsor, Splunk. Splunk delivers full-stack visibility across infrastructure, applications, and business services across any environment in real time. Thanks, Splunk, for the support!
Each year, the staff looks forward to gathering stats, discovering highlights, and seeing the fun things our site members do with their hats. This year was no exception, so let’s hop on it.
The team pulled out all the stops this year and created 47 hats – to see a full list of hats and how to earn them, check out this community-created list. We felt extra sneaky, so 26 were secret hats, while 21 were non-secret hats. 2cool4skool and I Voted were the most widely earned hats across the board, with 2cool4skool being distributed 797,834 times and I Voted distributed 200,845 times. We gave out a total of 1,477,208 non-secret hats and 424,735 secret hats across 1,063,300 profiles. Wow, that’s a lot of hats!
The least awarded hats this year were Cubed Away (4 users), Squared Away (12 users), and Running Up That Hill (12 users).
Each year, the effort to top our leaderboard is intense, and this year was no different in that regard. Kudos goes to U13-Forward and CDJB for collecting all 47 hats! Congratulations are also well deserved for Vickel (with 46 hats), James Risner, (with 45 hats), and double-beep (with 45 hats).
We’ve celebrated Winter/Summer Bash for a while now, but it never ceases to amaze us how some members get into the top 5 of the leaderboard for consecutive years. Extra congratulations go to U13-Forward, Vickel, and double-beep, for being in the top five three years in a row!
At the close of the event, 70,448 users were wearing hats and 336 of these users were wearing different hats on different sites. If you’d like to check out more exciting tidbits about Winter/Summer Bash 2022, all of our public stats for the event can be found on this page.
Also, a special shout out to the community members who participated in the chat room to puzzle out all of the secret hats (and the Sparkles the Unicorn puzzle). There were over 6,000 messages over the course of Winter Bash!
Before we sign off, it’s become a tradition to share some of our favorite avatar and hat combinations shared in the yearly Show off your hats! post on Meta Stack Exchange.
From RDK, we have Albert Einstein quite literally being Albert Einstein:
From adiga, we have a low power situation and the mood we all feel in this situation:
Last but not least, we have hkotsubo giving us the perfect reason to climb a mountain:
We had a lot of fun creating Winter/Summer Bash 2022, and we hope you enjoyed participating. Thanks to everyone for making this a spectacular event once more, and we hope you have a wonderful 2023!
The post The Winter/Summer Bash 2022 Hat Cafe is now closed! appeared first on Stack Overflow Blog.
SPONSORED BY INTUITOver the past five years, Intuit went through a total cloud transformation—they closed the data centers, built out a modern SaaS development environment, and went cloud native with foundational building blocks like containers and Kubernetes. Now they are looking to continue transforming into an AI-driven organization that leverages the data they have to make their customers’ lives easier. Along the way, they realized that their internal systems have the same requirements to leverage the data they have for AI-driven insights.
On this sponsored episode of the podcast—the first in a series of four—we talk with Pratik Wadher, senior VP of Product Development at Intuit, about how it is building a AI-enabled development platform that increases the development velocity for their 7,000 plus developers.
Episode notesIn terms of sheer volume, the AI/ML program at Intuit is massive. They make 58 billion ML predictions daily, enable 730 million AI-driven customer interactions every year, and maintain over two million personalized AI models.
Wadher notes that Intuit uses development velocity, not developer velocity. The thinking is that an engineering org should focus on shipping products and features faster, not making individual devs more productive.
No, the robots aren’t coming for your jobs. Wadher says their AI strategy relies on helping experts make better insights. The goal is to arm those experts, not replace them.
Intuit’s not here to hoard secrets. They’ve open sourced their DevOps pipeline tool, Argo, which a lot of companies used for AI and data pipelines. Intuit has recently launched Numaproj, which open sources a number of internal tools and capabilities.
Congrats to Lifeboat badge winner Bill Karwin for their answer to Understanding MySQL licensing.
The post The future of software engineering is powered by AIOps and open source appeared first on Stack Overflow Blog.
Handling data is an essential part of a programmer’s daily routine. Typically, data is organized into arrays and objects, stored externally in SQL or document-based databases, or encoded in text or binary files. Machine learning is all about data and works best when a large amount of data is used. Therefore, data and data processing play a central role in designing and building a machine learning pipeline. However, data formats are often very different from classes and objects, and terms such as vectors, matrices, and tensors are used. In this article, we explain why machine learning requires an efficient data pipeline and data formats. We explain the basic data structures from scalars to n-dimensional tensors and give examples of processing different data types.
Practical code examples are given in an accompanying workbook. In the following notebook you find actual snippets on data processing in Python.
Why data structures are different in MLWhen we talk about data for machine learning, we refer to the training data used to build and test models. The design goals for machine learning data structures are different from those of classical programming. Often, the raw data consists of tabular data, images or videos, text or audio stored on a local disk or in a cloud bucket. Machine learning frameworks cannot directly consume this data as it is often encoded (for example, as a JPG or MP4), contains additional information and cannot be processed efficiently. Performance matters a lot in machine learning, and training data is inferred hundreds and thousands of times by a model during training. Machine learning applications are trained and used by (multiple) GPUs synchronizing data via high performance internal networks and pipes. All this requires an optimized data format that can handle different types of data.
Design goals for ML data structures
- Suitable for high-performance processing and computations
- Efficient synchronization between different GPUs and machines
- Flexible for different types of data
Fortunately, most of the complex tasks are handled by machine learning frameworks such as Tensorflow or PyTorch. Nevertheless, it is important to understand the following fundamentals in order to design efficient data pipelines.
Scalars, vectors, and matricesIn our flexible data format, we start as simple as possible, with a single element: a scalar. Scalars refer to single data points; for example, the amount of blue in an RGB pixel or a token representation for a letter or word. In programming languages such as Java or Python, scalars are single integers, doubles, or booleans.
When building a list from scalars and the list has a fixed order (directed), it is called a vector. Vectors are very common in classic programming and are often used as tuples, arrays, or lists. With a vector, we can already represent a complete RGB pixel (values for red, green, and blue) or a sentence (each word or part of a word is represented by an integer token).
In the next step, we add a second dimension by stacking multiple vectors to a matrix. Matrices are two-dimensional and comparable to a table, consisting of rows and columns. By this, we can efficiently store grayscale images, multiple documents of a text, or an audio file with multiple channels.
Processing matrices on GPUs is extremely efficient and the mathematics behind calculating matrices is well-researched (although reinforcement models have only recently found even more efficient multiplication algorithms). Matrices are the foundation for any data structure in modern machine learning.
https://hadrienj.github.io/posts/Deep-Learning-Book-Series-2.1-Scalars-Vectors-Matrices-and-Tensors/Tensors and their propertiesA tensor describes an n-dimensional array of data. Often, the so-called rank or the number of axes refer to the dimensions. A rank-0 tensor is a scalar, a rank-1 tensor is a vector, and matrices refer to a rank-2 tensor.
N-dimensional tensors are ideal for machine learning applications as they provide fast access to data by a quick lookup and without decoding or further processing. Due to the well-known matrix mathematics, computing with tensors is very efficient and allows the training of deep learning models that require the computation of millions and billions of parameters. Many tensor operations such as addition, subtraction, the Hadamard transform, dot product, and many more are efficiently implemented in standard machine learning libraries.
Storing data in the tensor format comes with a notable time/memory tradeoff, which is not uncommon in computer science. Storing encoded and compressed data reduces the required disk space to a minimum. To access the data, it must be decoded and decompressed, which requires computational effort. For single files, this is mostly irrelevant and the advantages of fast transfer and low storage requirements outweigh the access time. However, when training deep learning models, the data is accessed frequently, and algorithms fundamental for machine learning models (such as convolution for image analysis) cannot operate on encoded data.
A well-encoded 320 x 213 pixel JPG image requires only around 13 KB of storage, whereas a float32 tensor of the same image data utilizes about 798 KB of memory, an increase of 6100%.
320 x 213 color pixels in JPG only require 13 KB of storage
same image data stored in a 320 x 213 x 3 float32 tensor weights 798 KB
To combine the advantages of both, special data loader modules have been designed to preprocess the data for optimized usage in the tensor format.
Additional optimizations such as batching and sparse data formats exist to handle the large amounts of data. Nevertheless, hardware requirements for (training) deep learning models remain high.
Decisions for your data pipelineTaking into account the above insights on specialized data structures, let’s have a look at the decisions one has to make when designing a data pipeline.
First of all, even before starting to develop any machine learning models, make sure to store any relevant data structured and accessible. For image data, this usually means some cloud storage with additional metadata attached to the files or stored in a separate database. For our data loader it is important to have a structured list of the relevant files and their attached labels. This metadata will be used to download and preprocess the files. Keep in mind that at some point there can be multiple machines working on the same datasets in parallel, so they all need parallel access. For the training procedure, we want to cache the data on the training machine directly to avoid high transaction times and costs, as we frequently access the data. Even if you don’t plan to train a machine learning model (yet), it might be worth it to think about storing relevant data and potentially labels that could be useful for supervised learning later.
In the next step, we convert the data into a useful tensor format. The tensor rank depends on the used data type (see examples in the workbook) and, more surprisingly, on the problem definition. It’s important to define if the model should interpret data (for example a sentence) independent from others or what parts of the data are related to each other. A batch usually consists of a number of independent samples. The batch size is flexible and can be reduced down to a single sample at inference/testing time. The type of the tensor also depends on the data type and normalization methods (pixels can be represented as integers from 0 to 255 or as a floating number from 0 to 1).
For smaller problems, it might be possible to load the full dataset into memory (tensor format) and perform the training on this data source with the advantage of faster data loading during training and a low CPU load. However, for most practical problems this is rarely possible, as even standard datasets easily surpass hundreds of gigabytes. For those cases, asynchronous data loaders can work as a thread on the CPU and prepare the data in memory. This is a continuous process so it works even if the total amount of memory is smaller than the full dataset.
Dataset decisions:
- structured format
- accessible storage
- labels and metadata
- tensor format (rank, batch size, type, normalization)
- loading data from disk to memory, parallelization
Scalars, vectors, matrices, and especially tensors are the basic building blocks of any machine learning dataset. Training a model starts with building a relevant dataset and data processing pipeline. This article provided an overview of optimized data structures and explained some of the relevant aspects of the tensor format. Hopefully the discussed decisions for designing data pipelines can serve as a starting point for more detailed insights into the topic of data processing in machine learning.
Visit the additional notebook for practical examples of how to process different types of data.
The post Getting your data in shape for machine learning appeared first on Stack Overflow Blog.
SPONSORED BY INTUITEvery engineering team talks about open source, AI, and development velocity in some form or another. But Intuit is talking about how all three of them combine to make for a better developer experience. This podcast series explores how the company is using AI and open source to let their engineers build better software faster.
Episode #1: The future of software engineering is powered by AIOps and open sourceOver the past five years, Intuit went through a total cloud transformation—they closed the data centers, built out a modern SaaS development environment, and went cloud native with foundational building blocks like containers and Kubernetes. Now they are looking to continue transforming into an AI-driven organization that leverages the data they have to make their customers’ lives easier. Along the way, they realized that their internal systems have the same requirements to leverage the data they have for AI-driven insights.
On this sponsored episode of the podcast—the first in a series of four—we talk with Pratik Wadher, senior VP of Product Development at Intuit, about how it is building a AI-enabled development platform that increases the development velocity for their 7,000 plus developers.
The post Better developer experience through AI and open source appeared first on Stack Overflow Blog.
Welcome to a new year. For our first episode back, we’re featuring a chat with Jessica Hicklin, the CTO of Unlocked Labs. She describes what it was like to enter prison with a life sentence at the age of 16, how she taught herself to code in while incarcerated, and how she turned that into a new role as a software engineer and entrepreneur after being unexpectedly released at the age of 42.
Show Less
Episode NotesIf you want to read more about Jessica, you can check out the blog we worked on together for the launch of our Overflow Offline initiative. If you’ve ever wondered what it’s like learning to code from an XML file of raw Stack Overflow data, be sure to check this episode out.
You can learn more about the Supreme Court case that led to Jessica’s release here.
Her company’s mission is to build a better justice system from the inside, specifically by educating incarcerated individuals so they can teach the next generation and have valuable skills upon release. Read more about Unlocked Labs here.
Our lifeboat badge of the week goes to mx0 for answering the question: How do you extract the ‘src’ attribute from an ‘img’ tag using Beautiful Soup?
Follow Ben on Twitter and if you enjoy the show, be sure to leave us a rating and review.
TRANSCRIPT
The post From life without parole to startup CTO (Ep. 522) appeared first on Stack Overflow Blog.
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. This is our number one post of 2022! Thanks for reading and we’ll see you in the new year. ]
As working programmers, you need to keep learning all the time. You check out tutorials, documentation, Stack Overflow questions, anything you can find that will help you write code and keep your skills current. But how often do you find yourself digging into academic computer science papers to improve your programming chops?
While the tutorials can help you write code right now, it’s the academic papers that can help you understand where programming came from and where it’s going. Every programming feature, from the null pointer (aka the billion dollar mistake) to objects (via Smalltalk) has been built on a foundation of research that stretches back to the 1960s (and earlier). Future innovations will be built on the research of today.
We spoke to three of the members of the Papers We Love team, an online repository of their favorite computer science scholarship.
Zeeshan Lakhani, an engineering director at BlockFi, Darren Newton, an engineering team lead at Datadog, and David Ashby, a staff engineer at SageSure, all met while working at a company called Arc90. They found that none of them had formal training in computer science, but they all wanted to learn more. All three came from humanities and arts disciplines: Ashby has an English degree with a history minor, Newton went to art school twice, and Lakhani went to film school for undergrad before getting a master’s degree in music and audio engineering. All of those fields of study rely heavily on reading texts that built the foundation of the discipline as to understand the theory that underlies all practice.
Like any good student of the humanities, they went looking for answers in the archives. “I had a latent librarian inside,” said Newton. “So I’m always interested in the historical source material for the things that I do.”
Surveying historyAs part of learning more about the history of programming, Ashby was reading Tracy Kidder’s Soul of a New Machine, about the race to design a 32-bit microcomputer in the late 70s. It covered both the engineering culture at the time and the problems and concepts those engineers wrestled with. This was before the time of mass-market CPUs and standard motherboard components, so a lot of what we take for granted today was still being worked out.
In Kidder’s book, Lakhani, Newton, and Ashby saw a whole history of computer science that they had no connection with, so they decided to try reading a foundational paper: Tony Hoare’s “Communicating Sequential Processes” from 1978. They were working on Clojure and Clojurescript at the time, so this seemed relevant. When they sat down to discuss the paper, they realized they didn’t even know how to approach understanding it. “It was like, I can’t understand half of this formalism, but maybe the intro is pretty good,” said Lakhani. “But we need someone like David Nolen to explain this to us.”
Nolen was an acquaintance who worked for The New York Times. He gave a talk there about Clojure and other Lisp-like languages, referencing a lot of John McCarthy’s early papers. Hearing this explanation with the academic context started turning a few gears in their minds. That’s when the idea of Papers We Love was born.
Knowing the history of the computing concepts that you use every day unlocks a lot of understanding into how they work at a practical level. The tools that you use, from databases to programming languages, are built on a foundation of academic research. “Understanding the roots of the things you’re working on unlocks a lot of knowledge that you’re not going to get purely just by using every day because you don’t understand the paths that they didn’t go down,” said Ashby.
There’s a talk they love that Bret Victor gave in 2013 called “The Future of Programming.” He’s dressed like an engineer from the 70s, white button-up, khakis, pocket protector. He starts giving his talk using an overhead projector that has the name of the talk. He adjusts the slide and it reveals that the date is 1973. He goes on to talk about all the great things coming out of research, all the things that are going to shake up computer science. And they’re all things that the audience is still dealing with, like the move from sequential execution to concurrent models.
“The top theme was that it takes a long time,” said Lakhani. “There’s a lot of things that are old that are new again, over and over and over.” The same problems are still relevant, whether because the problems are harder than once thought or because the research into those problems has been widely shared.
The trio behind Papers We Love aren’t alone in discovering a love for computing’s history. There is an increased interest in retrocomputing, engineers looking at the systems of the past to learn more about the practice of technology. It’s the flipside of looking at older papers; you look at the old hardware and software programmers used and work on it with a present-day mindset. “A lot of people are spinning up these ancient operating systems on Raspberry PIs and working with them,” said Newton. “Like spinning up an old Smalltalk VM on a Raspberry PI or recreating a PDP-10.”
When you see these issues in their initial contexts, like reading the research papers that tried to address them, you can get a better perspective on where you are now. That can lead to all sorts of epiphanies. “Oh, objects do the things they do because of Smalltalk back in the 80s,” said Ashby. “And that’s why big systems look like that. And that’s why Java looks like that.”
That new understanding can help you solve the problems that you face now.
The future of programming (today)There’s more to reading research papers than understanding history; you can find new ways to solve problems by reading current research. “The idea of Stack Overflow is: someone else has had your problem before,” said Ashby. “Academic papers are: someone else has thought about this problem before.”
If your work involves building variations of the same old CRUD app in new spaces, then maybe research papers won’t help you. But if you are trying to solve the unique problems of your industry, then some of the research in those problem spaces may help you overcome them. “I find papers to expand the idea of what’s possible with the work you do,” said Ashby. “They can help you appreciate that there are other ways to solve these problems.”
For Newton and his colleagues at Datadog, academic papers are an integral part of their work. Their monitoring software has to process a lot of information in real time to give engineers a view of their applications and the stack they run on. “We are very concerned with performance algorithms and better ways to do statistics on large volumes of data,” said Newton. “We need to rely on academic research for some of that.”
Just because research exists, of course, it doesn’t mean your problems are automatically solved. Sometimes a single paper only gets you part of the solution. “I was at Comcast where we wanted to leverage load balancing work that we do in terms of routing,” said Lakhani. “We ended up applying three different kinds of papers that didn’t know each other. We put semantics into network packets, routed them based on another paper via a specific protocol, and implemented a bunch of IETF specs. Part of this work now lives in a Rust library people can run today.” It’s finding threads in academic work and braiding them together to solve the problems at hand.
Without reading those papers, Lakhani’s team wouldn’t have been able to design such an effective solution. Perhaps they would have gotten there on their own. But imagine the amount of work to research those three concepts; there’s no need to redo their work if it’s already been done. It’s standing on the shoulders of giants, as the saying goes, and if you’re on top of the research in your field, you know exactly which giants to stand on.
A map of the giants’ shouldersNaturally, being a graduate of the humanities myself, I wanted to know which were the giants of computer science, those papers that would be on the syllabus if you were to construct a humanities-style curricula for a class. Think of it as a map of which giant shoulders you could stand on to get ahead.
It turns out, I’m not the first to wonder what’s in the computer science canon. In 1996, Phillip Laplante wrote Great Papers in Computer Science, which might be a bit outdated at this point. For a more recent take on the same thing, the trio recommend Ideas That Created the Future, published last year. Lakhani, who is now doing a PhD in computer science at Carnegie Mellon University (my alma mater), points out that there was a course when he arrived that covered the important papers of the field.
In a way, this canon is exactly what the Papers We Love repo aims to create. It contains papers and links to papers organized by topic. The group welcomes new pull requests with academic papers that you all love and want to see spotlighted.
Here are a few papers (and talks) that they recommended to anyone wanting to get started reading the research:
- Dynamo: Amazon’s Highly Available Key-value Store
- A Unified Theory of Garbage Collection
- Communicating Sequential Processes
- Out of the Tar Pit
Of course, there are many more.
If you’re intimidated by starting on a paper, then check out some of Papers We Love’s presentations, which offer a primer on how to understand a paper. The whole idea of these talks is borne out of that first frustration with a paper, then finding a path through it with someone else’s help. “They’ve gotten the CliffsNotes,” says Lakhani. “Now they can attack the paper and really understand it.”
The Papers We Love community continues to try to build a bridge between industry and academia. Everyone benefits—the industry gets access to new solutions without having to wait for someone else to implement and open-source them, and academics get to see their ideas tested and implemented in real situations.
“One of the goals of Papers We Love is to make it where you find out about stuff a little bit faster,” said Lakhani. “Maybe that changes things.”
The post You should be reading academic computer science papers appeared first on Stack Overflow Blog.
Welcome to ISSUE #158 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. The end of the year approaches and like everyone else, we’re doing best of lists. Please enjoy the bottom half of our top ten blog articles, as well as a regular bounty of questions and links.
From the blogUse Git tactically stackoverflow.blog
How you can use micro-commits to effectively apply the Strangler Fig pattern.
Best practices to increase the speed for Next.js apps stackoverflow.blog
Next.js is a powerful yet simple framework, though developers still struggle to increase the speed of their applications. Here’s how you can make those apps faster.
I spent two years trying to do what Backstage does for free stackoverflow.blog
Absent a time machine, telling others how to avoid my mistakes is the best I can do.
The complete guide to protecting your APIs with OAuth2 (part 1) stackoverflow.blog
OAuth2 is one of the most popular specifications for API authentication today, though wrapping your head around it can be a challenge.
The three top-paying tech roles in 2022 and the skills you need to land them stackoverflow.blog
Looking for the skills that pay the bills? Skillsoft ran a survey to find out the highest-paying roles and the skills they require.
Let’s talk about our favorite terminal tools (Ep. 521) stackoverflow.blog
A terminal shouldn’t have to feel…terminal.
Accelerate business success with Developer Experience Engineers promotion
Ensure developers have the right tools, processes, and environment to maximize productivity and create the greatest business value possible.
Interesting questionsWhy are there two ways of expressing NULL in C? stackoverflow.com
When you stare into the NULL ((void )0), the f(void) stares back into you.
Is one free from legal responsibility if the intellectual property has passed the plagiarism check software? law.stackexchange.com
Copyright infringement doesn’t go away under the dubious legal doctrine of “I tried.”
False claim of a publication in the CV of an applicant? academia.stackexchange.com
Let the folks moving the money handle it.
Is it worth to defragment XFS on SSD (many files)? superuser.com
That’s more of a HDD thing.
Links from around the webNo more airplane mode? EU to allow calls on flights www.bbc.com
It wasn’t that long ago that people weren’t allowed to use phones on airplanes at all…but now airplane mode might not be needed anymore either!
Welcome | Learn prompting learnprompting.org
A lot of artificial intelligence tools require “prompt engineering” to generate what you want. Here’s a great free guide on how to do prompt engineering well.
Jamstack trends: How will we develop in 2023? www.netlify.com
There’s some interesting predictions here about what web development will look like in 2023.
How I still use Flash in 2022 foon.uk
Flash may be dead for most of us… but there’s others who are still holding on!
A blast from the past: Level Up: Mastering statistics with Python.
The post The Overflow #158: Our top blog posts (part 1) appeared first on Stack Overflow Blog.
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we’ll see you in 2023.]
II was born in Manhattan and lived much of my life in the Big Apple. I went to school on the Bowery and worked in office complexes that sat adjacent to storied destinations like Wall Street, Times Square, and Madison Square Park. I met sources for lunch and attended concerts and conferences that moved my career forward. But like many knowledge workers, in the wake of the pandemic, I’ve moved away from the concrete jungle and relocated to a small, rural town a few hours north of NYC.
I’m not alone. Recent data indicates that only 8% of office employees who worked in NYC pre-pandemic are back to the office five days a week. This creates a financial crisis for major urban areas. Fully 25% of NYC’s tax base each year has historically been derived from commercial real estate, anchored by offices in Wall Street and Midtown and the plethora of restaurants and stores and sidewalk vendors that cater to the millions of people who used to flow every day to and from the city’s commercial corridors. Big cities, in other words, aren’t what they used to be. But that leaves open a door to what cities might become.
New York City’s mayor, Eric Adams, addressed the need for change in a recent speech. “It’s imperative that our economic leaders sit down and say what our business centers and districts are going to look like,” Adams said. “Do we change the zoning? Do we allow these new workforce housing that’s coming together outside, because there’s new ways people are doing business?”
There is something revolutionary in there. Working every day in the world of software developers and knowledge management, I think we’re at a tipping point that will change not just where we work—home or office—and how we work—remote, async—but the nature of our cities, our towns, and with them, our civilization. From London to São Paulo, from Boston to Berlin, there is an opportunity for the metropolis to emerge as something different, something equally essential, but perhaps more equitable, affordable, and humane. To get this transformation right, we can learn from the world of open-source software.
IIWhat drove us to work in offices in the first place? For most of its history, the physical workplace served essential, utilitarian functions. DJ Huppatz and Agustin Chevez explain that “the office” began as a place where peace and solitude would allow for concentration and where important and rare works on paper could be safely stored:
“The origins of the modern office lie with large-scale organizations such as governments, trading companies and religious orders that required written records or documentation. Medieval monks, for example, worked in quiet spaces designed specifically for sedentary activities such as copying and studying manuscripts. As depicted in Botticelli’s St Augustine in His Cell, these early ‘workstations’ comprised a desk, chair and storage shelves.”
Sandro Botticelli St Augustin dans son cabinet de travail or St Augustine at Work. Wikipedia CommonsTechnology played a pivotal role in the development of the office. Computers once required entire floors—hell, entire buildings—to house their processing power. They shrunk over time, but offices still provided a venue for workers to access hardware that was unaffordable or impractical for use at home. Huppatz and Chevez point to 1964, when IBM introduced a magnetic-card recording device into a Selectric typewriter, as a tipping point. From there, the functionality and convenience of a small army of devices—copy machines, fax machines, server racks—gave employees good reasons to work from an office.
Even when code could be written at home on a PC, working from home as a programmer wasn’t necessarily practical. When I spoke with Paul Ford and Sara Chipps about their early careers in the 1990s, they recalled sitting in an office where versions of a software project were passed around on a physical disk. Essential backups of key files and data? Sometimes it was a few hard drives in a briefcase that you carried home at night.
As a journalist, I worked for many years in fancy offices that served an essential function: a hub for physical work—collaborating on a newspaper or magazine printed on ACTUAL paper—and a place to access a company-owned PC where my work lived on local storage that wasn’t backed up to any cloud.
By 2015, however, I was acutely aware of the many hours a day I spent commuting and how unnecessary the commute was to completing my work—how, in fact, it often made completing my work harder. By that time, my work happened almost entirely in chat, emails, and online documents. Most desks still had a landline, but they sat unused, a relic of a different era of newsroom.
I felt at the time that seeing people in person, especially my bosses, was key to advancing my career. I was told explicitly by my manager that I was expected at the office at least three days a week. Yet there were many days when I would arrive at the office and hear no chatter around the coffee machine, see no inspiring collaboration happening around a drawing board. Each worker, even in an open office plan without cubicles, was living completely in their own world: headphones on, multiple tabs open to Google Docs, Slack, Email, Spotify, Twitter, YouTube, and a dozen others. We sat or stood, our attention fixed on the screen, office banter happening in private messages and across Twitter canoes, not in the break room.
For software developers, the advances of the last decade, especially the advent of cloud computing and version control, meant that asynchronous contribution to a code base was just as practical from home as the office. Pre-pandemic, however, the majority of large tech companies invested heavily in real estate and dictated that employees spend at least several days a week in the office. The transformative shock of our recent quarantines and the rapidly growing success of companies founded around open-source projects, however, is finally catalyzing a change away from this archaic approach.
III The pandemic exposed an unspoken truth. People were not less productive working from home; in fact, many got more work done. What gives? Well, subtract an hour of commute each way. Subtract another hour spent walking to grab coffee, snacks, and lunch. Remove an hour here or there for all the collaboration that happened around the ping pong table or Xbox. Take out the stand-ups, check-ins, and meetings spent on chit-chat and vague ideas which, ya know, could have been an email.
Why did so many companies, including supposedly forward-thinking tech companies, insist on a heavy investment in office and real estate even as most office work moved to portable devices tied to the cloud? And why are so many of the most valuable tech companies in the world still battling to get workers back into the office now?
As Huppatz and Chevez write, the office acts as a “visible statement of prestige and power.” Companies that have invested heavily in fancy office parks want them bustling with employee activity when clients, partners, or journalists come to visit. Another imperative for management, usually left unsaid, is that the office allows them to implement monitoring, surveillance, and control. The pair write:
Various management theories also had a profound impact on the office. As Gideon Haigh put it in The Office: A Hardworking History, the office was “an activity long before it was a place”.
Work was shaped by social and cultural expectations even before the modern office existed. Monasteries, for example, introduced timekeeping that imposed strict discipline on monks’ daily routines.
Later, modern theorists understood the office as a factory-like environment. Inspired by Frank Gilbreth’s time-motion studies of bricklayers and Fredrick Taylor’s Principles of Scientific Management, William Henry Leffingwell’s 1917 book, Scientific Office Management, depicted work as a series of tasks that could be rationalized, standardized and scientifically calculated into an efficient production regime. Even his concessions to the office environment, such as flowers, were intended to increase productivity.
For obvious reasons, physical products in development and proprietary technology need to be safeguarded. Work on these projects might require an office or workspace separate from the home. But the vast majority of code can now be written safely and securely from home. The tension between employees and organizations boils down to management’s fear that over time remote workers will be less productive and predictable. Given what we’ve seen during the pandemic, however, the onus is on leaders to show that working from home is less productive before insisting that working from an office is somehow superior.
Think about the value created by products like Linux and Python, Bitcoin and Ethereum, GoLang and React. Sure, people sat in rooms over the years and worked together to drive these projects forward. But it wasn’t the frisson of IRL interactions that turned them into the global juggernauts they are today. Quite the opposite: it was the ease with which anyone around the world could contribute to the project without needing any special permission.
Tech companies have become the most valuable organizations on earth, and the folks who write code at these companies command, on average, the highest salaries of any profession. I won’t try and predict what the future will hold, but I think it’s safe to say that coders are capable of building incredibly impactful and profitable tools, platforms, and business models without leaving the comfort of their pajamas. Increasingly, workers in finance, entertainment, education, and other industries are finding ways to do the same.
We have an opportunity for a radical rethinking of the office—and the city beyond.
IVBefore we go on, I want to offer an aside to make one thing clear. I’m not denigrating work that doesn’t involve code or that can’t be done remotely. The pandemic reminded us of another important truth—that our society can’t function without farmers and doctors, truckers and teachers. While a lot of ink has been spilled on the future of work, the majority of Americans, and most people around the world, can’t actually do their jobs remotely. This being Stack Overflow, however, where we serve a community of developers and technologists, it makes sense to focus on the option of remote work and what the expansion of that kind of work might mean for our society. I’ll also acknowledge that I’m an American and the perspective here is centered on the US. To the degree that it’s similar or different from the experience in other locales, I would love to hear from readers with more knowledge and experience than me.
So, back to the issue at hand. The question we should be exploring is not how we can force people back into offices to save the old model of a city, but what cities can become now that so many workers who once had to congregate there to make an impact have the option to work remotely.What would a reimagined urban center look like for these professions?
We know, from decades of research, that urbanization tends to exacerbate income inequality. In countries like the United States, a decades-long trend also saw manufacturing move away from smaller cities towards international hubs, leaving hundreds of mid-sized cities and their surrounding suburbs struggling with urban blight and rising poverty, which grew fastest in suburban areas during the period following the Financial Crisis of 2008.
For areas outside the biggest metropolitan areas, hybrid work has been a huge boon. Take Troy, NY, a city of 50,000 close to my new home in the Hudson Valley. As The Globe and Mail reported:
For years, these small legacy cities – gutted by a loss in manufacturing, pockmarked by abandoned industrial spaces, and hampered by a dwindling population – have struggled to make a sustained economic recovery. Yet the tides may finally be shifting. The rapid expansion of hybrid and remote workplaces during the pandemic, along with a climate crisis that has underscored the vulnerability of our bigger cities and laid bare the necessity for community resilience, has suddenly made places like Troy ripe for adaptation in the 21st century.
The well-established concept of “rewilding” urges societies to return lands back to their natural state, rebalancing environments where plants and animals were shunted aside in favor of human civilization. Hybrid and remote work provide us an opportunity for a re-widening, a dispersal of human capital that unwinds some of the concentration to urban areas we’ve seen over the last century, restoring a better balance.
Imagine a world in which massive office districts of major cities are remade to attract residents with remote or hybrid jobs who choose their home based not on its proximity to their corporate office, but what it offers in terms of great schools, hospitals, arts, entertainment, parks, waterfront, and community. Giant office buildings could offer flexible work space that can be rented short- or long-term by individuals or organizations.
Converting office districts to live-work zones would offer a much needed influx of new residential space, helping to combat the rising cost of homes and rentals. Citizens who do work essential to the livelihood of a community, such as teachers, healthcare providers, and service workers are provided with tax breaks, as needed, to ensure they can afford to live alongside those whose work can be done fully remotely.
Knowledge workers like me, who move out of the city, make urban spaces more affordable for essential workers who staff hospitals and restaurants. Meanwhile, small towns and cities that were hollowed out by deindustrialization over the last 30 years get an influx of new residents to support their tax base. Again, the majority of jobs don’t allow for remote work, but a great deal of wealth is concentrated among the jobs that do. Empowering or even encouraging those workers to live wherever they want could have a positive impact on the affordability of cities and the economic health of rural communities.
Forward-thinking cities can still focus on attracting top-tier workers in areas like finance, technology, and law, but they will do so by making themselves wonderful places to work, live, and play, not by insisting on the primacy of an antiquated 9-to-5 office culture.
The lesson I take from the open-source revolution and the last two decades of software development is that the platforms and tools with the least friction tend to win out. A “butts-in-seats” mentality that demands a regular commute on a rigid schedule creates a ton of unnecessary friction—in our jobs and in our lives. The city of the future, I hope, will be a place where anyone can safely and securely contribute their ideas or apply their skills. Make the permissionless innovation of open source the bedrock ideology of the next generation of urban centers, and we can start to build a new metropolis better-suited to our post-industrial age of information.
The post Remote work is killing big offices. Cities must change to survive appeared first on Stack Overflow Blog.
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we’ll see you in 2023.]
Nearly two years into the pandemic, many Americans are reevaluating their relationship with work. The US Bureau of Labor Statistics reported that 4.5 million Americans had quit their jobs at the end of November 2021, while 10.6 million jobs were open.
Software developers—even though their jobs can typically be done remotely and should, in theory, be more stable during a pandemic—are leading the exodus.
Some analysts have suggested that the number of people quitting white-collar office jobs is modest, and that the Great Resignation is about strong demand for workers, rather than a rethinking of labor. While it’s clear that some industries have been hit harder than others, it’s also true that higher-paid knowledge workers like developers are playing a prominent role in the Big Quit.
Harvard Business Review conducted an in-depth analysis of over nine million employee records from more than 4,000 companies across industries and found that resignation rates are highest in healthcare and tech. The study found that, generally, “resignation rates were higher among employees who worked in fields that had experienced extreme increases in demand due to the pandemic, likely leading to increased workloads and burnout.”
Resignations among healthcare workers, who have been on the front lines of a pandemic for nearly two years, are not a surprise. But what’s driving developers to make their exit, and what challenges does the rising resignation rate entail for individual contributors, managers, team leads, and companies who want to protect against knowledge loss and ensure business continuity?
Let’s get into it.
Increased demand equals burnout; burnout equals resignationIn tech, the resignation rate rose by 4.5% last year, according to Harvard Business Review. Eighty-three percent of developers report suffering from burnout, and 81% say it’s gotten worse during the pandemic. The top reason for pandemic-related burnout among developers? An increased workload.
The pandemic has contributed to an increase in demand for developers, even as it’s nudged many to quit their jobs. Beginning in March 2020, organizations accelerated their digital and cloud roadmaps to allow employees to work remotely. The resulting increase in software adoption and growing reliance on software across industries has increased demand for developers.
In some ways, of course, this is good news: when demand exceeds supply, skilled and seasoned developers can expect more job offers and more attractive compensation packages. But high demand can also cause developers to become overwhelmed and burn out. In fact, so many developers are resigning that a shortage of software developers is likely—not just in the United States, but also elsewhere.
A cultural shiftBurnout isn’t the only explanation for the rising resignation rate. The shock of the pandemic, lockdowns, and a complete shift to remote work caused many people to fundamentally change how they see work. As UC Berkeley economist Ulrike Malmendier argues, “The pandemic and rise of remote work have changed the way we view our lives and the world.”
Texas A&M psychologist Anthony Klotz, whom NPR credits with coining the term “Great Resignation,” says “pandemic epiphanies” are inspiring dissatisfied workers to give their notice. Those epiphanies take many forms:
- I could make more money somewhere else.
- I deserve better working conditions.
- I need more vacation time.
- I need a better work-life balance.
- I want to do something completely different with my career.
- I want to start my own business.
And those epiphanies often end with the words I quit.
“We can do better”While quitting might seem like an expression of dejection or an admission of defeat, in many ways the Great Resignation is more about growing confidence, a sense that the dynamic between labor and employers has shifted, and that workers have more choice and control. The Atlantic suggests that while “quitting is a concept typically associated with losers and loafers,” the Great Resignation “is really an expression of optimism that says, We can do better.” In fact, we may come to see the pandemic as “a crucial inflection point” in American attitudes toward work—and even the inception of a healthier work-life balance.
We’ve realized that our relationship with work needs, well, work. As Vox points out, “the pandemic—as well as government social safety nets like extended unemployment benefits—gave people the time, distance, and perspective to reevaluate the place of work in their lives.” And this reevaluation is “especially notable for Americans, for whom work is considered a part of their identity and who put in more hours than most other industrialized nations.”
Money matters—but it’s not the only thing that mattersOften programmers quit because they can make more money elsewhere. Compensation structures often incentivize developers to change jobs: the experience a person acquires in the role becomes more valuable than the incremental raises most developers can expect every couple of years. The spike in demand for digital transformation, coupled with the Great Resignation, has created an increasingly competitive hiring environment for software talent. This has boosted the compensation offered by employers looking to make critical hires.
Our own data shows that about 75% of developers are either actively seeking a new job or open to new employment opportunities. Of these developers, about 65% said compensation was the main reason they were looking to leave (or open to leaving) their current role. But money wasn’t the only factor: 39% wanted to work with new technologies, 36% were looking for a better work-life balance (including benefits like remote work and flexible hours), and 35% wanted better growth or leadership opportunities.
A tendency to view developers as technical resources rather than people (interchangeable, effortlessly rechargeable) causes some managers to neglect their employees’ job satisfaction and professional well-being. This attitude drives devs to quit. Almost universally, people want to work where they are valued and where they have an opportunity to grow their skills and advance their careers. For a growing number of developers, that means working for themselves.
Entrepreneurship is taking offMany people quit their jobs over the last two years to become self-employed freelancers, consultants, or entrepreneurs. In the words of The Wall Street Journal, “The pandemic has unleashed a historic burst in entrepreneurship and self-employment.” Some people want better-paying or more flexible jobs; others are anxious about COVID exposure, need to be home to provide childcare or supervise online learning, or are simply done with the rigidity of a 9-to-5 in the office.
The number of unincorporated self-employed people rose by 500,000 since the beginning of the pandemic, reaching nearly 9.5 million, according to Labor Department data. In other words, the number of self-employed people has risen by 6%, even as the overall employment rate in the US continues to lag almost 3% behind its pre-pandemic figure.
Americans also registered more than 4.5 million new businesses from January through October 2021, up 56% from 2020—the largest number on record dating back to 2004, according to the Census Bureau.
Developers are reinventing how they workOur own 2021 Developer Survey found that fewer professional developers were employed full-time (81%, a decrease from 83% in 2020). The percentage of professional developers who were independent contractors, freelancers, or self-employed rose from 9.5% in 2020 to 11.2% in 2021, suggesting that some developers are worried about job security or want more flexible work arrangements. So while the resignation rate is high, not all of those programmers are leaving the workforce; many are simply reinventing how work itself looks.
One consequence of this trend toward self-employment is that companies will likely find themselves working with contractors or consultants for certain roles and projects—increasing the potential for confusion as people come and go and distributed teams need an effective, asynchronous way to collaborate and communicate.
A focus on skills over pedigreeIn tech, economic power may be shifting toward labor. This means a focus on skills (what can you do?) over academic pedigree (where did you go?). Over the last 20 years, content platforms have allowed non-developers to build their skills and enabled experienced programmers to work more effectively. Some programmers shifted to creating tech companies, which allowed more people from non-technical backgrounds to enter the tech workforce. This gradual sea change has altered the way the industry works. For some programmers, it’s driven them out—or pushed them into business for themselves.
The rise of remote work, even before the pandemic, planted the seeds that are now bearing fruit in the form of the developer exodus: developers exhausted by corporate hierarchies, long commutes, expensive cities, and corrosive company cultures have been shifting to remote self-employment for a decade. The pandemic has accelerated the exodus, especially among developers 30-45 years old. These people are more senior in their careers and therefore more likely to launch their own businesses than to join another company—particularly in the face of age discrimination and high barriers to entry.
Challenges for managers and team leadsThe Great Resignation presents particular challenges for people who manage developers and lead development teams. For one thing, trying to hire and retain talent is time-consuming and resource-intensive, especially when so many people are no longer settling for jobs that don’t check all their boxes.
A high turnover rate is a related problem. Companies invest time and money onboarding and training new hires, but when those people leave, they take their institutional knowledge with them and create a vacuum that needs to be filled with another qualified candidate.
From an organizational perspective, companies need to protect against knowledge loss as employees come and go, expedite the onboarding of new employees so folks can start adding value quickly, and enable remote collaboration in an increasingly remote-first workforce.
But companies and managers also need to make avoiding developer burnout a priority, since that’s a contributing factor to many of these challenges: overworked developers quit, and the resulting churn consumes resources and causes knowledge loss. Valuing the developers on your team by recognizing and rewarding their hard work (and by investing in their professional development) goes a long way toward reducing burnout and attrition.
Plan for the boomerang effectManagers who create a positive work environment often find that employees who left for another company or to work for themselves want to come back after a short time, having realized that the grass wasn’t really greener after all. Self-employment is not without downsides, and it’s a rare company that doesn’t have a few drawbacks. To encourage these boomerang employees, managers need to build the right culture: one that values employees holistically.
“There is much value in recouping strong, previously-trained talent, but it is critical to let them know before they leave that the door could be open for a return,” explains SailPoint CEO Mark McClain in Fast Company. “Leaders who consciously establish from the get-go that work is a choice and that personal situations or great opportunities may warrant a job change make all the difference in encouraging boomerangs.”
Developer managers should take this advice to heart. The chances are good that some of the developers who left their jobs in 2021 will want them back in 2022—if they are welcomed back with open arms.
An inflection pointThe Great Resignation is reshaping the labor market in ways we’re just starting to understand. One thing is clear, though. The fact that developers are resigning at such high rates should nudge companies and managers to reevaluate how they treat these employees: how they’re paid, how much respect and autonomy they have, how flexible their jobs are, and how much work is demanded of them.
For developers, this is a moment to consider what is and isn’t working for you about your job—and whether you’re tempted to join the Great Resignation yourself. Let us know your thoughts in the comments.
The post The Great Resignation is here. What does that mean for developers? appeared first on Stack Overflow Blog.
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we’ll see you in 2023.]
Images are one of the most pervasive parts of the web. This isn’t a huge surprise as we humans are quite visual and the <img> tag has been around for almost 30 years. Images are so prominent that they are part of the most important content in over ~70% of pages on both mobile and desktop according to the largest contentful paint metric. We like images over on the Stack Overflow blog too.
The humble <img> element has gained some superpowers since it was created. Given how central it is to image optimization on the web, let’s catch up on what it can do and how it can help improve user-experience and the Core Web Vitals.
First, some tips to get us started optimizing our metrics:
- For a fast Largest Contentful Paint:
- Request your key hero image early
- Use
srcset+ efficient modern image formats - Avoid wasting pixels (compress, don’t serve overly high DPR images)
- Lazy-load offscreen images (reduce network contention for key resources)
- For a low Cumulative Layout Shift:
- Set dimensions (width, height) on your images
- Use CSS
aspect-ratioor aspect ratio boxes to reserve space otherwise
- For low impact to First Input Delay:
- Avoid images causing network contention with other critical resources like CSS and JS. While not render-blocking, they can indirectly impact render performance.
Note: Modern image components that build on <img>, like Next.js <Image> (for React) and Nuxt image (for Vue) try to bake in as many of these concepts as possible by default. We’ll cover this later. You can of course also do this manually just using the <img> element directly. If using 11ty for your static sites, try the 11ty high-performance blog template.
Image impact on user-experience and the Core Web VitalsYou may have heard of Core Web Vitals (CWV). It’s an initiative by Google to share unified guidance for quality signals that can be key to delivering a great user-experience on the web. CWV is part of a set of page experience signals Google Search will be evaluating for ranking. Images can impact the CWV in a number of ways.
Above, the Stack Overflow “The Key” hero image was the Largest Contentful Paint elementIn this guide, we will be using Lighthouse to identify opportunities to improve the Core Web Vitals, walking through optimizations for each metric. Lighthouse is an open-source, automated tool for improving the quality of web pages. You can find it in the Chrome DevTools suite of debugging tools and run it against any web page, whether public or requiring authentication. You can also find Lighthouse in PageSpeed Insights, CI, and WebPageTest.
Keep in mind that Lighthouse is a lab tool. While great for looking at opportunities to improve your user-experience, always try to consult real-world data for a complete picture of what actual users are seeing.
Cumulative Layout ShiftLayout shifts can be distracting to users. Imagine you’ve started reading an article when all of a sudden elements shift around the page, throwing you off and requiring you to find your place again. Cumulative Layout Shift (CLS) measures the instability of content. The most common causes of CLS include images without dimensions (see below), which can push down content when they load and snap into place. Ignoring them means the browser may not be able to reserve sufficient space in advance of them loading.
Generated using Layout Shift GIF Generator. You may also be interested in the CLS Debugger.The basicsTo place an image on a web page, we use the <img> element. This is an empty element—it has no closing tag—that requires a minimum of one attribute to be helpful: src, the source file for the image. If an image is called “keyboard.jpg” and it exists in the same path as your HTML document, it can be embedded as follows:
**<img** src="keyboard.jpg"**>**
To ensure our image is accessible, we add the alt attribute. The value of this attribute should be a textual description of the image, and is used as an alternative to the image when it can’t be displayed or seen; for example, a user accessing your page via a screen reader. The above code with an alt specified looks as follows:
**<img** src="keyboard.jpg"
alt="A beautiful pink keyboard."**>**
Next, we add width and height attributes to specify the width and height of the image, otherwise known as the image’s dimensions. The dimensions of an image can usually be found by looking at this information via your operating system’s file explorer (Cmd + I on macOS).
**<img** src="keyboard.jpg"
alt="A beautiful pink keyboard."
width="400"
height="400"**>**
When width and height are specified on an image, the browser knows how much space to reserve for the image until it is downloaded. Forgetting to include the image’s dimensions can cause layout shifts, as the browser is unsure how much space the image will need.
Modern browsers now set the default aspect ratio of images based on an image’s width and height attributes, so it’s valuable to set these to prevent such layout shifts.
Identify layout shifts from images without dimensionsTo limit Cumulative Layout Shifts from images without dimensions, include width and height attributes on your images and video elements. This approach ensures that the browser can allocate the correct amount of space in the document while the image is loading. Lighthouse will highlight images without a width and height:
Most images on the blog do set a width and height. Lighthouse was only able to find one small example and CLS on the pages tested were generally pretty good!Largest Contentful PaintIn many modern web experiences, images tend to be the largest visible element when a page completes loading. These include hero images and images from carousels, stories, and banners. Largest Contentful Paint (LCP) is a Core Web Vitals metric which measures when the largest contentful element (images, text) in a user’s viewport, becomes visible. This allows a browser to determine when the main content of the page has finished rendering.
When an image is the largest contentful element, how slowly the image loads can impact LCP. In addition to applying image compression (e.g. using Squoosh, Sharp, ImageOptim or an image CDN) and using a modern image format, you can tweak the <img> element to serve the most appropriate responsive version of an image or lazy-load it.
Identify the Largest Contentful Paint elementLighthouse has a “Largest Contentful Paint element” audit that identifies what element was the largest contentful paint. Hovering over the element will highlight it in the main browser window.
If this element is an image, this information is a useful hint you may want to optimize the loading of this image.
Hovering over an image in the Chrome DevTools Elements panel will display the dimensions of the image as well as the image’s intrinsic size.
Responsive imagesWhat about switching image resolution? A standard <img> only allows us to supply a single source file to the browser. But with the srcset and sizes attributes we can provide many additional source images (and hints) so the browser can pick the most appropriate one. This allows us to supply images that are smaller or larger.
**<img** src="keyboard-800w.jpg"
alt="A beautiful pink keyboard."
width="400"
height="400"
srcset="keyboard-400w.jpg 400w,
keyboard-800w.jpg 800w"
sizes="(max-width: 640px) 400px,
800px"**>**
The srcset attribute defines the set of images the browser can select from, as well as the size of each image. Each image string is separated by a comma and includes: a source filename (keyboard-400w.jpg); a space; and the image’s intrinsic width specified in pixels (400w), or a pixel density descriptor (1x, 1.5x, 2x, etc.).
From Speed at Scale with Katie Hempenius and I at Google I/OThe sizes attribute specifies a set of conditions, such as screen widths, and what image size is best to select when those conditions are met. Above, (max-width:640px) is a media condition asking “if the viewport width is 640 pixels or less,” and 400px is the width the slot the image is going to fill when the media condition is true. This typically corresponds to the page’s responsive breakpoints.
Device Pixel Ratio (DPR) / Pixel density cappingDevice Pixel Ratio (DPR) represents how a CSS pixel is translated to physical pixels on a hardware screen. High resolution and retina screens use more physical pixels to represent CSS pixels for imagery that is sharper and has more detailed visuals.
The human eye may not be capable of distinguishing the difference between images that are a 2x-3x DPR vs. an even higher-resolution. Serving overly high DPR images is a common problem for sites leveraging <img srcset> and a suite of image sizes.
It may be possible to use DPR-capping to serve your users an image at a 2x or 3x fidelity to prevent large image payloads. Twitter capped their image fidelity at 2x, resulting in 33% faster timeline image loading times. They found that 2x was a sweet spot of both good performance wins with no degradation in quality metrics.
Note: This approach to DPR-capping is currently not possible if using “w” descriptors.
Identify images that can be better sizedLighthouse includes a number of image optimization audits for helping you understand if your images could be better compressed, delivered in a more optimal modern image format or resized.
Lighthouse detected that the Stack Overflow blog is using WordPress and was able to suggest some WP-specific guidance on how to size a small number of images that could have been smaller.Even those images that are responsive (that is, sized relative to the viewport) should have width and height set. In modern browsers, these attributes establish an aspect ratio that helps prevent layout shifts, even if the absolute sizes are overridden by CSS.
When not using an image CDN or framework, I like to use responsivebreakpoints.com to determine the optimal image breakpoints and generate <img> srcset code for my responsive images.
Serving modern image formatsArt direction allows us to serve different images depending on a user’s display. While responsive images load different sizes of the same image, art direction can load very different images based on the display.
The browser can choose which image format to display using the <picture> element. The <picture> element supports multiple <source> elements and a single <img> element, which can reference sources for different formats including AVIF and WebP.
<picture> <source srcset="keyboard.avif" type="image/avif"> <source srcset="keyboard.webp" type="image/webp"> <source srcset="keyboard.jpg" type="image/jpeg"> <img src="keyboard.jpg" alt="Omg a keyboard"></picture>
In this example, the browser will begin to parse the sources and will stop when it has found the first supported match. If no match is found, the browser loads the source specified in <img> as the fallback.
Understanding the myriad of image format options out there today can be a confusing process, but you may find Cloudinary’s comparison of modern image formats helpful:
Identify images that could be served in a more modern formatLighthouse highlights potential savings from serving images in a next-generation format.
I also enjoy using Squoosh for its support of bleeding-edge formats, such as JPEG XL, as it offers a low-friction way to experiment with modern formats outside of a CLI or CDN.
There are multiple ways to approach sizing issues as both srcset and sizes are both usable on <picture> and <img>. When in doubt, use <img> with srcset/sizes for single images that have a simple layout. Use <picture> for serving multiple formats, complex layout, and art direction.
caniuse has the latest browser support details for WebP, AVIF and JPEG XL.
Content negotiationAn alternative to manually handling image format selection using <picture> is to rely on the Accept header. This is sent by the client, allowing the server to deliver an image format that is a best-fit for the user. CDNs such as Akamai, Cloudinary, and Cloudflare support it.
Request your image earlyIf you are optimizing LCP, preload can help boost how soon late-discovered hero images (e.g such as those loaded by JavaScript or background hero images in CSS) are fetched. Where possible, attempt to solve this by better minimizing the request chains to your LCP image so that the browser doesn’t need to first fetch, parse, and execute JavaScript or wait for a component to render/hydrate to discover the image.
You can use <link rel=preload> with <img> to allow browsers to discover critical resources you want to load as soon as possible, prior to them being found in HTML.
<link rel="preload" as="image" href="keyboard.jpg">
Note: Use preload sparingly and always measure its impact in production. If the preload for your image is earlier in the document than it is, this can help browsers discover it (and order relative to other resources).
Preload can be used to fetch sources for an <img> of a particular format:
<link rel="preload" as="image" href="keyboard.webp" type="image/webp">
Preload can also be used to fetch responsive images so the correct source is discovered sooner:
<link rel="preload" as="image" href="keyboard.jpg" imagesrcset=" poster_400px.jpg 400w, poster_800px.jpg 800w, poster_1600px.jpg 1600w" imagesizes="50vw">
PlaceholdersWhat if you would like to show the user a placeholder while the image loads? The background-image CSS property allows us to set background images on an element, including the <img> tag or any parent container elements. We can combine background-image with background-size: cover to set the size of an element’s background image and scale the image as large as possible without stretching the image.
Placeholders are often inline, Base64-encoded data URLs which are low-quality image placeholders (LQIP) or SVG image placeholders (SQIP). This allows users to get a very quick preview of the image, even on slow network connections, before the sharper final image loads in to replace it.
**<img** src="donut-800w.jpg"
alt="A delicious donut"
width="400"
height="400"
srcset="donut-400w.jpg 400w,
donut-800w.jpg 800w"
sizes="(max-width: 640px) 400px,
800px"
loading="lazy"
decoding="async"
style="background-size: cover;
background-image:
url(data:image/svg+xml;base64,**[**svg text]);"**>**
Note: Given that Base64 data URLs can be quite long, [svg text] is denoted in the example above to improve readability. The decoding attribute above is also used to signal a preference between synchronous and asynchronous image decoding.
With an inline SVG placeholder, here is how the example from earlier now looks when loaded on a very slow connection. Notice how users are shown a preview right away prior to any full-size images being downloaded:
Images loaded on a simulated slow connection, displaying a placeholder approximating the final image as it loads in. This can improve perceived performance in certain cases.There are a variety of modern solutions for image placeholders (e.g CSS background-color, LQIP, SQIP, Blur Hash, Potrace).
Perceptual image loading methods from Gunther Brunner of CyberAgentFirst Input DelayIt’s possible for images to block a user’s bandwidth and CPU on page load. They can get in the way of how critical resources are loaded, in particular on slow connections and lower-end mobile devices leading to bandwidth saturation. First Input Delay (FID) is a Core Web Vitals metric that captures a user’s first impression of a site’s interactivity and responsiveness. By reducing main-thread CPU usage, FID can also be reduced.
Image lazy loadingWhat about offscreen images that are not visible until a user scrolls down the page? There may not be value in eagerly loading lots of images a user may never see, especially if it slows loading more critical content they see earlier on in the page. In the example below, all the images on the page are “eagerly loaded” (the default in browsers today), causing the user to download 1.1 MB of images. This can cause users’ data plans to take a hit in addition to affecting performance.
An image gallery eagerly loading all the images it needs up front, as shown in the Chrome DevTools Network panel. 1.1 MB of images have been downloaded, despite only a small number being visible when the user first lands on the page.Using the loading attribute on <img>, we can control the behavior of image loading. loading="lazy" lazy-loads images, deferring their loading until they reach a calculated distance from the viewport. Setting loading="eager" loads images right away, regardless of their visibility in the viewport. The default is eager, so it doesn’t need to be explicitly added (that is, just use <img> for eager loading).
Below is an example of lazy-loading an <img> with a single source:
**<img** src="donut.jpg"
alt="A delicious pink donut."
loading="lazy"
width="400"
height="400"**>**
With native <img> lazy-loading, the earlier example now downloads only about 90 KB of images! Just adding loading="lazy" to our offscreen images has a huge impact. You ideally want to lazy-load all images present outside of the initial viewport and avoid it for everything within the initial viewport.
An image gallery using native image lazy-loading on images outside of the viewport. As seen in the Chrome DevTools Network panel, the page now only downloads the bare minimum of images users need up front. The rest of the images are loaded in as users scroll down the page.Lazy loading also works with images that include srcset:
**<img** src="donut-800w.jpg"
alt="A delicious pink donut"
width="400"
height="400"
srcset="donut-400w.jpg 400w,
donut-800w.jpg 800w"
sizes="(max-width: 640px) 400px,
800px"
loading="lazy"**>**
The Opportunities section of Lighthouse lists any offscreen or hidden images on a page that can be lazy-loaded as well as the potential savings from doing so.
See caniuse.com for latest browser support for native image lazy-loading.ConclusionsImages are key to delivering a great experience on the web. Hopefully you’ve learned something useful about how far the <img> element has evolved. When in doubt, test it out and see what tools like Lighthouse suggest might be opportunities to deliver an even more amazing image loading experience than you are today.
If you’re interested in learning more, I recently published a new book called Image Optimization that covers advanced image optimization techniques that can help make your images on the web shine.
The post Picture perfect images with the modern element appeared first on Stack Overflow Blog.
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we’ll see you in 2023.]
After two decades of working in the technical training industry, I’ve found software development roles need people who have the skills to do the job, regardless of whether those skills come from a bachelors in computer science or a certification course on the internet.
I’ve worked in various roles focused on technical training before moving to Skillsoft, where I’m the VP of Tech Products, figuring out what developers want to learn today and how we can give them the skills they need to succeed.
Recently, we surveyed 9,300 tech professionals to learn more about their roles, salaries, skills, certifications, and more. There are three main roles I’ll focus on below.
I’ll also explore the broader trends that might help shape your career path and look at practical ways you can get the most out of your education and training, whether you’re just starting out, looking to level up, or trying to hire and retain the best technical talent.
Part one: The highest-paying rolesAccording to our research (and research from others too), these roles rank among the highest-paying in tech today:
- Enterprise cloud architect
- Security architect
- Data scientist / architect
Enterprise cloud architect – Average: $172,241Enterprise cloud architects do the high-level technical planning and design work for an organization’s infrastructure, including its apps and other products. They design the architecture of systems, craft deployment strategies, and manage the long-term stability, resilience and security of systems, services, and products.
Depending on the maturity of the organization, this role might also involve crafting a migration strategy: deciding what to take along, what to deprecate, and how to make the change with the least disruption. And of course, if you find success and growth, you’ll have to start thinking about change management and upgrading your site reliability engineering (SRE) team.
For those who aspire to this role (or hold it today), the combination of cloud and security could be a huge opportunity for you.
People in this role, on average, hold roughly five certifications. Global Knowledge’s annual “15 Top-Paying IT Certification List” shows those with cloud-related certifications tend to make the highest salaries. Those with the Google Cloud Professional (GCP) Cloud Architect certification make an average of $169,029, ranked number two on the list just behind those with a GCP Data Engineer certification.
However, 70% of cloud architects don’t have any security certifications—even the basics. This is a spot where a lot of folks can bolster their skill set and value. Despite the gap, more architects are seeing the value in security credentials. About one-quarter of architects say they plan to pursue a security certification in the year ahead.
Here some resources to help you become a cloud architect:Skillsoft Aspire Journey – DevOps Engineer to Cloud Architect (features 39 courses)
Skillsoft Aspire Journey — Network Security Specialist To CloudOps Security Architect (features 35 courses)
Certification Prep Guide: How to Become a Google Certified Professional Cloud Architect
Here are guides for AWS and Microsoft Azure, which also rank highly.
Security architects – Average: $137,776Due to the overwhelming need for cybersecurity professionals, organizations tend to compensate security professionals higher than most. Security architects design the security systems, and by extension, they are the ones on the line when something goes wrong with the defenses.
This is an in-the-trenches role. You don’t just say how it should work, you make it work. This group, more than cloud, seems to value certifications. Almost all (94%) hold a certification, with 87% pursuing more.
Only one-in-five security architects seek cloud certifications, so bolstering your skills in this area might help you stand out from the crowd. What’s more, a lot of organizations are most exposed in their APIs and front-end services. If you can improve DevSecOps, it alleviates a lot of the pain later on.
For security architects interested in additional certifications, these two disciplines can add value to your resume: Agile or DevOps. In today’s world, DevSecOps is imperative and helps security professionals deploy best practices in their organizations and adapt rapidly to ever evolving threats.
- Skillsoft Aspire Journey – Security Analyst To Security Architect (features 44 courses)
- Certification Prep Guide: How to Earn Your CompTIA Security+ Certification (another top-paying certification)
Data scientist – Average: $121,853This is the newest and hardest to pin down, with specific job titles varying greatly. These are folks building data pipelines, warehouses, and storage. They work on data analysis, building dashboards, and research and experimentation.
Because of the growing demand for data scientists, organizations continually place higher and higher values on this skill set. While organizations like Indeed report an annual average salary of $121,853, Robert Half says people in this role could make up to $135,000 or more.
For data roles, if you’ve already got the basics or advanced skills, layering on cloud, operations, and security skills will set your resume apart from the pack—especially when considering how the three roles mentioned here work together. Think of these areas as the three legs of a stool in a modern organization: They make up different sides of the same operation. You you build a cloud, you secure it, you need to ingest data to learn and improve.
If this is your intended specialty, thesee these resources below can help you progress your career:
- Skillsoft Aspire Journey – Data Analyst to Data Scientist (features 100 courses)
- Recommended: Essential Math for Data Science (features 35 courses)
Enjoying this piece? Listen to an interview with the author, Skillsoft’s Mike Hedrickson.
Part two: How to make the most of educational opportunities You know some of the roles and skills that might be worth pursuing. What’s the best way to get the education or training you need?
Let’s break it down across three dimensions:
- Beginners: folks who are just starting their careers and hoping to break into a new role.
- Intermediate and advanced: folks who already have experience but want to level up or change their career.
- Managers and executives: folks who employ developers and want to ensure they can learn and grow.
Beginner A lot of folks can get caught in analysis paralysis when it comes to starting their coding education. My first piece of advice would be that you learn best when you feel comfortable and motivated. Everyone learns in different ways.
We live in an amazing time when access to training in software development is widely available across the internet, often at little or no cost to start. You should think about what makes sense in terms of the time and budget you have available, then decide what style works best for you.
The modality is key. Consider your options:
- Mentoring / coaching
- Instructor-led training
- On-demand courses
- Microlearning
- Peer groups
- Practice labs
- Gamification
Second, make it your hobby. Half an hour a day goes a long way if you keep it up for one year. It will provide more value than an in-depth course you start and never finish.
Intermediate and advancedWhen I speak with more experienced developers about the keys to lifelong learning, I hear how it’s vital to carve out time to study each day or each week. Consistency is key.
Work with your manager and any direct reports to put time on the calendar for improving your existing skills or adding new ones.
Also, consider how you plan the steps in your journey and what tools you use. If you like and identify with what you do, you will enjoy it more. That will help you get through any career doldrums.
Remember when you were a kid and the best teachers made learning fun? I challenge you to find that joy again and recognize that enjoying education is a mindset you can hone.
Managers and executivesWhen creating career paths for individuals and showing them what they can aspire to, it’s important to keep them motivated.
How do you hire and retain the best technical talent? It turns out salary isn’t the only, or even the most important, motivator. In our research, opportunities for growth and development rank highest, with work-life balance not far behind.
At a CIO conference, someone asked me, “What if I train someone and get them a certification and they leave, you know, because it makes it easier for them to leave?”
And my answer to them was, well, what if you don’t train them and they stay right there? If you want people to be trained and educated and moving forward, invest in them.
If you invest in them, they will stay.
Giving employees a clear view of career paths and ladders can also be motivating. Not everyone wants to be an application architect, but even if they don’t want to hold that position, knowing what skills go into it at your organization is something a lot of devs want to understand.
Work-life balance and growth opportunities are keyWe started out this blog talking about salary, and of course, compensation is important. But what we found in our research was that people care more about opportunities for growth and development than they do compensation.
The highest percentage of respondents to our survey (59%) say they value opportunities for growth above all else. Compensation came next at 39%, but work-life balance followed closely at 31%. Work-life balance ranks highly in importance broadly, and a lack thereof is cited as a leading reason for why people change employers.
The data speaks for itself. But I would add that one of the greatest aspects of this field is that people have a passionate, lifelong love of learning and self-improvement. Bettering oneself can renew energy, focus, and hope in people at every level of their career. At the end of the day, people want a sense of purpose. Working toward their goals and aspirations gives them that.
In the annual IT Skills and Salary Report, we go a lot deeper into in-demand areas of tech, the highest-paying certifications, and more. You can read the entire report here.
The Stack Overflow blog is committed to publishing interesting articles by developers, for developers. From time to time that means working with companies that are also clients of Stack Overflow’s through our advertising, talent, or teams business. When we publish work from clients, we’ll identify it as Partner Content with tags and by including this disclaimer at the bottom.
The post The three top-paying tech roles in 2022 and the skills you need to land them appeared first on Stack Overflow Blog.
Welcome to ISSUE #157 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: gathering data on why people take new jobs, worrying about what university faculty should (or can) do about AI-generated text, and raining on your quantum wormhole parade.
From the blogHat’s out of the bag! Join us for Winter/Summer Bash 2022! stackoverflow.blog
Earn a hat this season! Winter/Summer Bash runs through January 4. Join us for this fun end-of-year tradition, sponsored by Splunk. As you participate on Stack Exchange sites, you’ll be able to earn hats and other accessories for your avatar.
Job insights from the tech community: The latest survey results from Stack Overflow Knows stackoverflow.blog
Money gets people to leave their jobs, but it won’t always make them stay.
The next step in ecommerce? Replatform with APIs and micro frontends stackoverflow.blog
Your ecommerce solution doesn’t need to know what you’re selling, just how to sell it.
Taking drag and drop tech stacks with Builder.io’s Steve Sewell stackoverflow.blog
For his TikToks and coding wisdom.
Evolve data architectures to speed modernizing applications promotion
Cloud-native architectures webinar: Practical guidance on architecting data platforms for DevOps and application modernization. Plus, tips on data management and democratization in enterprises.
Interesting questionsWhy was the stack originally invented? retrocomputing.stackexchange.com
It’s the same reason we invented wallets: local storage.
How should a faculty deal with the problem of AI-generated texts? academia.stackexchange.com
Jarvis, write me a policy for dealing with AI generated essays
Were over 3000 persons arrested in Britain for social media posts in 2020? skeptics.stackexchange.com
Almost half of them were for reposting ancient All Your Base memes.
How would a violin or trumpet degrade over time on Mars? space.stackexchange.com
Just what you’ve always wanted! Plenty of free time to learn the trumpet.
Links from around the webTaming names in software development www.simplethread.com
One of the hardest computer science problems is naming things. Here’s how to get better.
Does WWW still belong in URLs? css-tricks.com
There’s a long-running argument over URL names. Here’s the reasoning for both sides.
Google’s Sycamore chip: no wormholes, no superfast classical simulation either scottaaronson.blog
Remember the whole wormhole thing we talked about a few issues back? Well… we learned more about it.
Why Japan’s internet is weirdly designed www.youtube.com
The internet in Japan looks different. Why?
A blast from the past: Network protocols in orbit: Building a space-based ISP.
The post The Overflow #157: Tis the season for hats appeared first on Stack Overflow Blog.
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we’ll see you in 2023.]
Many apps today are actually a front-end for a series of API calls. APIs are necessary to proper functioning of such applications, but if you don’t protect them, bad actors can exfiltrate data, DDoS your servers, or otherwise abuse them.
OAuth is one of many solutions you can use to protect your APIs and other resources. It allows users to securely delegate access to resources without sharing their original credentials. OAuth2 (the version of OAuth that this article will cover) has been around since 2012 as a standard and is built on lessons from other, earlier standards, including OAuth1 and SAML.
Being a standard, OAuth benefits from many smart people working together in the open. As a user of this standard, you gain all their hard work without having to hire them! This work includes security analysis, where the group constantly considers different attack vectors and weaknesses in the protocol and ameliorates them. The members of the group also work to support weird edge cases in scale, user interfaces, and network connectivity. If you have a typical auth use case, the OAuth standard almost certainly will work for you.
If you need core functionality, you should be covered by almost any OAuth server. But if you need specialized functionality, even if it is part of a standard, carefully review the documentation of any solution you are considering.
While I’ll dive further into how you actually use OAuth to protect an API in your system below, including code examples, I won’t cover certain topics in this article. Some of the topics that will be omitted include:
- Every single OAuth related specification. There are a lot of them!
- All the edge cases OAuth and related standards can address.
- How to use OAuth to access a third party API such as Google. This is a related use case, but different enough that it doesn’t make sense to cover it.
When you are done with this article, you’ll know more about why you might choose OAuth, when to use it, and some alternatives.
Why use OAuth to protect your APIs?When you are using OAuth, you outsource user authentication and authorization to a central identity provider (IdP). Users sign in to the IdP and are granted time-bound permissions in the form of an access token. This token is presented to other applications, APIs, and services.
Using such a centralized service has a number of advantages:
- One system holding user PII can be locked down and protected more easily than many systems.
- Just as a database is focused on retaining data with certain guarantees, an IdP can focus on login functionality and provide a well understood interface.
- Because an IdP is the place where authorization and authentication decisions are performed, it becomes a single central location for analyzing, enabling, and disabling access to systems.
- When all users authenticate at the IdP, you can easily add functionality, such as federation to other identity sources or security measures like multi-factor authentication. All applications, APIs and services which accept tokens from the IdP benefit from additional functionality without any change to their code.
OAuth, having been around for over a decade, is ubiquitous. There are OAuth clients in almost every modern programming language, and even some less modern ones such as COBOL. This ubiquity means that when you are working with an OAuth server, you can leverage libraries to perform the integration quickly.
It has been extended multiple times for specialized use cases (called profiles) and new authorization flows (called grants). The standards body behind OAuth, the OAuth IETF working group, offers best practices for newer technologies like mobile applications or IoT devices.
Below I will discuss the core standards you should know, but be aware that not every IdP implements every standard within the OAuth umbrella. Examples of standards that may not be implemented include:
- The device grant, which lets you perform an OAuth flow for a device with limited user input options.
- Dynamic client registration, which allows clients to register with an IdP in an automated fashion, without human or out-of-band intervention.
- MTLS, which allows mutual X.509 certificates to be used for authentication and to bind tokens to specific clients.
A sampling of specificationsOAuth was built to be extended. Unlike earlier auth related specifications like SAML, which were monolithic, large and difficult to implement, OAuth is composable and extendable. Even the core specification was delivered in two RFCs, RFC 6749 (which covers the flows) and RFC 6750 (which details the token).
Below are brief overviews of the core standards, as well as some that are useful in particular circumstances. You’ll also learn about standards that are not yet codified, but are worth keeping an eye on. If you plan on implementing any of these, it’s always a good idea to dive into the RFC texts themselves.
Core OAuth standardsThese are the core OAuth standards, though not every implementation has to use every one of them.
- RFC 6749 and RFC 6750: As mentioned above, these comprise the beating heart of OAuth. The former covers the main authorization flows, called grants. The latter covers how the access token, the end product of a grant, should be used when it is a bearer token (most of the time, it will be a bearer token). A bearer token is not bound to a particular client. I like to think of a bearer token like a car key: anyone who holds the key can start the car. In the same way, anyone who holds a bearer token can gain access to resources protected by it.
- RFC 7519 documents a common token format, JSON Web Tokens or JWTs. JWTs are JSON objects which contain claims (which is fancy for “data, possibly with a standardized meaning”) about an entity for whom the token was issued. They are typically cryptographically signed, which allows them to be verified and trusted. Sibling standards further define JWTs and related functionality: RFC 7515, RFC 7516, RFC 7517, RFC 7518 and RFC 7520. RFC 7517 is especially useful as it covers publishing public keys, which allows asymmetric signing algorithms such as RSA to be used to sign a JWT.
- OpenID Connect (OIDC) is an extension of OAuth (called a profile) that allows access to authentication information. Although OAuth can and is used without OIDC, they are often implemented together.
- RFC 7662 documents introspection. This process validates an access token by communicating with the OAuth server that created it. Using introspection is an alternative to JWTs and other self-contained token formats.
- RFC 7636 outlines PKCE (pronounced ‘pixie’) and is an example of how standards address security issues. PKCE protects clients incapable of holding secrets, such as browser or mobile applications, from an entire class of attacks. PKCE is recommended for all clients using the Authorization Code grant.
- The evolving OAuth2.0 Security best current practices (BCP) document discusses security threats and extends the 2013 OAuth threat model standard, RFC 6819, which is almost a decade old.
Next, let’s look at some interesting standards which might not be applicable in every situation.
Specialized OAuth standardsSince OAuth is extensible, some optional functionality may be very important to you, and some may not. There’s no central repository showing which IdPs support which standards, so check technical documentation to ensure you get the implementation and functionality you need.
Some standards that fall into this category include:
- RFC 8252 discusses OAuth grants and mobile applications. Since mobile applications cannot maintain secrets and each application has a high level of control over the user input, there are certain additional steps you must take to ensure security. This is especially important if the client and the IdP are not controlled by the same organization.
- RFC 7591, dynamic client registration, allows clients to register themselves. In core OAuth, client registration occurs rarely and is typically done in a manual manner. With this RFC, clients can discover everything they need to register themselves. This is useful when you want to have many unique clients.
- RFC 8628 creates an additional grant, the device grant, designed specifically for clients that have limited user input options, such as televisions or other appliances. With this grant, people may log in using a secondary input device, such as a computer or phone, and still have the original client receive the access token.
- RFC 9068 covers how to specify JWT access tokens in a standard format, allowing different IdPs and resource servers to interoperate.
- DPoP/MTLS addresses an issue left unresolved with the core token RFC, 6750, because of implementation complexity. These documents (the former of which is a draft, not a full-fledged RFC) outline how to bind a token to a particular client. Each of these uses a different mechanism, but if the idea of a bearer token being stolen and used by a malicious actor is unacceptable to you or your security team, using these can help.
OAuth continues to evolve and there are two main efforts to improve it. Let’s discuss these efforts in the next section.
OAuth’s futureWhile there are plenty of incremental improvements being discussed in various standards bodies, the two main efforts to improve the core of OAuth are OAuth 2.1 and GNAP.
OAuth 2.1 is currently under active development. This specification consolidates best practices around security and usability which have been added to OAuth over the years since it was released. The authors have explicitly ruled out any breaking changes or radical modifications.
GNAP, on the other hand, is a reimagination of the OAuth protocol, in the same way that OAuth2 was a reimagining of earlier protocols. This early draft includes breaking changes such as introducing new software actors and changing the core communication format from form parameters to JSON.
Whew, that was a lot. Hopefully this gives you an idea of the breadth and width of the OAuth landscape as well as the kinds of problems you can solve using it.
Next, let’s dig into some details.
Which grant should I use?Consider a simple application, diagrammed above, which allows users to manage todos. Clients like a web browser or mobile app will access two different components: an OAuth platform to authenticate users and a Todo API to add, update, or delete todos.
An OAuth grant is a specific flow that results in an access token. Per the specification, a token is an opaque string without any structure. However, OAuth servers can choose their token format, and many use JSON Web Tokens, which do have internal structure. Some parts of the grant, such as error messages or expected parameters, are well defined. Others, such as the actual authentication process, are left as implementation details.
A grant authenticates the user or other entity, assembles appropriate permissions based on user roles, groups, and requested scopes, gathers the authorization data, and encapsulates those permissions from the authorization server in the form of an access token. Here’s an example of a token: mF_9.B5f-4.1JqM.
The token is often, but not always, sent to the client for later presentation to the resource server. In the diagram above, the mobile apps and browser on the left will be going through an OAuth grant in order to gain access to the Todo API.
In this context, which grant should you choose to send your users through? The core RFC, RFC 6749, defines a number of grants. It can be confusing to determine which is the best fit for your use case.
For most developers, there are really only a few questions to ask:
- Is there a human being involved?
- How long will the client need access to the protected resource?
Let’s tackle each question.
Is there a human being involved?Whenever a user is involved, the best grant to use is the Authorization Code grant. This grant will be discussed in more detail below. Using this offers architectural flexibility around the final location of the access token as well as a better security profile. In general, you should pair the Authorization Code grant with PKCE.
In the todo application outlined in the diagram above, a human being is making the initial request to display todos in their application, so the Authorization Code grant should be used.
But let’s consider a different situation.
Suppose we extend the application with new functionality to remind our users of deadlines associated with their todos.
In that case, we need a reminder service which would run every day, see which todos were due, and send a reminder email. This service would still need to authenticate because we wouldn’t want anyone to be able to access our todos. But there is no user kicking off the request—perhaps its only a cron job.
That flow of permissions might look a little something like this:
When there is no human being starting the request, the correct grant to use is the Client Credentials grant. This grant should be used whenever you have service to service communication and want to leverage the client library support, centralized authentication, and security infrastructure of an authorization server.
How long will the client need access to the protected resource?In general, access tokens are good for a short period of time (seconds to minutes). If the client can gain access to the resources it needs in that time, then all is well and good. However, sometimes the client needs access for the longer term. When the access token expires, the client can either ask the user to re-authenticate or it can use the Refresh grant.
This grant allows a client to transparently re-request a token with the same permissions without forcing the user to re-authenticate.
What about the other grants?The other grants, such as the Device grant or the Resource Owner Password grant, should be used only when the use case calls for their specific functionality.
In general, use the Authorization Code grant if there is a human being involved and the Client Credentials grant if you are performing server to server communication.
Alternatives to OAuthOAuth isn’t the only option to protect your API. The main alternative is API keys. They are a good solution in some situations and they are simple to understand. However, compared to OAuth, they do have some deficiencies.
API keys are relatively static. While you can and should rotate API keys, you have to build the infrastructure to do this yourself. API keys are not time-bound unless you also build this into your system.
API keys are “secrets” and should be managed as such. Just like the OAuth client secret, API keys are privileged data, which means you can’t, for example, store them safely in JavaScript. Therefore, they limit your architectural flexibility.
There also is no encoded information in an API key, unlike tokens, which may have encoded information, especially if an access token is a JWT. This richer data format can include useful business-specific information such as a todo app subscription level. It also allows for authorization to be performed without requiring “phoning home” to the the OAuth server which created the token.
ConclusionIn this article, you learned about why OAuth is a good choice to protect access to your APIs, more about its component standards, and options for using OAuth grants to protect resources. You also learned about alternatives to using OAuth such as API keys.
While OAuth can be complex, it handles a large number of use cases. You separate out the concern of authentication to a specialized component, while using a standardized temporary credential (the token) in the rest of your system. In addition, by using OAuth, you leverage standards and expertise from all over the world.
In the next article in this two part series, we’ll look at how the Authorization Code grant works in step by step detail with code, as well as how you should validate a token.
The post The complete guide to protecting your APIs with OAuth2 (part 1) appeared first on Stack Overflow Blog.
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we’ll see you in 2023.]
In recent years, web application development has undergone a radical transformation due to the rise of Next.js. This framework allows developers to build powerful web apps with JavaScript without worrying about building the back-end infrastructure. It simplifies the process of creating hybrid applications with client-side as well as server-side rendered pages. While the framework is simple, developers still struggle to increase the speed of their applications.
An application’s speed is strongly related to the amount of time it takes to serve the application code, styles, and data to the client in the first round trip. When the server needs to send additional assets (for example images) during the initial round trip, the application performance degrades. Fortunately, developers can follow a number of best practices to improve the speed of their Next.js applications.
Use server-side renderingServer-side rendering (SSR) is a technique used to render the initial HTML of a webpage on the server before delivering it to the browser. Using server-side rendering will help your app reduce the time required to render the first page on the client side, so the user will see the content of your page much faster. SSR will also improve application performance, especially on mobile devices.
Next.js provides an async function named getServerSideProps that we can use to render any page on the server and return static HTML to the client. You can do your data-fetching work inside this function.getServerSideProps function takes a context object as a parameter that contains page data such as params, res, req, query, etc. This function will be called by the server on every request, returning an object that will be passed to the page component as a prop. In other words, this function allows you to fetch your data from the API and return the fetched data to the page component as a prop.
Example:
// This function will be called by the serverexport async function getServerSideProps({context}) { // Fetch data from external API const data = await fetch(`YOUR_API`) // Returning the fetched data return { props: { data } }}function SSRPage({ data }) { // Displaying the data to the client return( <div>{data}</div> )}export default SSRPage
In the above example, whenever the user visits the SSR page, the getServerSideProps() function will be called by the server and will return the fully rendered static page.
Use dynamic importsTraditionally, applications load all the components and the CSS required by the application in the initial load. Dynamic import allows you to split your code into small chunks and load them on demand. In the context of web applications, this means that you can import specific components on an as-needed basis. If a user never interacts with a particular component, that component will never be loaded. This can be a huge performance boost, especially on mobile devices. This will also reduce the initial load time and the overall bundle size of the application.
For example, if the user hasn’t logged in, you can lazy load the login component. To use dynamic import, you just need to import the code using an ES2020 dynamic import.
import dynamic from 'next/dynamic'import SimpleButton from '../components/Buttons'const DynamicComponent = dynamic(() => import('../components/LoginButton'))function Program() { return ( <div> <SimpleButton /> <DynamicComponent /> </div> )}export default Program
In the above code, we are using the dynamic component provided by the framework to load our login button dynamically. You can pass a component name, an array of module names, and a function inside the component that will be invoked when the module is loaded.
Cache frequently used contentCaching improves response times and reduces bandwidth usage by serving content from a cache instead of the original source. Next.js has built-in caching so pages load faster. To implement caching in your Next.js application, you can manually set the headers on any API routes that retrieve content and server-side rendered props to use Cache-Control. Below is the implementation for built-in caching.
For API routes:
export default function handler(req, res) { res.setHeader('Cache-Control', 's-maxage=10'); }
For server-side rendering:
export async function getServerSideProps({ req, res }) { res.setHeader( 'Cache-Control', 'public, s-maxage=10, stale-while-revalidate=59' ) return { props: {}, }}
For static files and assets, you don’t have to manually add caching; Next.js automatically adds them.
Remove unused dependenciesMany applications depend on third-party packages. While dependencies are definitely good for your app, they increase its size and loading time. If you are using npm packages in your Next.js application, you should watch for unused dependencies. They take up space in your final bundle and might cause unexpected behaviors in your application.
If you have a small project, you can easily find the unused dependencies and remove them from the package.json file of your Next.js app. But if you have a large project with lots of different dependencies, it may be difficult to find the unused dependencies. In this case, use the depcheck package to find unused dependencies in your project (this package is included with npm).
I recommend that you remove dependencies one by one and restart your application after each removal to ensure that the dependency was truly not needed and that you didn’t break your application.
Optimize images Image optimization involves reducing the size of an image file. Because images are one of the biggest assets weighing down your app’s performance, reducing the size of image files can improve performance. This is a two-step process: 1) resize the image to a smaller size and 2) save it in the correct format (jpeg is better for photos; png is better for graphics).
Next.js provides an inbuilt next/image component that we can use in place of the native <img> component.
import Image from 'next/image'function OptimizedImage() { return ( <> <h1>Next.js Image</h1> <Image src={image_url} alt="Any Text" width={500} height={500} blurDataURL="URL" placeholder="blur" /> )}export default OptimizedImage
Now let’s look at the benefits of the next/image component.
Lazy loading:
Lazy loading is the process of loading a particular chunk of an app only when it is visible in the client viewport. By default, the next/image component lazy loads images, which will decrease the loading time. If you don’t want to lazy load an image, set priority={true} to turn it off.
Placeholder images:
Using the next/image component, you can add a blurred placeholder for any image using the placeholder prop.
Preload images:
If you have multiple images in a page, you can prioritize loading using the next/image component.
Optimize your scriptsIn addition to npm dependencies, many applications use third-party scripts like Google Analytics, Google AdSense, and Bootstrap. These scripts can further slow your Next.js app. Instead of using the default <script> tag, you can use the next/script component of Next.js. It allows you to set the loading priority for third-party scripts.
For example:
import Script from 'next/script'export default function OptimizedScript() { return ( <> <Script id="YOUR_ID" src="URL" onError={(err) => { console.error('Error', err) }} onLoad={() => { // Function to perform after loading the script }} /> )}
By setting the value of the strategy prop in the next/script component, you can use three different script loading approaches:
afterInteractive: The script will be loaded on the client side after the page becomes interactive.beforeInteractive: The script will be loaded on the server side before self-bundled JavaScript is executed.lazyOnload: The script will be loaded after all other resources are loaded.
After applying one of these strategies, check the speed and performance of your app using web performance tools like Google pagespeed. A web performance tool can provide valuable information about application performance, such as:
- The time it takes to get the initial page.
- The time it takes to get the initial resources.
- The number of round trips transmitted.
- The amount of data transferred each trip.
Start building faster Next.js applicationsNext.js has become popular because it allows developers to build powerful JavaScript apps without having to build the back-end infrastructure, but it’s also full of features that can help you improve application performance while doing much of the heavy lifting on the server. Following these best practices will help you take advantage of those features so you can start building faster Next.js applications.
The post Best practices to increase the speed for Next.js apps appeared first on Stack Overflow Blog.
On today’s episode we chat with Anthony Dellavecchia, a developer advocate at Twilio, about some of his favorite tools for boosting productivity and why he went all out building his personal website.
Episode NotesYou can learn more about Anthony here.
His favorite terminal tool at the moment is Warp, which describes itself as “a blazingly fast, Rust-based terminal reimagined from the ground up to work like a modern app.”
His personal website features a live chat function. Sometimes it’s actually Tony, sometimes it’s just a bot.
No lifeboat badge today. We”ll be taking a break for the holidays and will resume episodes in 2023. Until then, enjoy the holidays.
TRANSCRIPT
The post Let’s talk about our favorite terminal tools appeared first on Stack Overflow Blog.
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we’ll see you in 2023. ]
In the movie Free Solo the rock climber Alex Honnold trains to perform a free solo climb of El Capitan, a mountain in Yosemite.
(El Capitan. Photo by Mike Murphy, 2005.)It’s a good movie, but if you haven’t seen it, free solo climbing is when you scale a rock face without ropes, harness, or safety equipment. If you lose your grip and fall, you’ll die. El Capitan, just to rub it in, is 914 meters of vertical rock. Free-climbing it is an incredible endeavor, but Honnold gets it done by committing to one move at a time (this article is about using Git, after all).
Save pointHonnold didn’t just free-climb El Capitan. He trained deliberately towards the goal of free climbing El Capitan.
The documentary shows how he repeatedly climbs El Capitan with safety equipment. He plans a route and climbs it several times. On each of the training ascensions, he’s using ropes, a harness, and various fasteners for the ropes. When he falls during training, he doesn’t fall far, because the rope, harness, and fasteners stop the fall at the last point of fixation.
It’s almost like a video game save point.
In one memorable scene, Honnold considers a jump from one position to another. Hundreds of meters in the air, parallel to a vertical rock face. It’s a truly precarious maneuver. If he fails, he’ll die.
Or, that’s true for the free climb. At first, he rehearses the move using rope and harness. This enables him to perform a potentially fatal jump in relative safety. When it goes wrong, he’s back at where he fixed his rope, and he may try again.
When you’re making large code changes, even migrating to a new implementation, you can create save points to prevent catastrophes. Like Alex Honold, you can fix your code in place to give you a better chance to get to the next successful build.
Precarious editingWhen you edit code, you go from one working state to another, but during the process, the code doesn’t always run or compile.
Consider an interface like this:
public interface IReservationsRepository{ Task Create(Reservation reservation); Task<IReadOnlyCollection<Reservation>> ReadReservations( DateTime dateTime); Task<Reservation?> ReadReservation(Guid id); Task Update(Reservation reservation); Task Delete(Guid id);}
This, as most of the code in this article, is from my book Code That Fits in Your Head. As I describe in the section on the Strangler Fig pattern, at one point I had to add a new method to the interface. The new method should be an overload of the ReadReservations method with this signature:
Task<IReadOnlyCollection<Reservation>> ReadReservations(DateTime min, DateTime max);
Once you start typing that method definition, however, your code no longer works:
Task<IReadOnlyCollection<Reservation>> ReadReservations( DateTime dateTime); T Task<Reservation?> ReadReservation(Guid id);
If you’re editing in Visual Studio, it’ll immediately light up with red squiggly underlines, indicating that the code doesn’t parse.
You have to type the entire method declaration before the red squiggly lines disappear, but even then, the code doesn’t compile. While the interface definition may be syntactically valid, adding the new method broke some other code. The code base contains classes that implement the IReservationsRepository interface, but none of them define the method you just added. The compiler knows this, and complains:
Error CS0535 ‘SqlReservationsRepository’ does not implement interface member ‘IReservationsRepository.ReadReservations(DateTime, DateTime)’
There’s nothing wrong with that. I’m just trying to highlight how editing code involves a transition between two working states:
In Free Solo the entire climb is dangerous, but there’s a particularly perilous maneuver that Alex Honnold has to make because he can’t find a safer route. For most of the climb, he climbs using safer techniques, moving from position to position in small increments, never losing grip or footing as he shifts his center of gravity.
There’s a reason he favors climbing like that. It’s safer.
Micro-commitsYou can’t edit code without temporarily breaking it. What you can do, however, is move in small, deliberate steps. Every time you reach a point where the code compiles and all tests pass: commit the changes to Git.
Tim Ottinger calls this a micro-commit. Not only should you commit every time you have a green bar—you should deliberately move in such a way that the distance between two commits is as short as possible. If you can think of alternative ways to change the code, choose the pathway that promises the smallest steps.
Why make dangerous leaps when you can advance in small, controlled moves?
Git is a wonderful tool for maneuverability. Most people don’t think of it like that. They start programming, and hours later, they may commit to Git in order to push a branch out.
Tim Ottinger doesn’t do that, and neither do I. I use Git tactically.
I’ll walk you through an example.
Adding an interface methodAs described above, I wanted to add a ReadReservations overload to the IReservationsRepository interface. The motivation for that is described in Code That Fits in Your Head, but that’s not the point here. The point is to use Git to move in small increments.
When you add a new method to an existing interface, the code base fails to compile when you have existing classes that implement that interface. How do you deal with that situation? Do you just forge ahead and implement the new method? Or are there alternatives?
Here’s an alternative path that moves in smaller increments.
First, lean on the compiler (as Working Effectively with Legacy Code puts it). The compiler errors tell you which classes lack the new method. In the example code base, it’s SqlReservationsRepository and FakeDatabase. Open one of those code files, but don’t do anything yet. Instead, copy the new ReadReservations method declaration to the clipboard. Then stash the changes:
$ git stash
Saved working directory and index state WIP on tactical-git: [...]
The code is now back in a working state. Now find a good place to add the new method to one of the classes that implement the interface.
SQL implementationI’ll start with the SqlReservationsRepository class. Once I’ve navigated to the line in the file where I want to add the new method, I paste in the method declaration:
`Task<IReadOnlyCollection<Reservation>> ReadReservations(DateTime min, DateTime max);`
That doesn’t compile because the method ends with a semicolon and has no body.
So I make the method public, delete the semicolon, and add curly brackets:
public Task<IReadOnlyCollection<Reservation>> ReadReservations(DateTime min, DateTime max){}
This still doesn’t compile, because the method declaration promises to return a value, but the body is empty.
What’s the shortest way to a working system?
public Task<IReadOnlyCollection<Reservation>> ReadReservations(DateTime min, DateTime max){ throw new NotImplementedException();}
You may not want to commit code that throws NotImplementedException, but this is in a brand-new method that has no callers. The code compiles and all tests pass—of course they do: no existing code changed.
Commit the changes:
$ git add . && git commit[tactical-git 085e3ea] Add ReadReservations overload to SQL repo 1 file changed, 5 insertions(+)
This is a save point. Saving your progress enables you to back out of this work if something else comes up. You don’t have to push that commit anywhere. If you feel icky about that NotImplementedException, take comfort that it exists exclusively on your hard drive.
Moving from the old working state to the new working state took less than a minute.
The natural next step is to implement the new method. You may consider doing this incrementally as well, using TDD as you go, and committing after each green and refactor step (assuming you follow the red-green-refactor checklist).
I’m not going to do that here because I try to keep SqlReservationsRepository a Humble Object. The implementation will turn out to have a cyclomatic complexity of 2. Weighed against how much trouble it is to write and maintain a database integration test, I consider that sufficiently low to forgo adding a test (but if you disagree, nothing prevents you from adding tests in this step).
public async Task<IReadOnlyCollection<Reservation>> ReadReservations(DateTime min, DateTime max){ const string readByRangeSql = @" SELECT [PublicId], [Date], [Name], [Email], [Quantity] FROM [dbo].[Reservations] WHERE @Min <= [Date] AND [Date] <= @Max"; var result = new List<Reservation>(); using var conn = new SqlConnection(ConnectionString); using var cmd = new SqlCommand(readByRangeSql, conn); cmd.Parameters.AddWithValue("@Min", min); cmd.Parameters.AddWithValue("@Max", max); await conn.OpenAsync().ConfigureAwait(false); using var rdr = await cmd.ExecuteReaderAsync().ConfigureAwait(false); while (await rdr.ReadAsync().ConfigureAwait(false)) result.Add( new Reservation( (Guid)rdr["PublicId"], (DateTime)rdr["Date"], new Email((string)rdr["Email"]), new Name((string)rdr["Name"]), (int)rdr["Quantity"])); return result.AsReadOnly();}
Granted, this takes more than a minute to write, but if you’ve done this kind of thing before, it probably takes less than ten—particularly if you’ve already figured the SELECT statement out on beforehand, perhaps by experimenting with a query editor.
Once again, the code compiles and all tests pass. Commit:
$ git add . && git commit[tactical-git 6f1e07e] Implement ReadReservations overload in SQL repo 1 file changed, 25 insertions(+), 2 deletions(-)
Status so far: We’re two commits in, and all code works. The time spent coding between each commit has been short.
Fake implementationThe other class that implements IReservationsRepository is called FakeDatabase. It’s a Fake Object (a kind of Test Double) that exists only to support automated testing.
The process for implementing the new method is exactly the same as for SqlReservationsRepository. First, add the method:
public Task<IReadOnlyCollection<Reservation>> ReadReservations(DateTime min, DateTime max){ throw new NotImplementedException();}
The code compiles and all tests pass. Commit:
$ git add . && git commit[tactical-git c5d3fba] Add ReadReservations overload to FakeDatabase 1 file changed, 5 insertions(+)
Then add the implementation:
public Task<IReadOnlyCollection<Reservation>> ReadReservations(DateTime min, DateTime max){ return Task.FromResult<IReadOnlyCollection<Reservation>>( this.Where(r => min <= r.At && r.At <= max).ToList());}
The code compiles and all tests pass. Commit:
$ git add . && git commit[tactical-git e258575] Implement FakeDatabase.ReadReservations overload 1 file changed, 2 insertions(+), 1 deletion(-)
Each of these commits represent only a few minutes of programming time; that’s the whole point. By committing often, you have granular save points you can retreat to if things start to go wrong.
Now change the interfaceKeep in mind that we’ve been adding the methods in anticipation that the IReservationsRepository interface will change. It hasn’t changed yet, remember. I stashed that edit.
The new method is now in place everywhere it needs to be in place: both on SqlReservationsRepository and FakeDatabase.
Now pop the stash:
$ git stash popOn branch tactical-gitChanges not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: Restaurant.RestApi/IReservationsRepository.csno changes added to commit (use "git add" and/or "git commit -a")Dropped refs/stash@{0} (4703ba9e2bca72aeafa11f859577b478ff406ff9)
This re-adds the ReadReservations method overload to the interface. When I first tried to do this, the code didn’t compile because the classes that implement the interface didn’t have that method.
Now, on the other hand, the code immediately compiles and all tests pass. Commit.
$ git add . && git commit[tactical-git de440df] Add ReadReservations overload to repo interface 1 file changed, 2 insertions(+)
We’re done. By a tactical application of git stash, it was possible to partition what looked like one long, unsafe maneuver into five smaller, safer steps.
Tactical GitSomeone once, in passing, mentioned that one should never be more than five minutes away from a commit. That’s the same kind of idea. When you begin editing code, do yourself the favor of moving in such a way that you can get to a new working state in five minutes.
This doesn’t mean that you have to commit every five minutes. It’s okay to take time to think. Sometimes, I go for a run, or go grocery shopping, to allow my brain to chew on a problem. Sometimes, I just sit and look at the code without typing anything. And sometimes, I start editing the code without a good plan, and that’s okay, too… Often, by dawdling with the code, inspiration comes to me.
When that happens, the code may be in some inconsistent state. Perhaps it compiles; perhaps it doesn’t. It’s okay. I can always reset to my latest save point. Often, I reset by stashing the results of my half-baked experimentation. That way, I don’t throw anything away that may turn out to be valuable, but I still get to start with a clean slate.
git stash is probably the command I use the most for increased maneuverability. After that, being able to move between branches locally is also useful. Sometimes, I do a quick-and-dirty prototype in one branch. Once I feel that I understand the direction in which I must go, I commit to that branch, reset my work to a more proper commit, make a new branch and do the work again, but now with tests or other things that I skipped during the prototype.
Being able to stash changes is also great when you discover that the code you’re writing right now needs something else to be in place (e.g. a helper method that doesn’t yet exist). Stash the changes, add the thing you just learned about, commit that, and the pop the stash. Subsection 11.1.3 Separate Refactoring of Test and Production Code in Code That Fits in Your Head contains an example of that.
I also use git rebase a lot. While I’m no fan of squashing commits, I’ve no compunction about reordering commits on my local Git branches. As long as I haven’t shared the commits with the world, rewriting history can be beneficial.
Git enables you to experiment, to try out one direction, and to back out if the direction begins to look like a dead end. Just stash or commit your changes, move back to a previous save point and try an alternative direction. Keep in mind that you can leave as many incomplete branches on your hard drive as you like. You don’t have to push them anywhere.
That’s what I consider tactical use of Git. It’s maneuvers you perform to be productive in the small. The artifacts of these moves remain on your local hard drive, unless you explicitly choose to share them with others.
Conclusion Git is a tool with more potential than most people realize. Usually, programmers use it to synchronize their work with others. Thus, they use it only when they feel the need to do that. That’s git push and git pull.
While that’s a useful and essential feature of Git, if that’s all you do, you might as well use a centralized source control system.
The value of Git is the tactical advantage it also provides. You can use it to experiment, make mistakes, flail, and struggle on your local machine, and at any time, you can just reset if things get too hard.
In this article, you saw an example of adding an interface method, only to realize that this involves more work than you may have initially thought. Instead of just pushing through on an ill-planned unsafe maneuver that has no clear end, just back out by stashing the changes so far. Then move deliberately in smaller steps and finally pop the stash.
Just like a rock climber like Alex Honnold trains with ropes and harness, Git enables you to proceed in small steps with fallback options. Use it to your advantage.
The post Use Git tactically appeared first on Stack Overflow Blog.
It’s that time of year again. We’re heading towards the end with a new beginning around the corner. Something we’ll probably remember about December 2022 is all the interesting tech that’s catching on. On today’s podcast, Ben Popper and Matt Kiernander take a brain-break from their work lives at Stack Overflow to reflect on it all…and whether or not we it.
Episode notes:
Ben asks Matt to explain Mastodon to him like he’s five. Matt says the experience feels a lot like…LinkedIn?
Matt explains that he took social media apps off his phone for a while…just to chill out. (Ed. note, they’re already back on.)
We cover the latest AI to emerge that can write essays, jokes, and yes, some code.
While everyone’s confused about the state of social media and AI chat, physicists have created a wormhole using a quantum computer. (Though it may have been a publicity stunt.)
Follow Ben and Matt.
Shout out to Lifeboat Badge winner ralf htp for their answer to the question ‘how to listen for and react to Ace Editor change events.’ Your answer has helped more than 20,000+ people, so rock on.
The post An honest end-of-year rundown (Ep. 518) appeared first on Stack Overflow Blog.
The last year has been a time of re-evaluation and opportunity for technology professionals. The rise of remote work, the Great Resignation/Reshuffle, and “quiet quitting” all demonstrate how fast the workplace is changing, especially amidst recent economic uncertainty and layoffs in the tech sector. In October 2022, we surveyed 2,600+ tech professionals to learn more about the wants, needs, and expectations of developers when it comes to the companies they work for and the work they are doing worldwide.
Most technologists would take a new job, especially young tech talentWhile not everyone is actively searching for a new job, most are open to considering new roles. 74% of technologists are actively looking for a job now or are open to new opportunities, which is consistent with last year’s survey (also 74%).
Younger developers are more likely to be actively looking for their next role. We see the highest percentage of active job seekers with the 20-24 year-old cohort (27%), 21% for 25-34 year olds, 17% for 35-44 year olds, and only 12% for 45-54 year olds. Additionally, the percentage of young developers actively searching for their next role increased nine points year over year (22% in 2022 versus 13% in 2021). This rise in young job applicants, combined with two-thirds of 20-24 year olds indicating they were either working in their first job or have not started their professional career yet, suggests a wave of new tech talent is ready to enter the workforce. What’s more, the 20-24 age group is succeeding at finding new jobs: 27% have obtained as many roles as the average person in the 25-34 age group (3 or 4 professional jobs under their belt). Younger people are accepting new jobs more frequently, and the data shows they are hungry for more.
Money can’t buy you love, but it’s a good reason to job hopThere are many reasons developers may be actively looking or open to new job opportunities, and there can also be compelling reasons to stay in their current role (cue “Should I Stay or Should I Go” by The Clash). Over half of respondents agreed a better salary is still the largest motivator when considering a new opportunity (54%). Our data also shows that experienced developers are more concerned with better pay than growth and leadership opportunities (57% vs. 37% of 35-44 year olds and 62% vs. 38% of 25-34 year olds). Across different team roles, better salary is a top motivator, as well (61% for individual contributors and 58% of people managers).
While salary remains a primary motivator for developers in the United Kingdom, European Union, and Latin America, the desire to work with new technologies came in second as a reason to leave a role. In fact, the number of Latin American respondents ranking working with new technologies as a motivator increased from 44% to 59%, while less respondents from the EU and UK listed new technology as a motivator, dropping from 55% in 2021 to 43% this year. Additionally, 38% of EU/UK respondents are not interested in new job opportunities this year, which is an increase from last year (27%). This uptick could be related to the economic downturn much of the world and Europe is experiencing and may indicate a growing desire on the part of European workers for stability and familiarity.
Developers do their (job) researchFor those looking, finding new job opportunities and researching potential employers can be a daunting task. With more jobs and job-seekers than ever before, how are companies standing out amongst the competition for tech talent?
Developers most frequently discover companies they may want to work for in the future through word of mouth, with 46% of all respondents using their personal network. Across all age groups and among independent contributors vs. people managers, this number is consistently high. For the cohort with the highest ratio of job seekers—25-34 year olds—the most popular resources to find out about future employers behind their personal network are company reviews (41%), other media (34%), and company media (33%).
Finding a job is not a linear process, so it makes sense that job seekers check review sites (like Glassdoor or Blind) because they are evaluating a company’s reputation before they put effort into applications and cover letters. When the rubber hits the road and it’s time to start submitting applications, all age groups highly rate using company reviews from third-party sites (55%), which is higher than those who did so while considering future employers (34%).
While employers would be wise to note these trends amongst job-seekers, let’s not forget the interview process. Respondents revealed that many stop pursuing a job when they get another offer (31%), when there is a lengthy hiring process (25%), or the interview is disorganized (34%). 19% of respondents cited not being able to find enough information about what it is like to work for a company as their reason to stop pursuing a job, and our highly-active 25-34 age group cited this reason most (22%). Perhaps the reason why review sites are so popular for researching an employer when actively searching is due to the fact that the information applicants want is hard to find.
What keeps tech professionals from looking?We’ve looked a lot at the technologists who are considering leaving their jobs—what factors convince them to stay in their current role? Flexibility (58%), salary (54%), and learning opportunities (54%) prevent developers from checking job boards. Not surprisingly these qualities are all rated higher by independent contributors than people managers, with people managers valuing leadership opportunities moreso (37% vs. 27%). Regionally, respondents in the USA & Canada rate salary the highest (62%), and EU/UK respondents rate flexibility the highest (68%) in their current jobs but rate salary the highest for new jobs (72%) among all cohorts.
Respondents cite a focus on the developer experience (42%), the product or solution the company is selling (35%), and learning from individuals outside of their team (34%) as the top factors that make a company more appealing to work for now or in the future. The 25-34 year old age group, whom we know are more likely to be looking for new roles, rate developer experience (47%) and the product the company is selling (39%) higher than their older and younger peers. This is particularly noteworthy given that this group turns to company-owned or news media to research employers, supporting the idea that attracting talent goes beyond a job posting and into deeper questions of the business and employee experience as a whole.
We specifically asked our users about their experience at work. More respondents (53%) agree/strongly agree that “waiting on answers to questions often causes interruptions and disrupts my workflow.” Most disagree that knowledge silos are preventing them from getting their work done (26%) but also agree that they often answer the same questions repeatedly (46%). Interruptions and waiting for answers add up over time, creating a dissatisfying work experience for developers.
Complementing the benefits and perks of a job, technologists say starting/ending the day at a precise time (46%), being expected to work from an office (44%), and lacking the resources to be confident in their work (43%) are the top drawbacks from their current roles. Flexibility and lack thereof has been a consistent theme in this survey’s results, and a lack of resources and accurate answers is a notable addition to the tools developers cite as important.
The workplace continues to change with the influx of new and experienced tech talent and companies adjusting to trends we’ve noted here about on-the-job experience. Young tech talent, in particular, will be reshaping the way companies attract and retain employees in the new year. Organizations will need to focus on how to adequately inform developers about their products and workplace culture not only in the job description but in the ever-evolving technology conversation happening in the news, on review sites and in other media.
The post Job insights from the tech community: The latest survey results from Stack Overflow Knows appeared first on Stack Overflow Blog.
Another year is coming to an end, making it a time to reflect on the triumphs we celebrated and tribulations we faced. It’s been yet another rough year for many around the world, but a new year is upon us, bringing with it the hopes and dreams of a better future for everyone.
To help kick off the new year with a bit of joy, we’re thrilled to announce it’s time for our annual Winter Bash. Winter Bash (or Summer Bash, for those of you in the upside down) is a fun end-of-year event that’s been a community tradition for over a decade. From December 14 to January 4, we’ll reward you for participating in the community. When you ask, answer, vote, edit, and chat, you’ll earn hats or other accessories for your avatar.
First, we’d like to introduce this year’s Winter Bash 2022 sponsor, Splunk. Splunk delivers full-stack visibility across infrastructure, applications, and business services across any environment in real time. Thanks, Splunk, for the support!
Although we’ve kept the name Winter Bash for our yearly event, we haven’t forgotten our fellow technologists in the southern hemisphere, who are enjoying warmer weather. Just use the “Winter/Summer” toggle on the bottom left of the landing page to change the season to Summer!
The team has been hard at work this year to bring you a smorgasbord of hats to ensure your profile is sporting the latest in Winter Bash fashion. We’ve reimagined some past favorites and added some delightful new hats. But it’s not just the hats themselves we’ve revived and re-envisioned… we’ve done the same with the triggers and have some new secrets waiting to be discovered.
How will you discover those secrets and add hats to your collection? It’s easy! Do what you already do best: participate on the site by asking good questions, providing good answers, voting, commenting, and exploring all Stack Exchange sites! You may be surprised at all the nooks and crannies you discover.
When you complete a challenge, you’re awarded its respective hat. Hats can be worn on your profile image by using our hat tool (details below).
Winter Bash 2022 runs from Wednesday, December 14th, 21:00 UTC to Wednesday, January 4th, 21:00 UTC.
Here’s a step-by-step guide to getting and wearing your first hat:
-
Be active on Stack Exchange! Post answers, comments, or questions. If you just want to play around with hats, find a good post and upvote it—that’ll get you your first hat
-
Click on any hat in the snowflake menu to go to your wardrobe. (You can also access this by going to your profile and clicking the hat icon!)
-
Select the hat you want, use the handles to customize it to your liking, and save it to show off across the network.
If you want to learn more, please visit the Winter Bash FAQ page!
Happy Winter Bashing to the Stack Exchange community. We wish you luck in your adventures!
P.S. If Winter Bash isn’t your cup of tea this year, as always, Winter Bash has a prominent opt-out option. We understand you may prefer to keep your Stack Overflow and Stack Exchange experience free of distractions. You can opt out of Winter Bash by choosing “No hats for me, please” from the Winter Bash menu at the top navigation toolbar.
The post Hat’s out of the bag! Join us for Winter/Summer Bash 2022! appeared first on Stack Overflow Blog.
We sit down for a chat with Steve Sewell, CEO at Builder.io, to talk about the experiences that inspired him to craft a visual CMS and start a company around it. Along with coding and running a company, Steve has become a popular content creator, and he explains why he believes short form TikToks are a great format for teaching people to program.
Episode NotesSteve was working as an engineering manager at ShopStyle and found that an increasing amount of his team’s time was spent working on custom requests from departments like marketing and sales. They tried headless CMS but the data and components couldn’t keep up with ever evolving needs evolving needs. They wanted a drag and drop system connected to their code, data, and components.
This pain point inspired him strike out on his own to create a new product. The vision was a tool that would allow colleagues from across a company to make changes to web pages without requesting dev time, but would also ensure that any changes made would be up to the standards of the design department and not introduce errors that engineering would then have to fix.
Hence, the company’s pitch for a plug & play system that integrates with your existing sites & apps. It relies on a few key ideas:
- API-based infrastructure that is native to your tech stack
- Works with any frontend or backend
- Build with your own data, like product catalogs or customer data platforms, to create rich, dynamic experiences
You can check it out for yourself over at Builder.io.
Follow Steve on Twitter and TikTok where he breaks down websites and effects he finds interesting.
Congrats to phoenisx for being awarded the Necromaner badge after answering the question: Property ‘share’ does not exist on type ‘Navigator”?
The post Taking drag and drop tech stacks with Builder.io’s Steve Sewell appeared first on Stack Overflow Blog.
SPONSORED BY COMMERCE LAYERAround the world, billions of people can sell their wares online, in part thanks to solutions that handle the complexities of securely and reliably managing transactions. Businesses, large and small, can sell directly to customers. But a lot of these ecommerce services provide a heavier surface than many need by managing product catalogs and requiring inflexible interfaces.
On this sponsored podcast episode, Ben and Ryan talk with Filippo Conforti, co-founder of Commerce Layer, an API-only ecommerce platform that focuses on the transaction engine. We talk about his early years building ecommerce at Italian luxury brands, the importance of front-ends (and micro-frontends) to ecom, and how milliseconds of page load speed can cost millions.
Episode notesConforti was the first Gucci employee on their ecommerce team, so he got to experience life in a fast-moving startup within a big brand. When he left five years later, the team had grown to around 100 people.
The ecommerce space is crowded—one of Commerce Layer’s recent clients evaluated around 40 other platforms—but Conforti thinks Commerce Layer stands out by making any web page a shoppable experience.
Conforti thinks composable commerce back ends that neglect the front end neutralize the benefits. Commerce Layer provides micro-frontends—standard web components that you can inject into any web page to create shoppable experiences.
Getting your ecommerce platform as close to your customer makes real monetary difference.A report from Deloitte finds that a 100ms response time increase on mobile translates to an 8% increase in the conversion rate.
Thanks to Mitch, today’s Lifeboat badge winner, for their answer to the question, How to get all weekends within a date range in C#?
The post The next step in ecommerce? Replatform with APIs and micro frontends appeared first on Stack Overflow Blog.
Welcome to ISSUE #155 of The Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams. This week: we’re talking about dynamic application security testing, the quest to cure the common cold, and the merits/limitations of single-page apps.
From the blogComparing when to use gRPC vs GraphQL stackoverflow.blog
We dig into two of the most popular API protocols to see where they work best.
Continuous delivery, meet continuous security stackoverflow.blog
Dynamic application security testing (DAST) can help catch security flaws in your code. And it can do it automatically in your build process.
From Twitter Bootstrap to VP of Engineering at Patreon, a chat with Utkarsh Srivastava (Ep. 514) stackoverflow.blog
Patreon’s VP of Eng talks product roadmaps, deployment best practices, and UX philosophies.
2022 Global DevSecOps Survey shows security as a top concern promotion
Download and share the entire report, “The 2022 DevSecOps Survey: Thriving in an Insecure World”, to dig deeper into security automation, AI, information overload, compliance, faster releases, and real world challenges.
Interesting questionsRejecting a job offer within the same department that really doesn’t fit me well—do I explain myself? workplace.stackexchange.com
“I would generally recommend not elaborating: a Closed Mouth gathers no Foot.”
Should we auto-select a new default payment method when the current default expired? ux.stackexchange.com
Don’t make financial decisions for users.
Why haven’t we cured the common cold yet? biology.stackexchange.com
Well, for starters, which of the 200 or so viruses that cause the common cold are we talking about here?
Can we determine for sure if the Sun revolves around the Earth? skeptics.stackexchange.com
General relativity states that all frames of reference are equally valid, not that one local frame is the only right answer.
Links from around the webEverything I wish I knew when learning C tmewett.com
Though it’s an older language, C is still alive and well and is behind a lot of the software you know and love. Here’s some useful tips on how to learn it.
Why HTML is a strategic dead end for business transactions and eCommerce jimgray.azurewebsites.net
1999 is calling to let us know HTML is “dead” and “increasingly dysfunctional!“
On the merits and limitations of React and single-page apps www.youtube.com
It’s a long debate that may not change your mind, but it’s good to understand the pros and cons of SPAs.
Physicists create a holographic wormhole using a quantum computer www.quantamagazine.org
This sounds like science fiction, but read on to have your mind blown!
A blast from the past: The most successful developers share more than they take.
The post The Overflow #155: Continuous security appeared first on Stack Overflow Blog.
On today’s episode, we’re airing a conversation recorded at the Next.JS conference. We chat with Lee Robinson, VP of Developer Experience at Vercel about the company’s vision for evolving from Webpack to Turbopack, helping customers who are cautious about migrating to a new tool, changes happening with React server components, and much more.
EPISODE NOTES
Webpack has been king for several years. Vercel wants folks to embrace Turbopack, but their claims about speed raised a lot of backlash after it was first announced. Lee explains why he thinks the Rust-based approach will ultimately be a big benefit to developers and how organizations who are deeply ingrained with existing tools can safely and incrementally migrate to what is, for now, a very Alpha and experimental release.
We go over the routing and rendering updates in Next.JS 13, exploring where it might offer developers more flexibility and the ability to use React server components to ship less, maybe a lot less, JavaScript. As Lee says in the episode:
“So to your point about wanting to ship less JavaScript, that was a kinda fundamental architectural decision of where we headed with the app directory. And the core of this is because it’s built on React server components.
The key thing with React server components is that as your application grows in size from one component to a hundred thousand components, the amount of client-side JavaScript you send can be exactly the same. It can be constant because you can render every single component on the server.
And that’s a lot different from the world of React applications today, where every new component you add for data fetching or just putting some HTML on the screen also adds additional client-side JavaScript.
So this is kind of inverting the default, back from the client to be server first. Now, of course, we still love client-side interactivity that React provides making really interactive and rich UI experiences, but the default for data fetching or just getting HTML to the browser happens from the server, and that’s gonna help us reduce the amount of JavaScript.”
You can learn more about Lee on his website, LinkedIn, and Twitter.
TRANSCRIPT
The post Ready to optimize your JavaScript with Rust? appeared first on Stack Overflow Blog.
SPONSORED BY PLURALSIGHTLearning is a critical part of our work as engineers. The problems we solve are technical, complex, and ambiguous, but the tools at our disposal change and improve regularly. The code we develop requires time for ideation and advanced skills for implementation. Most days we are learning on the fly and experimenting as we go. Because our time is in such high demand, we rarely have an evening or a weekend to squeeze in professional development so our skills remain relevant.
Meanwhile, we’re navigating pressures from engineering departments. Company leadership wants us to have up-to-date skillsets and work with the latest tech. However, they may not allow us to learn on company time or are struggling to provide pathways for meaningful learning. Yes, we’ve heard phrases like, “Friday afternoons will be set aside for learning.” But those Friday afternoons are often spent wrapping up work to complete a sprint.
Even if the engineering organization offers a rich learning platform, the chances of getting through a course—while also keeping up with work, family, and other obligations—are pretty low. We’re left with the difficult choice between learning something new in our spare time or being with our friends and family—who we might have ditched last weekend because we had to work.
Despite full calendars and heavy demands on our personal time, there are ways to make time for learning. It’s tempting to believe that we need an hours-long block of time to learn anything, but that’s not the case. Learning in small increments is better and more realistic. Plus, it’s an important habit to develop for a long-term career in engineering. Like anything else worth doing, it isn’t easy and you have to be creative.
Determine what to learn and how you’ll learn itEarlier in our careers, it may have been easier to pull all-nighters and spend a weekend learning C# (or C++, or C, or whatever). But the older we get, the more responsibilities we have and the more precious our time becomes. Suddenly it feels like learning is a chore because it’s so difficult to fit in with everything else.
Limited learning time means you have to really hone in on what to learn. That’s why knowledge needs to be distilled into what’s most important. When you can finally carve out the time to learn, you don’t want to waste it.
Here’s a few tips on how to maximize your learning time:
Don’t confuse the learning with the accomplishment. When people want to acquire new skills, they’ll sometimes resent the learning activity itself. Common blockers include feeling like the material is slowing them down or loaded with unnecessary prerequisites. However, activities such as proving concepts, understanding dependencies, and lab activities are vital for true skill-building. Merely completing a course or getting a certificate isn’t learning if you can’t recall or apply the material a few months later; it’s harmful to prioritize the accomplishment over the learning itself. Learning isn’t a singular event; it requires specific tactics that take time, repetition, and subconscious processing..
Look at learning as a key component of your career. Take a step back and look at learning as part of your journey, not just something you do for a job, project, or task. Learning is the primary skill of an engineer, so don’t hold yourself back by making it a low priority. It’s common for engineers who stop learning to end up stagnating in their careers and running into blind spots. They don’t move forward with technology and miss out on opportunities. In physical engineering, the laws are unlikely to change over time (though our understanding of them might). But in technology, the foundations on which we engineer are constantly changing with higher-level abstractions, improved programming languages and frameworks, and new practices. Learning is how we push through and evolve, so do what you can to find the motivation to learn sooner than later.
Hone your learning plan by building a taxonomyLet’s say you’re a front end JavaScript developer who wants to learn more about asynchronous API calls. A taxonomy will help you to determine the order of importance of what to learn. Consider the example of async API calls, which are part of communication in browsers. When learning about this concept, the phrases, “APIs,” “communication,” and “browsers” should anchor your learning taxonomy to keep you on track and reduce potential distraction. The more precise the taxonomy gets, the more you can narrow your educational path and learn only what is relevant or interesting.
Learning for the long termKnowing what you want to learn is a great way to grow, but investing in your unknown unknowns, are what support an engineer’s ability to evolve as tech changes. Ignoring unknown unknowns is how engineers develop tunnel vision, causing them to lose perspective of bigger problems and become frustrated as a result.
It’s understandable to get defensive about your engineering weaknesses. If you’re already working effectively, why waste time learning about anything new? Your tasks needed to be done yesterday, there’s pressure coming from management, and the business is still trying to navigate market conditions. How can you think about learning for tomorrow when you haven’t completely solved yesterday’s problems?
We recommend staying open-minded to learning, even when it seems like there’s no opportunity or reason to do so. Look into alternative ways of working and see what new tech is on the horizon. Ask yourself why new concepts are on the rise. The tools or methods might be better—or maybe they’re just different. Staying focused on yesterday’s problems might put you on the wrong side of history.
Develop a daily habit of addressing your unknown unknowns. It will make working in your role a whole lot more sustainable. Even a cursory understanding of alternatives and forward-thinking options can give you agility for a long-term career. You’ll avoid developing a reputation as “the legacy problem solver.” You’re also much less likely to burn out when you have a variety of new and old problems to solve. Strategically working through the gaps in your understanding will keep your daily tasks feeling fresh.
Establishing a daily habit of open-minded learning will put you on a path toward sustainable long-term evolution. When done in small time increments, sustainable learning will help you throughout the day. For example, if you encounter something new in the morning, the idea may continue to bounce around in your head in the shower or while you’re commuting. Having that idea percolate is a strong part of the learning process.
The challenge of bite-sized learning is that the ideas don’t always connect. You might not remember what you learned in the morning, so it’s hard to come up with next steps or questions. That’s where learning becomes more of a practice or continuous habit. Learning more often and regularly moves us forward. This applies to both individuals and organizations.
Developing a learning cultureIt’s increasingly important for organizations to support their employees’ professional growth goals. By promoting learning as part of an organizational mindset and culture, leaders can help their teams exercise their learning muscles.
Think about it like a professional basketball player. If a player’s jump shot is weak, they work on it. But the coach doesn’t say, “We don’t have time for you to run on the treadmill! Just go work on your jump shot.” Treadmill time is just as important as the jump shot because it’s an investment in the future. Unfortunately, some organizations don’t view learning as an investment, and they’ll tell their engineers to get off the treadmill and only work on the jump shot. It’s challenging. However, there is no shortage of organizations that are enthusiastic about building a learning culture. The downside: company leadership often doesn’t know how.
Some companies try to hire their way into new skills, thinking fresh perspectives may change the culture. That strategy usually doesn’t pan out. Other companies can’t overcome their fear of training employees because the employee will inevitably leave. Leaders like Aaron Skonnard, CEO of Pluralsight, are encouraging companies to change from “consumers of talent” to “creators of talent.” This idea is a healthy step forward, but we need practical, sustainable ways of making that happen. Let’s explore two methods that reliably work: feedback loops and grassroots efforts.
Feedback loops are critical for a sustainable learning cultureAs we learn, we need to understand whether what we’re learning is aligned with individual and organizational goals. Learning as an engineer needs to be a shared value between employers and the individuals who work for them. Like any other discipline, however, learning needs to be focused and intentional.
There’s a practical reality of someone getting distracted and learning the wrong thing or learning something that’s not goal-aligned. This can be frustrating. Feedback loops, either from managers, peers, or subject experts can ensure that you are spending your time on subjects valuable to both your team and your overall skill goals. Organizations that value learning understand that it’s as much a discipline and skill as anything else, and it makes a huge difference for employee satisfaction.
Stack Overflow found that 56% of developers consider opportunities to learn when thinking about staying at their job. People want roles where they are supported in their learning journeys; if their current employer doesn’t give them that support, they may look for another job. They know it’s important for their careers, so they want to go where they can learn. When an organization is able to sense these indicators, they can respond, increase employee retention, and therefore increase sustainability and learn from their blind spots.
Grassroots learning culture developmentThe relationship between employees and organizations goes two ways. When it comes to building a “learning culture,” our default response might be “that’s the company’s responsibility, not the individual’s.” However, employees have much more control than they think. They can form communities of practice and centers of excellence, cross-functional learning groups, or even do something as simple as a lunch-and-learn. Here are some more ideas.
Build learning time into your estimates. When estimating the effort for a project task, we usually think about “how many hours will this take to complete?” Instead, we should think, “how many hours of learning and work will this take to complete?” We recommend that engineers mindfully build learning time into their estimates so there’s no competition for time in their sprints. You don’t have to be dishonest by increasing an estimate. Just say, “I think it’ll take eight hours, but I’ll need two additional hours of research time.”
Start a book club. Jeremy (co-author of this piece) was a consultant in a former life and helped implement a book club at several companies. One company was bewildered at the mere suggestion. “A book club?! Are you crazy?” They did it anyway, and the response was fantastic. They’re still doing the book club four years later. They started with the classic computer science book, Design Patterns: Elements of Reusable Object-Oriented Software by the so-called Gang of Four, assigned everyone a chapter, and shared what they learned with their team. Book clubs sound old-fashioned, but they still work very well.
Have software demos and show off. Demos are a great opportunity to show off new work and ideas to a broader audience. Stack Overflow, for example, has monthly demos from the PDEC team (Product, Development, Engineering, and Community). The demonstrator gets praise and that feels good, but the demo also encourages other people to demo their work. They start thinking, “Wouldn’t it be awesome if we did that too?” Engineering teams of any size can easily set up frequent demo hours to provide teams the opportunity to share. This creates a positive feedback loop and the potential for cross-pollination of ideas.
Companies want to learn and they need your helpMore organizations than ever want a learning culture that supports employees and facilitates the adoption of tomorrow’s tech. They are budgeting for it and trying to figure it out, but it’s not their core competence and they don’t know how to encourage people to learn. Managers and leaders frequently want their teams to learn, grow, and succeed. Sometimes they’ll find solutions that people don’t want, so it’s our job as engineers to provide specific requests for growth. Going to our managers with vague requests like “we need to learn more” won’t give them much to work with.
Pluralsight has spent a lot of time understanding how to make learning possible at organizations of every size. One of the ways we stand out is not having 10,000 courses or 100 courses just on ReactJS. That’s confusing and users shouldn’t have to figure out how to learn as they learn. We have taxonomies, quick learning sessions you can fit in your day, learning paths, skill paths, and certification paths—all of which are optional—to give engineers line of sight on a learning goal. You know that as soon as you take five courses, you can get things done in React. (Or you can take a la carte classes all day long.) We give people the chance to test their progress as they go. And by popular request, we now have in-depth lab exercises.
The more you learn, the better your future choices will be. You’ll learn what’s important to you about learning, have discernment as you learn, and learn better over time. We are here to help engineers and their employers develop a lifetime practice of learning.
The post How to make time for learning in tech appeared first on Stack Overflow Blog.
From the fastest-growing startups to the largest enterprises, developers at organizations around the world turn to Amazon Web Services (AWS) to become more agile and innovate faster. The company offers more than 200 fully-featured services from global data centers and was named a leader in the Gartner 2022 Magic Quadrant for Cloud Infrastructure and Platform Services (CIPS).
Today, we are pleased to share that AWS has joined CollectivesTM on Stack Overflow. Collectives are dedicated tag-defined spaces on Stack Overflow where you can find relevant information from subject matter experts on specific platforms, ecosystems, or topics.
Sixty-two percent of respondents in our 2022 Stack Overflow Developer Survey told us they spend more than 30 minutes a day searching for answers or solutions to problems. This is time that could be spent learning or building. Through its Collective, AWS wants to engage with and support developers where they are most active, help simplify learning, and enable interactions among community members who are sharing solutions on Stack Overflow for hard-to-solve technical problems.
“Our aim isn’t just to meet developers where they’re at, but to take them where they’re going by supplying a single place to look for AWS answers on the platform they already know and trust.” says Emily Freeman, head of community engagement at AWS.
“We believe bringing together communities of practitioners, from beginners to experts, to share their knowledge and learn from each other is core to the technology experience,” says Stack Overflow Chief Product Officer Teresa Dietrich. “We are so excited to have AWS support and empower the community of users on Stack Overflow.”
Users who join the AWS Collective will find more than 230,000+ questions and other relevant content using 130+ tags, such as amazon-web-services, amazon-ec2, amazon-s3. These curated, centralized community resources will help users more easily discover the most up-to-date answers including those recommended or written by AWS subject matter experts, technical articles such as how-to guides, and Bulletins for upcoming events and releases. Members can keep tabs on where they rank on the leaderboard and be promoted to Recognized Member status based on their contributions. By bringing knowledge and users together, the AWS Collective will help the community continue to learn, share, and grow.
To learn more about Collectives, visit https://stackoverflow.com/collectives.
To join AWS’s Collective, visit https://stackoverflow.com/collectives/aws
To review the 2022 Stack Overflow Developer Survey, visit https://survey.stackoverflow.co/2022
The post AWS joins Collectives™ on Stack Overflow appeared first on Stack Overflow Blog.
On today’s episode we chat with Andrew McFarlane, CTO at Validation Cloud. His company focuses on building out infrastructure for blockchains, supporting the nodes and validators that keep everything running and verified. McFarlane explains where popular languages like Rust and Go can be found in the Web3 world and why he thinks a crypto winter is the best time to be building fundamental tech.
Episode NotesYou can learn more about Andrew, from building out a telco in Canada to cyber security at Deloitte, on his LinkedIn.
Validation Cloud bills itself as the world’s fastest node infrastructure and cites networks like Bitcoin, Ethereum, and Binance as clients it supports. Learn more at the company’s website here.
Shout out to this week’s lifeboat badge winner, Derek, for helping answer the question: How do you open the file chooser in an Android app using Kotlin?
The post The blockchain tech to build in a crypto winter appeared first on Stack Overflow Blog.
There’s been a lot of high profile layoffs in the news lately: Layoffs.fyi shows over 140,000 layoff across nearly 900 companies in 2022. Whether this is a general economic downturn, dot com bust V3, or a correction after an aggressive overreach during the pandemic remains to be seen. What is clear is plenty of people are finding themselves suddenly jobless and will be wondering what to do.
When you get laid off, you think, I used to know what I was going to be doing until my next vacation. Now I don’t know what I’m doing tomorrow.
Ben Matthews, Stack Overflow Director of Engineering
When the first dot com bubble burst, I was in the same position. I had taken a role at a startup creating online programming courses. The office space was gorgeous, the work was engaging, and the coffee was top quality. One day, the coffee was replaced by a lesser brand. Soon after, everyone was laid off. This was in early 2001. It took me nearly five years to get back into the tech world. But I recovered and found a career path that was even more rewarding.
While the tech industry has gone through a few shifts since I’ve entered the work force, some of the people getting laid off haven’t been through this before. Even if you have been through it, it’s helpful to have a toolkit of strategies and advice to get your through it if it happens to you.
If you’ve just been laid off…When you lose a job during a round of layoffs, you lose a significant part of your life. You spend eight hours (or more) every day interacting with the same people, pursuing the same goal, then suddenly, that stops. Allow yourself some time to grieve. Your friends may not know how to deal with grief and may say the wrong things. Forgive them.
It felt like a betrayal because it was just outta nowhere. There were no signs. Even though I would advise people, you can’t take this personally, it still felt that way because these even though I may not have had the strongest relationship with management—we didn’t see eye to eye—it did feel like there was a lack of respect on top of it. I was just four months away from getting my pension with the company.
Ben Matthews, Stack Overflow Director of Engineering
You might feel a little vulnerable and precarious after a layoff; that’s perfectly normal. Depending on what you did to get to this job—move to a new city, invest in new hardware/training, stretch your finances—getting laid off might feel like more than just a loss of a job; it might make you feel like you need to reevaluate your whole life. Before you make any big decisions, take some time to process your layoff. While location problems are less of a concern now that more of us have the opportunity to work from home, there are still plenty of jobs that want you to be in the same location as other employees.
I moved to Texas for my first job out of college using the last of my money. Dropped an opportunity to do a master’s since the goal of the master’s was to get a job like the one I just got in Texas. A month after I started, they hired a new CFO whose great new strategy was to lay off half the company (new grads never survive that). Fun fact, I got a 20% raise on the Monday because of my good work and was laid off on the Friday… Talk about whiplash. Found myself on the other side of the country with no family, friends, network, job, or money. Had to take out a loan to even pay for rent and food.
Keith van der Meulen, Data Engineer, Platform Engineering
Find all the folks that got laid off with you and schedule some time to vent. When I was laid off, the whole team went out and talked about their experiences. We shared our frustrations, connected, and drank a little too much. But in the end, we felt a bit better, and one of those former coworkers reached out a little later about joining her team. I had already decided to move cities, so it was a no go, but the opportunity came from connecting in that post-mortem vent.
That leads to the first way you can start looking for a way back into a job: For most of the people I talked to and most of the advice I read, working your network can make the greatest difference in your post-layoff job hunt. LinkedIn has been a game changer for this, but the other social networks can help with that. Heck, even enjoying sports can help you find your next job.
I met my friend Bob, who now runs the front-end team at Facebook, hanging out during the South Africa World Cup. He told me that he’d moved to California from Virginia, lost his job almost a year ago, and had given himself exactly 365 days to get a new one before he would take his wife and kids back to his parents’ basement in Virginia. It was around day 350: he’d already given notice to his landlord and was about to sell his beloved classic Porsche 911 to fund the move. I could tell he was a good engineer, so I offered to recommend him for a job I had just turned down that day. I told him I didn’t think the company had a long-term future, but it was a stepping stone to a better job and he completely understood the assignment. When that company closed, we introduced him to another startup where he did well; and when that company sold to Google, he worked his way up to front-end leadership on the mobile search engine—then to Facebook. But it all started because he did something—watching football!—to solve his biggest problem, which was that he didn’t have a local network to activate in times of need. Seeing Bob’s experience was the start of my advice to tell EVERYONE you’re looking for a job, without embarrassment or delay.
Joyce Park, co-founder of 106 Miles.
But your network won’t guarantee a job. You’ll need to do some legwork. Get your resume/elevator pitch/cover letter game in order and have as many people as possible review it. Connect with everybody you’ve worked with. Figure out where you’d like to work and connect with some people there. Research shows that people get jobs from weaker relationships—acquaintances—more than from close friends or former coworkers.
I updated my resume and LinkedIn profile. I shared them with former colleagues and friends for honest feedback. I applied for unemployment and over 20 jobs the following week. I created a Google Sheet to keep track of the many job listings, companies, and cover letters I sent. I applied to more jobs. I ate chips and queso. Lots of chips and queso.
Alex Pratt, Senior Demand Generation Specialist
Ultimately, though, the thing that will get you a new job is applying to those jobs. Chase the gigs that you know you can do, but also throw some applications at jobs that would stretch your skill set. If the jobs don’t come rolling in, consider contract work and open source contributions. Both provide extra connections to people and showcase your skills.
If you’re nervous about the state of the industry…For those of us who still have a job, this spate of layoffs, especially the large numbers happening at the tech behemoths, can make us all nervous. Those of us who were around for the previous bubble bursts might be getting flashbacks. But a few hiring freezes and rounds of layoffs don’t equal another crash.
While company size doesn’t guarantee safety—obviously—startups are always a bit of a risk. Most startups fail: about 90% will eventually go under. Working at a startup can be exciting and offer a big payoff if there’s an exit, but consider it a privilege to do so. In general, you should have some money in the bank to cover a few months expenses in case an emergency happens (this, too, is a privilege), if you’re working at a startup, have six or more months worth of expenses covered in your savings. If you’re looking for a stable job, maybe don’t work for a company that relies on investors to pay the bills.
For me, the biggest impact was the lost sense of trust that things would work out in a job, even if you were doing well. My dad is coming on 40 years with Hewlett Packard as a developer. Both grandfathers have the gold watch from their companies for 30 some years of service. Stack Overflow has been great and I’m finding myself back to enjoying my job, compensation, and company culture, but there will probably always be a bit of fear that it can disappear in an instant somewhere in the back of my head.
Keith van der Meulen, Data Engineer, Platform Engineering
Regardless of where you work, you should make an effort to understand your company’s business. Just the basics: does it make money and how? What’s the draw for customers? Is what you do integral to making money or are you working on peripheral problems? The better you are at connecting yourself and your daily work to that business process, the better chance you have of sticking around during any downturns. A corollary to that: seniority matters (or for programmers, employment is often LIFO). People who have been at a company for years have often accumulated a large amount of business knowledge and are therefore invaluable.
In downturns, degrees and experience matter more. If you’re self-taught, you might be at a little disadvantage, but if you’re got a few years of experience in a real-world job, most companies will ignore the degree. Similarly, if you’re in college and close to graduation, it might be a good idea to stretch out your remaining classes for as long as you can: Students who graduate into recessions can earn less than their peers for the rest of their careers.
It may not feel like it, but this can be a good thingIf you’ve lost your job, you don’t want to hear about the bright side of things. But getting a big shake up like this can leave you better off than you were before. Software engineers and other technologists who understand how software works are in high demand and will likely remain that way. Lots of companies that aren’t tech companies need people to write software for them. While you’re out of work now, you have one of the most marketable skillsets around.
After a layoff everyone feels super vulnerable. My ex, who had quit graduate school before finishing his doctoral thesis, thought that if he had finished his PhD he would have a job. His friend, who had dropped out of Stanford undergrad, fretted that lack of a BS was the cause of his unemployment. One of the other members, who had a visa situation, was panicked about how that might affect their job prospects. Every last one of them spent a lot of time second-guessing themselves. The truth was that these search engineers were among the most employable in the industry, and I don’t think anyone was off for more than three months.
Joyce Park, founder of o-founder of 106 Miles.
Unless you’ve been working at a company that’s been giving generous raises while you’ve been there, a layoff may be your best chance at getting a big raise. A recent study found that a typical job switch garnered the employees a 10% raise. Nearly half of job switchers got a raise when changing, with a third getting a 30% pay bump. If you’ve been hanging onto a job that gave out paltry raises that barely met the increases in cost of living, a job change—unexpected or not—might get you the bigger bucks that you deserve.
The company eventually got bought out and my pay and benefits dropped by quite a bit. The company I loved working where I trusted that my performance would be recognized changed to me just being employee number 24601. After two years of wage freezes, they started hiring people at 30% higher salary than me, but couldn’t give me a raise because the spreadsheet said 6% max.–-
Keith van der Meulen, Data Engineer, Platform Engineering
But the best reason to be hopeful is that it gives you an opportunity to take stock of where you are in life and consider whether you are on the path you want to be on. As Frank Herbert writes in Dune, “Without change something sleeps inside us, and seldom awakens. The sleeper must awaken.” A strong, sudden change can be just the thing to wake you, to help you see beyond the confines of your current work to the larger world you live in.
Who was going to hire a pregnant woman? And if I do get hired, will I even be eligible for maternity leave? Is my husband’s income alone enough to qualify us for a new mortgage? These were all questions that kept me up at night.Until one day in July, I received an email back from a company called Stack Overflow. In the following weeks I went through a rigorous interview process and the rest, as they say, is history. In mid-August, at 20 weeks pregnant, I was offered a full-time role at Stack Overflow. My husband and I closed on our new home three weeks later. And when I gave birth to my son in January 2020, I was given 16-weeks of fully paid maternity leave.
Alex Pratt, Senior Demand Generation Specialist
For me personally, that was certainly the biggest takeaway. It triggered some big changes, and I did feel a bit lost in the wilderness for a bit. But I found my footing by making choices towards better things. At first, the dot com crash made it hard for me to find something in tech, and I took a job in another field. But it played out according to what Joyce Park calls her “anti-King Canute” rule (named after a king who tried to legislate the tide): “Constantly remind yourself that there are external factors affecting your job search which you can’t do anything about, and fight your own second-guessing thoughts that there’s something wrong with YOU. It’s not you! It’s the economy! When there are jobs, you will get one.”
If you’ve been laid off, it may feel like the ground beneath you has turned to sand. But almost everyone I talked to had lay off stories; we’ve been here before and we’ll be here again. Tech industry experience is highly valued, so take time to process the layoff, then get your resume in shape and start looking again.
The post Just laid off? Nervous about possible layoffs? Here’s what to do. appeared first on Stack Overflow Blog.
Developing in VR, bitcoin over Tor, and data structures in JS
The post The Overflow #154: The state of the cloud in 2022 appeared first on Stack Overflow Blog.
Last one to leave turns off the microservices.
The post Taking stock of crypto’s crash appeared first on Stack Overflow Blog.
Dynamic application security testing (DAST) can help catch security flaws in your code. And it can do it automatically in your build process.
The post Continuous delivery, meet continuous security appeared first on Stack Overflow Blog.
Patreon’s VP of Eng talks product roadmap, deployment best practices, and UX philosophies.
The post From Twitter Bootstrap to VP of Engineering at Patreon, a chat with Utkarsh Srivastava (Ep. 514) appeared first on Stack Overflow Blog.
We dig into two of the most popular API protocols to see where they work best.
The post When to use gRPC vs GraphQL appeared first on Stack Overflow Blog.
"Performant", knights who need glasses, and keyboard shortcuts for all
The post The Overflow #153: How to get a job in Japan appeared first on Stack Overflow Blog.
Typing might be faster, but longhand stays with you better.
The post Why writing by hand is still the best way to retain information appeared first on Stack Overflow Blog.
We chat with a Platform Engineer and Reality Labs Advocate about the expanding toolkit available for crafting virtual reality experiences.
The post Here’s what it’s like to develop VR at Meta (Ep. 508) appeared first on Stack Overflow Blog.
SPONSORED BY PLURALSIGHT Early in the days of high-traffic web pages and apps, any engineer operating the infrastructure would have a server room where one or more machines served that app to the world. They named their servers lovingly, took pictures, and watched them grow. The servers were pets. But since the rise of public…
The post Cloudy with a chance of… the state of cloud in 2022 appeared first on Stack Overflow Blog.
What if you could bake a payment mechanism into the DNA of an open source package manager?
The post The creator of Homebrew has a plan to get open source contributors paid (Ep. 506) appeared first on Stack Overflow Blog.
Hashgraph vs. blockchain, ADHD and a pilot license, and Mastadon
The post The Overflow #152: Another week of tech layoffs appeared first on Stack Overflow Blog.
Just because marketing uses a word doesn't mean it's a meaningful way to talk about software.
The post “Performant” is nonsense, but performance can still matter appeared first on Stack Overflow Blog.
Prompting for a username and password is so 2005. Today, you can just prompt for a fingerprint.
The post You can add biometric authentication to your webpage. Here’s how. appeared first on Stack Overflow Blog.
Low-code/no-code tools can help developers and non-developers alike.
The post Speeding software innovation with low-code/no-code tools appeared first on Stack Overflow Blog.
How a solo developer makes a living with a job board for engineering roles in Japan
The post Tips and tricks for succeeding as a developer emigrating to Japan (Ep. 505) appeared first on Stack Overflow Blog.
Testing the one assertion per test rule, black holes, and shell scripts
The post The Overflow #151: DIY mad science appeared first on Stack Overflow Blog.
We need to talk about it.
The post Another hard week in tech (Ep. 505) appeared first on Stack Overflow Blog.
Family histories, robots, and politics. Plus, the one Stack Exchange that covers them all: Anime!
The post Five Stack Exchange sites are celebrating their ten year anniversaries in Q4 2022! appeared first on Stack Overflow Blog.
SPONSORED BY HEDERA HASHGRAPH When most people talk about Web3 or cryptocurrencies and related technologies, they usually mean blockchains. But blockchain is only the first generation of distributed ledger technology (DLT). As with any new technology, once people see how it works, new generations come along rapidly to address the faults in the previous ones. …
The post Hashgraph: The sustainable alternative to blockchain appeared first on Stack Overflow Blog.
From building the app store to forging a new approach to personal data on the blockchain.
The post Fighting to balance identity and anonymity on the web(3) (Ep. 504) appeared first on Stack Overflow Blog.
What happens if you build it and no one comes?
The post Going from engineer to entrepreneur takes more than just good code (Ep. 503) appeared first on Stack Overflow Blog.
Unlocking innovation with our CEO, the OG UNIX font, and homelabbing
The post The Overflow #150: Keystrokes vs. productivity appeared first on Stack Overflow Blog.
One test case, not one test assertion.
The post Stop requiring only one assertion per unit test: Multiple assertions are fine appeared first on Stack Overflow Blog.
The Foursquare app used to be just a way to check in to the places you go. But that location data is more valuable to developers.
The post Making location easier for developers with new data primitives appeared first on Stack Overflow Blog.
The Foursquare app used to be just a way to check in to the places you go. But that location data is more valuable to developers.
The post Making location easier for developers with new data primitives appeared first on Stack Overflow Blog.
We break down homelabbing tricks to level up your WFH game.
The post DIY mad science…it’s all about homelabbing appeared first on Stack Overflow Blog.
We break down homelabbing tricks to level up your WFH game.
The post DIY mad science…it’s all about homelabbing appeared first on Stack Overflow Blog.
Building traditional native apps often requires maintaining two or more codebases. Let's look at two frameworks that let you keep your code unified.
The post Flutter vs. React Native: Which is the right cross-platform framework for you? appeared first on Stack Overflow Blog.
Building traditional native apps often requires maintaining two or more codebases. Let's look at two frameworks that let you keep your code unified.
The post Flutter vs. React Native: Which is the right cross-platform framework for you? appeared first on Stack Overflow Blog.
Synthetic data, can ISPs censor?, and paying to be surveilled
The post The Overflow #149: Stack Overflow without the internet appeared first on Stack Overflow Blog.
Synthetic data, can ISPs censor?, and paying to be surveilled
The post The Overflow #149: Stack Overflow without the internet appeared first on Stack Overflow Blog.
As quantum computing becomes available on demand, a new generation can experiment with this still nascent technology.
The post How to get more engineers entangled with quantum computing (Ep. 501) appeared first on Stack Overflow Blog.
As quantum computing becomes available on demand, a new generation can experiment with this still nascent technology.
The post How to get more engineers entangled with quantum computing (Ep. 501) appeared first on Stack Overflow Blog.
Learn about the workflow designed to help users ask their first question on Stack Overflow.
The post Introducing the Ask Wizard: Your guide to crafting high-quality questions appeared first on Stack Overflow Blog.
Learn about the workflow designed to help users ask their first question on Stack Overflow.
The post Introducing the Ask Wizard: Your guide to crafting high-quality questions appeared first on Stack Overflow Blog.
We’re fortunate to continue to grow at a rapid pace. In dynamic times, whether it be in times of hyper growth or in times of market volatility, we are seeing from our community and customers alike that breaking down the barriers to knowledge is essential for success.
The post CEO update: Breaking down barriers to unlock innovation appeared first on Stack Overflow Blog.
We’re fortunate to continue to grow at a rapid pace. In dynamic times, whether it be in times of hyper growth or in times of market volatility, we are seeing from our community and customers alike that breaking down the barriers to knowledge is essential for success.
The post CEO update: Breaking down barriers to unlock innovation appeared first on Stack Overflow Blog.
We break down the key announcements - from Turbopack, to Splitbee analytics, to new features in Next.JS 13.
The post Goodbye Webpack, hello Turbopack! The big news from today’s Next.JS conference appeared first on Stack Overflow Blog.
We break down the key announcements - from Turbopack, to Splitbee analytics, to new features in Next.JS 13.
The post Goodbye Webpack, hello Turbopack! The big news from today’s Next.JS conference appeared first on Stack Overflow Blog.
There's more to developer education than classrooms and bootcamps.
The post A flight simulator for developers to practice real world challenges and surprises (Ep. 500) appeared first on Stack Overflow Blog.
Keystrokes per minute is a terrible measure of productivity, but a keyboard can help you focus better to be productive.
The post How hardware and software can maximize your flow states appeared first on Stack Overflow Blog.
The service-oriented approach to 1MM rep, one qubit, and less scary cryptography
The post The Overflow #148: How to job hop appeared first on Stack Overflow Blog.
A long-time Microsoft employee explains his attraction to the new world of blockchain technologies.
The post He helped build .NET and VS Code — Now’s he working on Web3 (Ep. 499) appeared first on Stack Overflow Blog.
For coders without an internet connection, an offline dataset provides an essential encyclopedia
The post Introducing the Overflow Offline project appeared first on Stack Overflow Blog.
If you want a fast highway, you should have fewer cars.
The post Faster feedback loops make for faster developer velocity (Ep. 498) appeared first on Stack Overflow Blog.
We all have fears when it comes to tech. These are (some of) our stories.
The post Beware the scammers posing as tech recruiters (Ep. 497) appeared first on Stack Overflow Blog.
Statistically-relevant data, but not actually exploitable.
The post Privacy-friendly machine learning data sets: synthetic data appeared first on Stack Overflow Blog.
Automated movie and TV curation, downcasting, and templating in HTML
The post The Overflow #147: Working with a second brain appeared first on Stack Overflow Blog.
A new platform promises to make building a robot as easy as crafting a smartphone app.
The post The robots are coming… but when? (Ep 496) appeared first on Stack Overflow Blog.
Most organizations struggle to change their culture or find a formula for success in difficult-to-mature processes. They don't always understand their own systems.
The post How observability-driven development creates elite performers appeared first on Stack Overflow Blog.
How long is too long to stay at a software development job?
The post The right way to job hop (Ep. 495) appeared first on Stack Overflow Blog.
And he keeps learning with every answer.
The post How to earn a million reputation on Stack Overflow: be of service to others appeared first on Stack Overflow Blog.
An amazing group of experts gave talks on everything from developer productivity to the future of hybrid work and remote learning.
The post Missed our Flow State conference? Catch up on all the sessions appeared first on Stack Overflow Blog.
Flow state via fingertips, recovering from a PIP, and hello Hacktoberfest
The post The Overflow #146: Weekday vs Weekend appeared first on Stack Overflow Blog.
Sometimes the path from IC to CEO is learning that you love being a coach.
The post A chat with Red Hat’s Matt Hicks on his path from developer to CEO (Ep. 494) appeared first on Stack Overflow Blog.
We chat with the engineers behind some of the world's biggest streaming platforms.
The post Meet the AI helping you choose what to watch next appeared first on Stack Overflow Blog.
Learn about our newly designed tool to help make your favorite questions and answers easier to find.
The post Meet Saves: the tool to help you organize your favorite content on Stack Overflow appeared first on Stack Overflow Blog.
We talk about giving people the space necessary to do their best work, implementing more inclusive hiring practices, and everyday routines that help us stay our happiest and most productive.
The post The many strengths of neurodivergence (Ep. 493) appeared first on Stack Overflow Blog.
Do we work better when we outsource our memory to other tools?
The post Two heads are better than one: What second brains say about how developers work appeared first on Stack Overflow Blog.
Five nines without burnout, dealing with deference, and upcycling.
The post The Overflow #145: An entrepreneur embraces OSS appeared first on Stack Overflow Blog.
We recap Stack's first ever customer conference and Cassidy shares her plans for tackling her first Chief Officer role.
The post Cassidy becomes a CTO! (Ep. 492) appeared first on Stack Overflow Blog.
Sponsored by Logitech Developers and their employers are constantly thinking about productivity. We partnered with Logitech to produce a four-part podcast series to chat about how your hardware and software work together to keep you in a flow state and make you more productive. Each podcast will have it’s own landing page on the blog,…
The post For developers, flow state starts with your finger tips appeared first on Stack Overflow Blog.
While countless apps are competing for your attention, here's some tips on how to fight back.
The post Don’t let software steal your time (Ep. 491) appeared first on Stack Overflow Blog.
Is everybody coding on the weekends? Is everybody learning Rust?
The post Stack Overflow trends: Weekday vs weekend site activity appeared first on Stack Overflow Blog.
Proof of work is here, but who can stake me some silicon?
The post Ethereum finally merges, semiconductors stay scarce (Ep. 490) appeared first on Stack Overflow Blog.
Single sign-on, a 9V battery to power the world, and the core ideals of Steve Jobs
The post The Overflow #144: Number input is the worst appeared first on Stack Overflow Blog.
When it's done wrong, it becomes punitive micromanagement. When it's done right, it empowers everyone to tackle the problems they handle best.
The post We hate Scrum and Agile…when it’s done wrong (Ep. 489) appeared first on Stack Overflow Blog.
The days of traditional application monitoring are fading. Applications today are no longer a single program, but a network of services connected by API and RPC endpoints across cloud containers that are created and removed as needed.
The post Five nines uptime without developer burnout (Ep. 488) appeared first on Stack Overflow Blog.
Developers are always trying to shorten the distance between thinking of a solution and coding. How much does the integration of hardware and software in your everyday tooling help?
The post Can integrating hardware with software save developers time and energy? (Ep. 487) appeared first on Stack Overflow Blog.
Serial entrepreneur Arpit Mohan, cofounder and CTO of Appsmith, tells Ben and Cassidy about his path to building Appsmith, an open-source project that makes it easy for engineers to build, ship, and maintain internal tools.
The post A serial entrepreneur finally embraces open source (Ep. 486) appeared first on Stack Overflow Blog.
Absent a time machine, telling others how to avoid my mistakes is the best I can do.
The post I spent two years trying to do what Backstage does for free appeared first on Stack Overflow Blog.
AI-assisted cheating, clarity vs. code confidence, and (not so) Critical CSS
The post The Overflow #143: Modern Perl appeared first on Stack Overflow Blog.
When a company hits a period of hypergrowth, developers are in for a thrill ride. They need to start scaling their systems, moving to service architectures and clouds, and looking to solve problems others haven’t. But hypergrowth brings headaches, too, and chief among them is how to keep everyone aware of what’s going on with teams that they aren’t a part of.
The post Hypergrowth headaches (Ep. 485) appeared first on Stack Overflow Blog.
Think that web form has got your number? If you used input type="number", you may be surprised to find that it doesn't.
The post Why the number input is the worst input appeared first on Stack Overflow Blog.
We chat with Marcel Twohig, Head of Design for the MX Series at Logitech, Thomas Fritz, Associate Professor of Human Aspects of Software Engineering, about what makes developers more productive.
The post What science says about flow state (Ep. 484) appeared first on Stack Overflow Blog.
In a new study commissioned by Stack Overflow, The Total Economic Impact of Stack Overflow for Teams, Forrester Consulting found that customers saved $9.5M over three years with a payback period of less than 6 months.
The post Forrester Consulting TEI Study: Five ways Stack Overflow for Teams delivered 191% ROI appeared first on Stack Overflow Blog.
Ben, fresh from launching Stack Overflow’s new Student Ambassador Program, tells Matt about partnering with Major League Hacking, the young programmers eager to get back to in-person events, and the powerful allure of free pizza. Plus: Why you don’t have to create an account to engage with our public platform.
The post Hackathons and free pizza: All about Stack Overflow’s new Student Ambassador Program (Ep. 483) appeared first on Stack Overflow Blog.
Without SSO and other enterprise features, a product can only go so far.
The post The many problems with implementing Single Sign-On appeared first on Stack Overflow Blog.
Functional programming for blockchains, multiple conditional inheritances, and the life of Clippy
The post The Overflow #142: The bane of bossware appeared first on Stack Overflow Blog.
Ben talks with Dylan Fox, founder and CEO of rapid-growth startup AssemblyAI, about how he became interested in AI and machine learning, why he left a steady job at a tech giant to create something new, and what AI can offer creators like writers and visual artists.
The post Plug-and-play AI for your own projects (Ep. 482) appeared first on Stack Overflow Blog.
That Perl interpreter you have on your Linux machine? Update it and check out the present.
The post This is not your grandfather’s Perl appeared first on Stack Overflow Blog.
Episode one of our four-part series sponsored by Logitech.
The post Flow state at your fingertips: How keyboards impact developer productivity (Ep. 481) appeared first on Stack Overflow Blog.
Curation at scale needs to process a lot of data with a good algorithm.
The post How machine learning algorithms figure out what you should watch next appeared first on Stack Overflow Blog.
Learn how developers, technologists, and forward thinking organizations are adapting to the new normal.
The post Work has changed. Our upcoming conference, Flow State, explores what’s next appeared first on Stack Overflow Blog.
Will students learn the the fundamentals if they can just TAB their way to a function?
The post Does AI-assisted coding make it too easy for students to cheat on schoolwork? (Ep. 480) appeared first on Stack Overflow Blog.
AI goes on prem, university cheating at scale, and why React re-renders
The post The Overflow #141: High-velocity and burnout appeared first on Stack Overflow Blog.
Tommy McClung, cofounder and CEO of ReleaseHub, sits down with the home team to talk about environments-as-a-service, what it’s like to work with the same cofounders for more than 20 years, and the role of karma in professional networking.
The post Environments on-demand (Ep. 479) appeared first on Stack Overflow Blog.
Some applications just lend themselves to certain programming paradigms.
The post Functional programming is an ideal fit for developing blockchains appeared first on Stack Overflow Blog.
The home team gathers for a conversation about workplace productivity monitoring: Does it motivate employees to get more done, or does it lead to stress that takes away from deep, focused work and replaces it with busywork instead?
The post What companies lose when they track worker productivity (Ep. 478) appeared first on Stack Overflow Blog.
Learn how Stack Overflow can help support your campus clubs or hackathons.
The post Stack Overflow is launching a Student Ambassador Program. Here’s how to apply. appeared first on Stack Overflow Blog.
AI-assisted job placement, garbage collection basics, and Redis explained
The post The Overflow #140: Interrogating code appeared first on Stack Overflow Blog.
Serial entrepreneur Varun Ganapathi joins the home team for a conversation about the intersection of physics, machine learning, and AI. He offers some recommendations for developers looking to get started in the ML/AI space and shares his own path from academia to entrepreneurship.
The post The luckiest guy in AI (Ep. 477) appeared first on Stack Overflow Blog.
The more open a system is to new contributors, the more chance that an accidental meeting will benefit everyone involved.
The post Open source and accidental innovation appeared first on Stack Overflow Blog.
The home team discusses how Instagram’s evolving platform has alienated some creators, why AI and machine learning are moving on-premises, and why Amazon’s acquisition of the company behind the Roomba is striking from a privacy perspective.
The post Why AI is having an on-prem moment (Ep. 476) appeared first on Stack Overflow Blog.
High velocity compared to what?
The post Does high velocity lead to burnout? That may be the wrong question to ask. appeared first on Stack Overflow Blog.
The home team sits down with Liam Zhao, founder and CEO of Immersive, a startup that gives creators tools to produce engaging virtual content and events.
The post Combining the best of engineering cultures from Silicon Valley and Shanghai (Ep. 475) appeared first on Stack Overflow Blog.
Low code & no code, electronic export confusion, and free design pattern book
The post The Overflow #139: Software licenses against evil appeared first on Stack Overflow Blog.
Since the day a hiring manager first wheeled a whiteboard into a conference room, software engineers have dreaded the technical interview, which can be an all-day process (or multi-day homework assignment). If you’re interviewing for multiple roles, you can expect to write out a bubble sort in pseudocode for each one. These technical interviews do…
The post The last technical interview you’ll ever take (Ep. 474) appeared first on Stack Overflow Blog.
The home team is joined by Heather Meeker, a specialist with a deep history in the world of open-source software licensing.
The post A history of open-source licensing from a lawyer who helped blaze the trail (Ep. 473) appeared first on Stack Overflow Blog.
Readable code is great, but not all code will be immediately readable. That's when you get your interrogation tools.
The post How to interrogate unfamiliar code appeared first on Stack Overflow Blog.
Monitoring data quality, telling your boss about overtime, and Docusaurus 2
The post The Overflow #138: Social learning for engineers appeared first on Stack Overflow Blog.
Spencer Kimball, cofounder and CEO of Cockroach Labs and co-creator of the GIMP image editor, tells Ryan and Ceora about how database technology has evolved to handle massive data volumes, how Cockroach labs came to focus on solving latency issues through serverless technology, and his “relatively gentle” transition from engineer to CEO.
The post A conversation with Spencer Kimball, creator of GIMP and CockroachDB (Ep. 472) appeared first on Stack Overflow Blog.
Will the programmers of tomorrow be shipping products written without touching too much code?
The post Will low and no code tools ever truly disrupt tech development? appeared first on Stack Overflow Blog.
Joshua Browder, founder and CEO of DoNotPay, tells us how a heap of expensive parking tickets inspired him to build software that helps people avoid fines, secure refunds, claim free land, win back lost savings, and even combat systemic racism.
The post The internet’s Robin Hood uses robo-lawyers to fight parking tickets and spam calls (Ep. 471) appeared first on Stack Overflow Blog.
Can you control what you've already set free?
The post Can you stop your open-source project from being used for evil? appeared first on Stack Overflow Blog.
Hate it? Automate it, scientific uncertainty, and the benefits of mini-forests
The post The Overflow #137: The San Francisco exodus appeared first on Stack Overflow Blog.
The home team talks about the coding error that forced ten million Canadians offline, advice for coders trying to get out of a rut, and how low-earth orbit satellites are reshaping the internet. Plus: a Netflix documentary for getting out of a rut and reshaping your mind all in one.
The post Satellite internet: More useful than sending a car into space (Ep. 470) appeared first on Stack Overflow Blog.
For a successful Agile and DevOps practice, organizations need to think beyond tooling. Engineering organizations need a strong community of practice culture that supports the collecting and distributing of knowledge, greater cross-organizational collaboration, and breaks down the silos that can happen in companies of all sizes.
The post Great engineering cultures are built on social learning communities appeared first on Stack Overflow Blog.
Developers need to always be learning, but knowing what skills companies need can help you direct your learning towards marketable skills.
The post Skilling for success: How demand for development skills is changing appeared first on Stack Overflow Blog.
Bigeye cofounders Kyle Kirwan (CEO) and Egor Gryaznov (CTO) join the home team to discuss their data observability platform, what it’s like to go from coworkers to cofounders, and the surprising value of boring technology.
The post Monitoring data quality with Bigeye (Ep. 469) appeared first on Stack Overflow Blog.
Kafka topic design, skills for reverse engineering, and another AI creating photos
The post The Overflow #136: Sufficiently advanced code completion feels like magic appeared first on Stack Overflow Blog.
Ben and Matt discuss how tech workers’ preference for remote work is driving a near-exodus from cities like San Francisco, while smaller cities like Tulsa, Oklahoma are literally paying remote workers to relocate.
The post San Francisco? More like San Francis-go (Ep. 468) appeared first on Stack Overflow Blog.
Spoken languages have distinct levels to measure skills; why shouldn't programming languages, too?
The post Measurable and meaningful skill levels for developers appeared first on Stack Overflow Blog.
It’s been a busy quarter for the company. We celebrated a handful of big milestones over the last three months. We added a new Chief Technology Officer, Jody Bailey, to our leadership team, announced Stack Overflow for Teams entering the Microsoft Azure Marketplace, launched exciting initiatives like Staging Ground, and released insights from this year’s Developer Survey.
The post Always learning appeared first on Stack Overflow Blog.
Lauren Peate, founder and CEO of Multitudes, joins the home team for a conversation about how managers and executives can support their development teams through ethical data and analytics practices. Plus: What it’s like to launch a startup in a smaller country like New Zealand.
The post Data analytics: Less creepy, more empowering appeared first on Stack Overflow Blog.
Turns out the robots are here to make your job more interesting.
The post Automate the boring parts of your job appeared first on Stack Overflow Blog.
Money that moves at the speed of information, a conversation with Stack Overflow's new CTO Jody Bailey, and and exploring how Rust manages memory.
The post The Overflow #135: Money that moves at the speed of information appeared first on Stack Overflow Blog.
The home team talks game development and PowerPoint, the good ol’ days of Game Boy, and wild facts about the largest species in the deer family. Plus: Was that summer everyone was playing Pokémon GO the closest we’ll ever get to world peace?
The post Game Boy emulators, PowerPoint developers, and the enduring appeal of Pokémon GO (Ep. 466) appeared first on Stack Overflow Blog.
An event-driven architecture can reduce dependencies, increase safety, and make your application easy to scale. But designing your systems and topics is a non-trivial task
The post Design patterns for asynchronous API communication appeared first on Stack Overflow Blog.
Get developers the right tools, or provide the means to build them.
The post How APIs can take the pain out of legacy system headaches (Ep. 465) appeared first on Stack Overflow Blog.
Meredydd Lyff, founder and CEO of Anvil, joins the home team to discuss code completion: what it is and how it works, from first principles to best practices. Plus: Is 90% of biology attributable to magic gremlins?
The post Code completion isn’t magic; it just feels that way (Ep. 464) appeared first on Stack Overflow Blog.
Your DevOps team might already be singing the praises of their observability platforms. But developers can benefit from them, too.
The post How observability is redefining the roles of developers appeared first on Stack Overflow Blog.
Perl in 2022, the legality of Googling the illegal, and fuzz tests
The post The Overflow #134: Avoiding the difficulty bomb appeared first on Stack Overflow Blog.
The home team convenes to discuss the end of the GPU shortage, how the no-code/low-code movement is impacting developers, and why job candidates should flip the script and interview their interviewers.
The post At your next job interview, you ask the questions (Ep. 463) appeared first on Stack Overflow Blog.