Search Results

Yes. You read the title right. An answer to the worst nightmare of industry professionals in developer-facing roles. This includes people in Developer Relations, community managers, Developer Program Managers and more! It’s not just us saying it; it’s the people in these roles who have expressed how challenging it is to prove the value an onboarded developer brings, and they have done so in podcasts , panels and 1 to 1 discussions we had. That’s why at SlashData, we developed the framework that calculates the added value every onboarded developer brings in real dollars. In our thought leadership report, we show you how to calculate this dollar value by introducing the concept of Developer Engagement Value . The total value that a developer is expected to bring over a period of time either by using a vendor’s technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). It is a forward-looking metric that takes into account the variable nature of developer behaviour and introduces a framework to calculate developer value in real dollars. You can access the full framework here . Or read on for more information.  Why do you need to know the value an onboarded developer brings? Developers are more than mere product or service users. Developers are unarguably partners and co-creators who add value that extends well beyond the direct revenue stemming from technology usage. Many Developer Relations (DevRel) and developer marketing practitioners struggle to prove just how valuable an onboarded developer is, and, consequently, to justify their budget investments in DevRel. Even if they do get their budgets approved, they are faced with the problem of how to optimally allocate this budget to the different activities. But are DevRel budgets the only reason why you would need to estimate the value that a developer brings? How about when launching a new developer product? Won’t you need a way to predict how many developers this new product will attract and how much value these new developers will bring? For decades, Customer Lifetime Value (CLV or LTV) has been used to predict the value a client will bring throughout their ‘lifetime’ (length of relationship) with a company. Model setup and estimation was fairly straightforward at the time when all we had to worry about was direct revenue and transactional data. But in the developer ecosystem and in the era of network effects, indirect revenue, influencers, open source, and developer communities of all shapes and sizes… how do you capture value? This is what we are after with the Developer Engagement Value . 4 key questions to answer first Estimating the value that a developer brings is a daunting task, given the indirect value contributions and network effects intrinsic to the developer ecosystem. Challenges, however, begin a lot earlier in the problem definition process than the indirect value estimation stage. Considering these four key questions will help us to define the boundaries of the problem better: Whose value should you estimate? As discussed earlier, it’s not just those using your products. We posed this question also to our community of DevRel practitioners, and we got back a broad spectrum of answers. See the full report for a selected set of their responses. Can you observe the developer journey? Time is a continuum and observing a developer’s journey uninterrupted in this continuum is one of the most challenging endeavours. Telemetry alone will not get you there. How should you define ‘lifetime’? What is the time horizon for your predictions? How far into the future should you try to see and estimate value for? Do you really need a dollar value estimate per onboarded developer? It depends on what your end goal is. For example, if what you’re trying to achieve is optimal prioritisation of DevRel initiatives, then a relative, rather than an absolute, value will suffice. If, however, you need a number for your ROI and budget calculations, then you do need a dollar value estimated. The DEV framework As we mentioned earlier, the concept of Customer Engagement Value (CEV) has been around for more than a decade. We built on the model proposed by Kumar et al. (2010), adjusting and extending it to capture all the forms of engagement that are typical to developers. In a nutshell: Our framework proposes a method of estimating the total value that a developer is expected to bring over a period of time, either by using your technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). We call this the Developer Engagement Value (DEV) , and it is a forward-looking metric that takes into account the variable nature of developer behaviour. To arrive at the Developer Engagement Value, SlashData identifies seven key areas from where developer value stems – seven value categories: Developer Direct Value (DDV) Supporter and Skill-builder Value (SSB) Peer Influencer Value (PIV) Decision-maker Influencer Value (DmIV) Developer Referral Value (DRV) Developer Feedback Value (DFV) Developer Contributor Value (DCV) Then, factoring in data from its global developer surveys, SlashData can map all the evolution paths that the developer segments of interest can theoretically take in the course of a selected forecasting period. The next step is to  build models to find the link between developer value and specific initiatives (DevRel, developer marketing, pricing strategy, or product feature design) and finally provide scenarios which show you how each initiative is expected to change the value of each segment.  The framework is fully flexible as it can be applied to a single product, to a group of products or across your whole business. It is also sensitive enough to pick up nuances between similar initiatives and, as such, can provide you with granular insight on specific activities. What can the Developer Engagement Value framework do for you? How are you planning to use it? Dive in the full version and here’s to a brighter future. Download the framework . #developercommunity #developerdollarvalue #developervalue #roi

In the blog post, Take your Data to Dinner , we discussed the importance of clean online survey data: not all survey responses are suitable for analysis – in fact, negative and often fraudulent actors abound. That blog explained how to screen data in order to establish its reliability and cleanliness. In this post, the focus is more technical. Looking strategically at what modern, industry-leading data collection methodology should look like, we unpack the nuts and bolts of the kind of information a market research firm should be collecting from their survey respondents so as to be informed about their quality of the data they provide. What counts as a fraudulent response to our surveys First and foremost, who are the negative actors that we’re talking about here? Before jumping in, it should be noted that these groups are not the only creators of dirty data. At SlashData, we have observed three categories of fraudulent respondents, broadly speaking:  Complete response bots. These bots circumnavigate a survey tool and deliver their answers as a complete set directly to the end point of an API. Think of it as a fully packaged response delivered without even a click needed on the survey tool. Their responses feel forced, clumsy, and lack the human signature. Bot responses from web automation tools. It is always sad to see sophisticated web debug tools such as Selenium harnessed in this manner. These web automation tools work by taking control of the browser according to a programmed routine designed by a developer. It may not be wholly surprising that for a market research firm in the tech space (with a proud pedigree amongst the developer audience) we have seen a goodly few iterations of this sort of bot. Responses like these have hidden systematic patterns which can lead to their detection. Humans working as click farms. This is an individual or a group utilising one or more physically or even virtually different devices in order to register multiple responses to a survey. These responses provide human-like responses but often reek of disinterest and are usually filled with contradiction. Their answers exude artificial resonance.  I’ll explain how we tackle each of these groups. As a prerequisite, I’ll explain the information SlashData gathers so as to do this. Thereafter the overall mechanism, a trust index, which integrates the multiple information sources. Equipped with this, I’ll return to each of these negative actor groups explaining each trip themselves into negative trust territory. A decision is only as good as the information up which it is made. Judging data quality on a number of unique information pieces Before making any decision, it is obviously prudent to gather information. The nightmare situation of any court judge (or market research firm) is the presentation of new evidence mid-trial: not only does it prompt re-evaluating all that has gone before but, in some instances, it casts doubt on the information already provided. For some market research firms, the threat that new ‘mid-trial’ information poses is so concerning that it acts as a deterrent from even seeking such information in the first place. This is a research bias! It is a bias that helps explain why market research firms say that they already have enough information to decide the quality of a respondent and are not hungry for more or to be challenged.  To avoid dismissing information with an important impact on our understanding of the cleanliness of our data, we do not accept this position at SlashData. Instead, we have focused on acquiring several unique pieces of information in order to generate an overall mechanism – a trust index – which integrates the information we are able to gather about our respondents into a single score against which we are able to evaluate their credibility as a bona fide respondent. It is obviously only worth designing a trust index if you have multiple sources of information such as click position monitoring, reCaptcha validation, IP and proxy detection methods; and this is just to name a few. Some of the key pieces of data that are core to SlashData’s approach in data collection standards are the viewpoint data (telling us exactly how much of the question the respondent engaged with), per-question timing, and third-party validation mechanisms such as GitHub verification for developer profiles. Constructing a trust index for our data Just having information does not give an answer. That is why constructing a trust index is such a sophisticated (and yet essential) process.  Here, The Trust Index designed at SlashData, is the key to a coherent system of quality control which works by tracking actions that build and diminish trust. To give an example, a response that does not use privacy persevering tools and is of the same geolocation and reported location builds trust. Similarly, a response that uses privacy preserving tools is trust neutral – it could be either a good or bad actor and based on this information alone, there is no sufficient evidence to determine either way. But couple privacy preserving tools with a signature that suggests it is the same device, close starting times and known incentives to defraud — a picture of overall trust diminishment occurs.  Deploy and Detect Let us return to the three groups of negative actors we identified above to demonstrate how we are able to detect each by deploying our industry-leading data collection methodology. Complete response bots. This type of bot scores very negatively on the Trust Index by bypassing many of our other data collection mechanisms – for instance, they would not have a sensibly defined viewpoint (because their responses did not come through a survey tool). This is a quick and reliable red flag to their credibility which means that we can be completely sure that this type of bot has been completely removed from our clean data at SlashData. Bot responses from web automation tools. This is a more sophisticated type of bot fraud. Because the bot interacts with the survey tool, it is able to create responses that contain basic viewpoint information and other artefacts that our other mechanisms of data collection are on the lookout for. There are some dead give-aways, though: the bots’ response times between questions are either fixed (taking precisely 2 seconds for instance) or follow some type of probability distribution, such as being normally or uniformly distributed. A real human response would take more or less time per question depending on the length of the question, the sophistication of the question (grid or list) and if the question is multi- or single-choice. Too much uniformity in this area signals a response of low trust value. Web automation tools also fail to pass reCaptcha tests. A failure of a reCaptcha test in any instance is an extremely trust diminishing action .  Humans working as click farms. This type of fraud requires screening through multiple different data sources in order to be detected since it is a broad group within which are several levels of professionalism. The least sophisticated examples answer questions carelessly, almost randomly and thereby fail multiple trust tests for consistency; those that are slightly more sophisticated may attempt to change devices or use privacy preserving tools, but subtle pointers  give them away and they are inevitably detected. The most sophisticated require the analysis of multiple patterns/combinations involving unlikely userAgent device signatures, privacy information and responses.  You cannot prevent, fight or detect fraud if you do not have the data.  Do not let cancerous data consume your research. The importance of partnering with a market research firm which is constantly committed to the improvement of data collection methodologies for online surveys is one way you can avoid publishing noise and instead focus on making a noise about your research! We can get the clean data you need to optimise your strategy. How? Let’s talk . About the author Jed Stephens, Senior Data Scientist Jed has several years of research experience in the academic and industry sectors, mainly focusing on applied statistical research and computational implementations of new statistical methods. He holds an MSc in Statistics. His interest is in turning data into informed, actionable decisions.

What do developers expect from tech leaders in their developer program offerings? How do the leading developer programs compare? If you are looking for answers to these questions, then the Developer Program Benchmarking is for you.  What is the Developer Programs Benchmarking? It is SlashData's semi-annual market analysis on engagement and developer satisfaction, of industry-leading developer programs. Working with developers is challenging and modern developer programs consist of myriad activities including: Documentation Providing sample code Developer education Tooling In-person events Online communication among others.  It is hard to be great at everything, and it is hard to allocate effort and money effectively for maximum impact. So, we benchmark the developer programs against each other and in doing so, we provide a clear path to improving your own developer program.  What can the Developer Programs Benchmarking help you improve? There are two main areas in this benchmarking study that can help you improve.  First, measure what developers value in various resources and activities, in all their diversity, across several segments of the developer population.  Second, we highlight the best-practice leaders and what makes them stand out. There is no single leader across all 22 activities we measure —everyone can improve somewhere.  To understand the success of the various developer programs included in our research, we use three key metrics:  Adoption —the percentage of developers in our survey that use each program. Engagement —how frequently the users of each program consume its resources. Satisfaction —how developers score each attribute of the programs they use, equal to the proportion of five-star reviews minus the proportion of one-and two-star reviews What new insights are there from the leading developer programs in Q3 2023? The main highlight? Many smaller vendors eclipse the established market leaders' satisfaction scores Developers' answers in public forums In each new edition, we have a special "Deep Dive" where, on top of the main insights on Developer Programs, we focus and shed light on a more specific area of Developer programs. For this edition, we added a Deep Dive on Answers in public forums. Here are the questions we answer. Which types of developers value answers in public forums the most? How often do developers ask questions, answer questions, or otherwise utilise public forums? What are the most important characteristics of a useful answer in a public forum, and how does this change by developers’ experience levels? How satisfied are developers with the quality, frequency, and speed of vendors’ responses to questions in public forums? You can find more details about developers’ preferences for developer programs at the dedicated Developer Program Benchmarking page . If you are looking to benchmark your developer program against the leaders, please get in touch .

Clean data is difficult to define. Simply, clean data is data that is analysis ready, but the term ‘analysis ready’ has baked into it much more than initially meets the eye. Perhaps then, the easiest way to get clear on what clean data is, is to understand what clean data is not. After all, as Tolstoy put it, “ All happy families are alike; each unhappy family is unhappy in its own way .”  Dealing with dirty data Dirty data is, by definition, data that is not analysis-ready - it is fraudulent, corrupted, or distorted in one or several of a number of ways, depending on how the data is provided. In surveys, for example, questions can be hurriedly answered, answered by selecting at random, answered systematically randomly, such as by always selecting the third option, answered in pretence, answered boastingly, and so on and so on. And this is just to name a few.  Suddenly, the data is corrupted, and what we are left with is not fit for clean, reliable analysis. Let alone decision-making.  What this means in practice is that it is only the data from respondents who are genuine and also consciously engaged (with a survey) that should be considered “clean”. Clearly a market research firm needs to be able to provide the process of screening for the various forms of dirty data. Clean data are necessary for real-world, tangible decisions A simple equivalent might be something like this. Imagine that you’re a user on an online dating platform. You’re looking to find your match, but out there online, it’s tricky - how do you know the people you meet are who they say they are? What if they’re only funny over text? What if, in reality, they don’t look like their profile picture? What if their online persona is only just that? Meeting someone in person gives you an immediate sense of whether that person is genuine or not — but online, we become reliant on cues: does my match eat the same types of food as me, watch the same shows, or support the same causes? These are all proxies for that first meeting when your instinct takes over and screens your match. That first meeting is the dirty data detection mechanism of dating. In an online survey, we almost never meet our participants in person. Getting to clean data, therefore requires building mechanisms to screen your ‘matches’ in the same way as you might in the online dating world. Without the proper infrastructure, one is liable to allow in those who are non-genuine.  At this point, you’ve scrolled through your potential matches online, and now it’s time to get serious. You want to begin a conversation, get to know them better, and check that when you actually talk to them, they are who they say they are. Being a researcher myself, I would suggest something scientifically proven to achieve results, such as Arthur Aron’s 36 questions which lead to love . This is also why all our clients benefit from survey questions written by our experienced market research analysts. Without a well-written question, the answer will always appear as if it was dirty data. Surveying and producing data beyond the ‘what’, looking at the ‘how’ We all know that on a date, the ‘how’ the question is answered is as important as the ‘what’ was answered. Enter SlashData’s bespoke survey tool. Whilst the survey is asking questions written by our experienced market research analysts, the survey tool gathers information about how respondents are answering the questions in order to screen for potentially non-genuine ‘matches’. It is this “how” that is critical to our advanced integrated cleansing system. Clean data example 1 Here is a concrete example: when speaking to other researchers, they are often shocked to know that at SlashData, we know exactly how long it took a respondent to answer any given question. The industry standard screen is ‘total time in the survey,’ but this is easily exploitable by respondents. How genuine do you think your date would be, for example, if they spent ten minutes answering your first question about the other dates they had met online but only 10 seconds answering all your other questions about likes, dislikes, family, work, hobbies, hopes and dreams? Their total survey time might be 10 minutes and 30 seconds, yielding a respectable 2min, 37 seconds per question average (over four questions), which, by industry standards, would yield an acceptable ‘total survey time’. Industry standards would tell you your match is ‘clean’, but you’d be right in feeling more than a little dubious.  At SlashData, we would be looking far closer at the time taken to answer each question because, when you’re looking for ‘the one’, it matters. This innovation would not be possible without our survey tool. Clean data example 2 Another example: as your date progresses and you start to learn more it is only human nature to complete a consistency check. Think of it as checking your respondent’s life story. “You’ve made a React app? But you told me you didn’t know JavaScript”. A red flag. A little later, you realise your first date is actually a UI designer. Consistency rules are critical to detecting if the picture the respondent paints stacks up as a whole. For every three questions SlashData typically implements a consistency rule - a large survey may consist of sixty plus validations. These rules allow us to check whether the data we’re getting is reliable. While these rules can be implemented regardless of the survey tool, you should be enquiring if your market research firm takes care to consider and implement these.  Data consistency is key A flip side to consistency is advanced pattern detection. Is your date taking the same to consider each of your questions or are they disinterestedly answering via the easy way out? At SlashData, we’ve seen respondents who have been recruited from top panel providers who nevertheless always choose the third option on the list. Depending on the survey tool your market research company used this may be impossible to detect if the options are randomised - how do you know whether your respondent has scrolled down enough on the screen to grasp the full question, or whether they’re simply picking from options that they can immediately see? These characteristics are critical to know when deciding how trustworthy a respondent is.  After all this, imagine the worst case scenario. Imagine after effort - all that swiping and small talk and screening out the dodgy ones -  you turn up to find that your date is…just here for the food. You’ve been let down and probably feel used. This is an instance where the incentives (a nice meal or cash amount for answering the survey) yield problematic results. In an online environment, it requires industry-leading adaptations to detect repeat responding and bot responses. An advanced cleansing methodology should take into account the device used to answer the survey, whether any proxy, VPN, or IP masking was used — all while not penalising legitimate use of these privacy tools. This requires the complex consideration of response patterns and respondent metadata. Bot and repeat responders are a real problem for clean data — both artificially inflate the number of survey responses as well as add considerable noise to the results. Consistency checks also form an important aspect of checking for this type of response data. Love is a serious matter. Clean data is crucial. Finding a genuine match takes effort. All are as true for screening online data as they are for online dates. To find that the data is ‘analysis ready’ requires a number of mechanisms to sift out a myriad of dodgy dates or dirty data that shouldn’t be underestimated in their importance. Per question speed tests, click pattern detection, consistency checks, AI bot detection, repeat responder detection are just some of the technical achievements of SlashData’s cleansing methodology. SlashData’s bespoke in-house survey tool is best in class in providing these inputs to any cleansing process. Is your data clean? It is critical to ask your market research partner if they have the information to actually ensure this is achieved. If you want to better understand our process or explore a specific topic together, let’s talk . About the author Jed Stephens, Senior Data Scientist Jed has several years of research experience in the academic and industry sectors, mainly focusing on applied statistical research and computational implementations of new statistical methods. He holds an MSc in Statistics. His interest is in turning data into informed, actionable decisions.

Nowadays, developers have an abundance of options to choose from when it comes to finding information about software development and staying up-to-date. Nevertheless, their needs and preferences vary  depending on where they stand on their developer journey and based on a few key characteristics. If you would like to understand what those are and how they affect developer information choices, then keep reading! In this blog post, we draw data and insights from SlashData's 27th Developer Nation survey, which was fielded in Q3 2024 and reached 9k+ developers worldwide. Open source communities and social media are the leading resources where developers go to find information Open source communities (43%) and social media (41%) are the leading resources for developers globally to gather information  and stay up-to-date about software development, according to our data. In comparison, only 3% of developers rely on vendor-organised events, while other resources, such as meetups and hackathons, also see limited (c. 14%) interest among developers. Vendor-driven resources including official websites, newsletters and/or events, are used by ~40% of developers. Experience is a key factor affecting information resources preferences Experience in software development stands out as one of the main factors influencing resource decisions. Indeed, experienced developers  (those with at least 10 years of experience) utilise a more diverse set of resources to get information and stay up-to-date  about software development compared to developers that are just starting out and have less than 2 years of experience (utilising 3.5 resources on average vs 4.3 among experienced). However, it is not only the breadth of resources that varies with the level of experience, but also the channel preferences. For example, experienced developers lean heavily (52% vs 32%) towards vendor-driven resources  to stay up-to-date, whereas nearly half of developers with up to 2 years of experience rely on social media  for their information (vs 31% of more experienced developers).  Experienced developers prefer vendor-driven resources to stay up-to-date. The relatively high use of vendor-driven resources could reflect the fact that experienced developers have more responsibilities than their early-career peers. To explain, the pressure to ensure proper implementation and functionality can lead to a preference for official vendor materials - such as documentation, blogs, and newsletters - since these resources tend to be of higher quality and more reliable. Another reason that official resources are not so favoured among developers with limited experience could be that this kind of resources might demand better understanding of the subject matter and in some cases a deeper level of expertise, something that is also gained through experience. On the other hand, the prevalence of social media among early-career developers, in conjunction with their limited use of a number of fairly established information channels, could be due to a lack of awareness of those resources. For example, Q&A sites and conferences/events which are generally known among developers. Developers with little experience are also more likely to be utilising conversational AI services / chatbots than their more experienced peers (30% vs 22%). For many developers making use of conversational AI services, the combination of real-time interaction, breadth of knowledge and a “safe environment” (as you can ask basic, or even ignorant, questions without fear of judgement) are possibly compelling adoption points. These features, however, don’t seem to be particularly appealing to highly experienced developers. Amongst the rest of information resources, the use of open source communities and Q&A sites, as well as listening to distinguished peers, are top of mind among experienced developers. Information source preferences vary by region Another important separating factor is the region developers are based in. There are certain regions, where reliance on information resources is limited compared with others. For instance, countries in Asia (including China and Japan) exhibit a small degree of resource utilisations, compared with other areas (3.2 on average vs 4.2 excl. Asia). At the same time, developers within each region seem to have varying preferences in terms of which exact types of resources to use. For instance, Western European developers are significantly more likely to attend conferences or events than the rest of their peers (38% vs 25%) , whereas Latin American developers show a much stronger preference for social media and following respected peers than average (59% vs 40%). Similarly, CEMA-based developers are more likely to be using official vendor resources than developers based in other regions (47% vs 40%). In the US, official resources are used by 41% of developers, with community-driven resources (community websites, forums and groups) a close second. Importantly, maybe in light of the ongoing turbulence in the US labour market, a third of US developers prioritise education through attending seminars or pursuing training courses and workshops . Other characteristics affecting information resource selection for software developers   In addition to experience and location, the types of projects that developers work on is another factor affecting the preferences for information resources. More specifically, involvement in different project types might require developers to use different frameworks, technologies and/or programming languages. Thus, depending on the maturity, reliability and accessibility of each tool or service they use, developers may seek to retrieve information from different channels that best match each topic of interest, in order to optimise their level of understanding. For example, our data shows that web and backend developers, as well as those building apps/extensions for 3rd-party ecosystems, behave similarly  not only in terms of their information sources preferences but also towards the number of resources that they use (around 4.2 vs 3.5), when compared with developers in other sectors. Specifically, they stay up to date using a diversified portfolio of resources following both official/vendor-based (such as docs or forums) and non-official/community-based resources (such as Q&A sites or open source communities). So, any effective outreach strategy would likely need to extend beyond official documentation and require at least some level of presence on community-based channels  for these developers.  Another interesting finding is that more than one in three developers involved in ML/AI, embedded software development, or industrial IoT, are attempting to sharpen their skills through seminars, training courses or workshops , compared with just about 20% of AR/VR developers. AR/VR developers used to be more eager for training resources  (~33% of AR/VR developers in Q3 2023), broadly highlighting the current bifurcated state of the ML/AI and AR/VR sectors, as the former continues to see additional investments from companies because of the remarkable progress of generative AI models, and the latter being put somewhat on the backburner. For the vast majority of areas discussed earlier (excl. Latin America), results remain consistent across regions, meaning that these findings cannot be attributed to geographical location effects. More data, more insights! If you’d like to receive more data and insights about where developers go to find information, as well as what types of content they prefer, reach out to us  or explore all our research at the SlashData Research Space . About the author Lazaros Ioannidis Data Analytics Manager Lazaros has extensive experience in data analysis and research, with a background in financial markets. He holds a Master’s in Finance and is a CFA® charterholder. At SlashData he helps clients find data-driven insights to questions they must ask about their business.

Developer Marketing & Relations: The Essential Guide just published its 3rd edition Quick history: In 2018 SlashData decided to publish a book titled “Developer Marketing: The Essential Guide”, seeing the lack of education in developer marketing and relations roles and activities. In that book, industry leaders from the world’s largest companies shared their “things to do and things not to do” experiences. Each chapter had its own author, focusing on the topic they knew best. Fast-forward to today. Thousands of books have already been sold. The industry evolves fast. Not all ground has been covered. Therefore, an updated edition was much needed. This is why the “Developer Marketing & Relations: The Essential Guide – 3rd Edition” has been launched. The 3rd Edition features 9 new chapters and 1 revised chapter since the first 2018 edition. It is a much more complete read and covers most of the topics that dev marketing and DevRel professionals will come across in their professional life. The book can be read cover to cover or readers can pick the topics they are interested in. Each chapter addresses a specific topic written by an author from a major company. Some of the topics are community (+ how to make it inclusive), building personas, building developer programs, developer events, connecting with developers and many more from 24 authors and 17 Industry-Leading companies. The book’s aim is to educate and help professionals push their careers forward. All profits from book sales are donated to worthy organisations: Code.org, Girls Who Code, Black Girls Code and CoderDojo. So far we have donated more than £7,000. To support the dev marketing and DevRel community at challenging times, the book price is reduced by 50% to make it accessible to everyone: $9.99 for the paperback and $4.99 for the digital edition. The book is available through Amazon in Paperback and Kindle  and through the book website in ePub . For more details, see the book website. If you are a journalist and want to spread the word and/or write a review of the book, you can claim a free copy . Companies the book authors work in: Amazon Web Services, apidays, ARM, Atlassian, Facebook, Google, Microsoft, Nutanix, Oracle, Qualcomm, Salesforce, Samsung, SAP, TomTom, Unity, VISA, VMWare #book #developermarketingresources #devrel #developermarketing #resources #devrelresources

The Developer Nation survey If this is the first time you heard about SlashData, I’m happy to share a few quick words. SlashData is a developer research company. Every quarter, SlashData runs a survey on the globe developer audience, to measure the pulse of the developer ecosystem and how they feel about new technologies, tools, platforms, the support from developer programs and more. Following the closing of the survey, our expert analysts work on identifying key trends and translate raw data into actionable insights that professionals and companies addressing a developer audience can utilise to fine-tune their strategy and address developers’ needs and wants. The State of Developer Nation reports SlashData’s Developer Nation survey is the leading research programme on mobile, desktop, industrial IoT, consumer electronics, embedded, third-party app ecosystems, cloud, web, game, AR/VR and machine learning developers, as well as data scientists, tracking developers’ experiences across platforms, technologies, programming languages, app and API categories, revenue models, segments, and regions. The 26th edition of the Developer Nation survey reached more than 10,000 respondents from 135 countries around the world.  Now the results are starting to show. SlashData announces the first 2 of the 6-report series that are becoming publicly available to the world, showcasing and diving into key developer trends for Q1 2024 and beyond. Each report focuses on a specific topic. All reports published under the State of the Developer Nation will be accessible under the freshly launched SlashData Research Space , free to access, view, and download. Developer Research Report: How developers interact with AI technologies Has AI taken over the world? Not yet. However, it has achieved to both take over all our discussions about the future and have 59% of developers use AI tools in their development workflows.  This report investigates the current landscape of developers' work with artificial intelligence (AI) technologies and how this impacts their careers. We start by looking at the ways in which developers work with machine learning (ML)/AI models, tools, APIs, and services and highlight the key differences between professional and amateur developers.  Following this, we focus on professional developers and explore the correlation between working with AI and self-perceived promotion opportunities at their current jobs. Finally, we take a closer look at the developers who are the most likely to express intent of quitting or changing jobs in the next 12 months. “59% of developers use AI tools to help them with their work” To understand the current landscape, we asked developers about the ways in which they work with ML/AI models, tools, APIs, or services. We find that 71% of all developers are actively working with AI in one way or another. workflows, where using chatbots for answers to coding questions (42% of all developers) is the most popular direction.  You can access the full report for free in the SlashData Research Space. Developer Research Report: Sizing programming language communities  Which programming language has the biggest language community? It’s been a non-contest for a while for JavaScript, but it’s always fun to see how the community size has changed. The choice of programming language can greatly influence the roles, projects, and general opportunities that a developer has. Languages are a classic subject of debate and represent the foundation of some of the strongest developer communities. Tracking language use is not just for developers, however; languages and their communities' matter to tool makers too, as they want to ensure they provide the most useful SDKs. In this report, we provide estimates of the number of software developers using various important programming languages, across the globe and all kinds of programmers. We also explore the effect that coding experience has on the adoption of each language. “The JavaScript community grew by 4M users in the last 12 months” Here is a full breakdown of the size of programming languages communities: See how Rust is out to beat records and how the size of communities has changed over time in the full report . Developer Research coming soon As I mentioned before, we have a lot more coming. A combination of deep dives on key topics and free reports for everyone to access. Here are the reports that will be soon available and will complete the State of Developer Nation series:  How and why developers engage with emerging technologies How happy are developers with their jobs? Threats in software supply chain management Profiling of new ML/AI developers If you are looking to address a tailored question or want to take advantage of our expertise in surveying developers, let’s talk . Join our live webinar on June 25 to dive in together on how happy are developers with their jobs. Save your spot . About the author Stathis Georgakopoulos, Product Marketing Manager Always keen to see what’s next in the industry, Stathis is the Product Marketing Manager for SlashData, setting the table and running the marketing activities. He's our go-to guy for all things marketing and does not hide his love for content marketing and creating helpful content.

Games are one of the most popular forms of entertainment and gamers demand high-performance and cutting-edge designs. Performance is also key to developers who work on creating games. Considering the popularity of this entertainment niche, we take a look at how developers work on creating the games; more specifically: game engines. This article is based on “Game Engines and their use in Game Development” Developer Ecosystem Insights . In this report, we explore the state of game development and look at engines and the technologies developers use for creating video games. The embrace of game engines Around 42% of the developer population is involved in the games sector—either as a professional, student, or hobbyist. The developers have a wealth of technologies from which to choose, among which, game engines are the most prevalent. 47% of developers use 3D game engines; while 36% use 2D game engines. Some of these developers use both 3D and 2D, leading to a total usage of 60% of the game developer population. As the name suggests, the difference between 2D and 3D games lies in the number of axes of motion available to the players. In 2D games, there is no perspective, fewer possible movements, and therefore, fewer interactions with other characters or objects in the game—resulting in these games being typically less complex than 3D games. Do you need specific data on developers or the technology landscape? Contact us , and we will get these for you. 60% of game developers use game engines As recently as 2017, our data showed that developers used 2D and 3D game engines equally, with 44% and 45% usage respectively. In subsequent years, however, the chasm between the two has widened — by 11 percentage points. Overall, a similar percentage of developers are using game engines: 63% in Q2 2017, compared to 60% in Q1 2021. However, far fewer developers are now only developing games with 2D engines, which is down 7 percentage points from Q2 2017. On the other end of the scale, sole usage of 3D game engines is up 5 percentage points. The large rise in 3D usage is due, in part, to the impact of VR gaming; as well as the dominance of smartphone and native desktop games which, when coupled with modern powerful hardware and larger screen sizes, encourage increases in game complexity. The platforms targeted by developers who use game engines will be explored further in chapter three. Uneasy rests the head that wears the crown Unity has the largest share of the game engine market: 38% of game developers who use game engines use Unity as their primary engine. The next most popular game engine, Unreal Engine, has 15% usage as a primary engine—much lower than Unity. Unity’s dominance is clear, but the gap between Unity and its competitors is closing. Overall usage of Unreal Engine—both as a primary and an ‘also using’ game engine—is currently at 43%. In Q2 2017, it was at 20%. Unreal Engine’s focus on higher-end graphics and performance allows it to fill an important segment—their latest release of UE5 looks poised to continue this trend—but the engine is harder to use than Unity and is accessible on fewer platforms, somewhat restricting mass adoption. On the other hand, Unity remains king of the gaming market because it has succeeded in doing many things well: it is considered the best engine for mobile, excels in, and has a much larger and focussed tool-set for 2D games.49% of developers using Unity use Unreal Engine; while 76% of those using Unreal Engine find themselves using Unity. Traditionally, Unity’s versatility has not been easily replicated, but developers are currently finding success in combining game engines to access the unique advantages of each. Typically, developers use more than one game engine: 64% of developers using game engines are using two or more, and 38% use three or more . Developers using offerings from vendors with a smaller market share tend to use multiple game engines at the same time. The smaller engines often lack all the capabilities of Unity and Unreal Engine, leading to game developers mixing engines to find their optimal usage combinations. These engines’ market share comes predominantly from their role as additional game engines. For example, Godot has a 20% usage as a game engine which developers are also using, but only a 5% usage as a primary game engine. The reasons for the popularity of game engines are many, but one of them is the undeniable fact that game engines can shorten production time and costs. This makes this kind of technology more appealing than ever to a wide range of developers, ranging from amateurs to professionals, who are trying to gain a foothold in the industry. What are your thoughts? This data is just the tip of the iceberg or in gaming terms – a small tutorial or walkthrough. We have a lot more insights and data to share with you on games, including: where game developers work, how and where to reach them and even a forecast of their population for 2023. Access all data here We can go on this adventure together. Contact us

SlashData is a market research company. However, you do not need a market research company to tell you how much the technology space has changed in the past 5 years. Stories from post-pandemic times seem like centuries ago, yet they are not. It was just 4 years ago when the peak pandemic response was an influx of developers in the industry, creating products and services that could help transfer everyday life online. Then, Artificial Intelligence became an everyday topic. Every company is now becoming an AI-enabled company.  And these are just the last 4 years.  How do we respond to the changing technology industry? Being a market research company, we show what we see. Right now, what we see is that we can help technology leaders navigate through these times in new ways. With that in mind, we have taken significant steps to improve the value of our services to our customers.  “We are moving beyond developers, adding, decision-makers and users in the technology space, to the list of audiences we research.  The most important decision we announce today is that we are extending the audiences we research to beyond developers. Our research will also address decision-makers and users within the technology space and dive into understanding their behaviour and preferences.  Adding to what we are researching, not removing For almost 20 years, we have been known for our expertise in addressing software developer audiences and their needs. We will keep doing that. SlashData will always support software developer market research needs - our flagship. Our Developer Nation community will continue to be important to us and we continue our investments and relationships with developers globally. Decision-making has become more centralised, especially in the enterprise space. As a result, we have received increasing support requests to understand more about the people who identify as more than “coders.” This includes citizen developers, C-level, Senior, and Director-level decision-makers, and even retail users.  So, we are embracing the change. From now on, SlashData will be able to offer market insights on: CEOs, CTOs and C-level executives Citizen developers Senior and director-level decision-makers Retail users Broader technology audiences This way, we can share insights on the audiences beyond “software developers”. Audiences that interact and can bring change in the industry.   Dive into the full list of services we can offer. Get more from SlashData, your trusted market research experts Three years ago, we introduced custom research services: Custom Quantitative , Competitive Market Research , and Qualitative research . Since then, we’ve built a team of analysts, market research experts, and diligent project managers. Our workflow provides the infrastructure to run customised projects as smoothly as possible.  “Our in-house survey software and ML-powered methodology deliver cleaner than ever data” Going even further, our in-house survey software, together with our Machine Learning-powered best-in-class cleansing methodology, delivers data cleaner than ever and cleaner than any market research company out there can deliver.  We use it and can vouch for it.  The real question now is: what questions are you eager to answer? Let’s talk .  About the author Moschoula Kramvousanou is the CEO of SlashData. She leads the team and navigates the company through a rapidly changing space. She has been with SlashData for more than seven years, and took over as the new CEO in 2022.

Finding a balance between core business and serving your industry and the professionals through your expertise pro bono has been a challenge for many companies. Giving back to the community is hardwired into our DNA. The most obvious examples are the 27+ editions of our State of the Developer Nation reports, showcasing the key, emerging developer trends for over 15 years and a wide collection of free industry analysis reports, openly available on our Research Space. Then, of course, we also had DevRelX. How DevRelX started DevRelX did not start as a standalone effort. Around 2017, we had long worked with developer marketing and relations professionals, helping them understand developers through our research. At the time, DevRel was a very niche, emerging role, in need of a definition and a standardised set of responsibilities and requirements for the role. Naturally, this lack of given requirements created a lack of definition for the expertise required for the roles. Was it a marketing role? For some companies, yes, for others not at all. Was it a product role? For some companies, yes, for others not at all. You can see what I’m getting at. How do you know what you need to be proficient at in such a fluid role? It was our founder, Andreas Constantinou, along with the attendees of the Future Developer Summit and Nicolas Sauvage, who got together to gather the leading experts in the industry and create a book that would help newcomers in the field and seasoned veterans understand what is required from a developer marketing or DevRel pro. You can find more information on the book here . This book was the first resource offered. However, books are much slower to update with new information as it comes along. This is why we started a podcast series. Also, we ran webinars to present new data and trends as they came along. Now, all these resources were scattered around the web, but they were all addressed to the same professional struggling existentially. It was only natural that the handsome geniuses behind SlashData’s marketing team (myself included) decided to have all these resources in one place. And how about adding a few more stuff? Like job openings and an events calendar. Thus, DevRelX was born. The DevRelX Community DevRelX started as a hub. A one-stop shop selling nothing. Instead, sharing freely free resources. It was constantly updated with new content, resources, interviews and videos. Something was missing, especially since a pandemic had joined the equation. It was missing the human factor. People could visit the website to get answers, but could they learn from each other or find solutions to common problems? Not really. What we needed was…a community! A place for people to come together, learn from each other and connect. We provided the space and shared data and insights - what we know best. The community was growing as more people joined and shared resources. It became a place for learning and interaction. The DevRelX Summit How about we bring everyone together for an event, then? We had been hosting the Future Developer Summit as a private, in-person event for years. Now that the community was growing and events were going online, there was no sense in not opening it up for those hungry to learn and connect. Thus , the  DevRelX summit  was born, bringing together people who had knowledge to share, wanted to meet each other, chat, and have a fun, learning day. You can catch up on the Summit presentations on our YouTube channel: Full 2023 event "Driving impact at the Age of AI" Full 2022 event "Elevate the DevRel community together" The Closing of DevRelX “Wow, you make everything sound so nice and movie-like; why is the community closing?” Awww, I am much flattered, but if there’s one thing I have learned about community building, it is this: it needs to be a strategic priority, and it needs people to help it grow and evolve into what the community needs, and not what the company supporting it needs it to be. We are also evolving; we are growing to take on projects from “the road not taken”. This evolution forces us to take steps that bring us farther away from the core of the DevRelX community and its whole essence. SlashData will focus on what we know best: researching and understanding the world as it changes. Then, producing insights and transforming data in a way that helps everyone else understand it, too. Rest assured that we will continue to serve the industry through our data. We will continue to be a resource to help you and the leaders in the technology space get the data and insights they need for strategic decision-making. Come to us with your questions and challenges; we will always have an open door to explore how we can help.  We owe a massive “thank you” to everyone who took this journey with us. We are grateful for the lessons learned and the people we met.  See you all out there. PS. Not all is lost. We will keep sharing and updating the most important resources that our community loves: DevRelX resources that will still remain available Developer Marketing & Relations: The Essential Guide book The DevRelX podcast WeKnowDevelopers webinars The DevRelX newsletter will continue bringing joy to its subscribers until the end of the year (at the very least). Then, it will be moved to the SlashData newsletter . Data & Insights SlashData Free Reports Research Space Developer Marketing & Relations Communities DevMarketing Community DevRel Collective

35% of DevOps professionals are affected by vulnerabilities and learning is the top goal for new developers The full picture is now complete. With the latest addition of the final 2 industry reports, the 6-report series puzzle is now complete and all the 2024 insights on software developer trends are available. You can go back and have a look at the first and second waves which kicked-off and continued the series. Or keep reading to see what new insights we have in store for you. Release 1: 59% of developers use AI tools & 25.2M JavaScript users  Release 2: AR & VR developers are the happiest, Blockchain engagement struggles The final release focuses on: Understanding the new Machine Learning and Artificial Intelligence software developer profiles  Exploring the practices and threats in Software Supply Chain Management Every report is available in the SlashData Research Space and you can quickly access the one that interests you at the index at the end of this post .  Let’s explore together the latest insights software developers have to offer. Developer Research Report: Profiling on new ML/AI developers  Who are the developers who just started their journey in ML/AI development? Just as the internet once revolutionised communication and smartphones transformed our daily lives, today, ML and AI are at the forefront of the technological frontier. This transition is not just a tale of their persistent march forward but also the people behind it. In order to understand the people’s potential influence on the field of ML/AI, in this report we will examine the backgrounds of developers who are new to this field. 76% of newcomers to ML/AI have less than five years of experience in software development The majority of newcomers to ML/AI are those with less than five years of experience in software development, accounting for 76% of the total, substantially higher than the average of other sectors (61%). On the other hand, only 9% of beginners in ML/AI have more than 15 years of experience in software development, compared to 15% of the industry average, further highlighting the field’s appeal to newcomers in the world of development. Region, programming language Looking at the share of ML/AI beginners within each region, we find that the vast majority of ML/AI developers in South Asia are beginners in the field (90%). This likely stems from this region having a significantly higher concentration of students in ML/AI compared to other regions (66% vs 36% at a global average). As we noted above, a fair  share of ML/AI developers are students. To understand how beginners in the field of ML/AI behave, it’s also important to compare them with their more experienced counterparts – developers with three or more years of experience. Machine learning and Artificial intelligence developers’ goals Beginners’ goals in ML/AI derive mainly from personal needs and interests, with the goal for 27% of them being to learn or gain experience in order to maximise future opportunities, compared to 16% of experienced ML/AI developers. On the other hand, experienced developers show a stronger orientation towards pragmatic goals, with a fifth of them (22%) focused on increasing organisational efficiency or reducing costs, as opposed to 15% of beginners. What else do you want to know about new ML/AI developers? Access the answers in the full free industry report .  Developer Research Report: Threats in software supply chain management Which are the main risks for organisations that build and maintain software? Software security and reliability are crucial aspects for organisations, which employ various practices and strategies to ensure them. However, despite best efforts, DevOps teams still face threats related to software supply chain management. Types of threats faced by DevOps teams Only a third of DevOps professionals working for organisations report facing no threats in the past year. In this report we focus on the 45% of DevOps professionals who are aware that their organisation has faced software supply chain security threats in the past 12 months.  Third-party-related threats are the most common software supply chain threats faced by organisations Third-party-related threats emerge as the most common type among these developers, with 35% experiencing software vulnerabilities in third-party libraries or components in the last year. Additionally, 26% of developers report threats from unstable third-party services or APIs. This highlights the importance of thorough due diligence before integrating third-party providers and the need for ongoing monitoring after integration. Alarmingly, only 17% of DevOps professionals report that their organisation performs risk assessments of third-party vendors, a practice that could help reduce exposure to these prevalent threats. As organisations grow in size, they become more vulnerable to certain types of software supply chain threats While most software supply chain threats don’t show a strong relationship with organisation size, we find that the incidence of some of the most common threats tends to increase as organisations become larger, in some cases nearly doubling. For DevOps professionals whose organisations experienced software supply chain threats in the past year, and they are aware of them, 31% of those working for small businesses (2-50 employees) report software vulnerabilities in third-party libraries or components. However, this rises to 41% among developers in large enterprises (1,000+ employees). Larger organisations likely integrate and depend on more third-party components due to the scale and complexity of their operations, increasing exposure to these vulnerabilities. Hence, performing risk assessments of third-party vendors must be a priority for larger organisations wishing to secure their software supply chain. The incidence of ransomware attacks nearly doubles for large organisations In addition to third-party risks, the occurrence of supply chain attacks also increases, from 12% in small businesses to 20% in large enterprises. Similarly, large enterprises have a greater attack surface due to more complex software supply chains with more dependencies and integration points. Therefore, it is recommended to scan dependencies on an ongoing basis – a practice that only 20% of DevOps professionals report that their organisation is doing – especially as organisations increase the number of dependencies and complexity of their software supply chain. Ransomware attacks targeting software or code repositories are another area of concern that scales with organisation size. They impact 11% of DevOps professionals in small businesses and this almost doubles to 21% among those at large organisations, likely because of the potential of higher ransom payouts. In the full report we also look at the substantial difference between industries. Access the  full report in the SlashData Research Space.  The full picture  The puzzle is complete. All reports in the State of the Developer Nation series are now available. You can access all reports at the SlashData Research Space. Pick the one you want to dive in first:  Profiling of new ML/AI developers Threats in software supply chain management  How and why developers engage with emerging technologies How happy are developers with their jobs? Sizing programming language communities How developers interact with AI technologies If you are looking to address a tailored question or want to take advantage of our expertise in surveying developers, let’s talk . The Developer Nation survey If this is the first time you heard about SlashData, I’m happy to share a few quick words. SlashData is a developer research company. Every quarter, SlashData runs a survey on the globe developer audience, to measure the pulse of the developer ecosystem and how they feel about new technologies, tools, platforms, the support from developer programs and more. Following the closing of the survey, our expert analysts work on identifying key trends and translate raw data into actionable insights that professionals and companies addressing a developer audience can utilise to fine-tune their strategy and address developers’ needs and wants.  Are you a software developer? Take the survey . About the author Stathis Georgakopoulos, Product Marketing Manager Always keen to see what’s next in the industry, Stathis is the Product Marketing Manager for SlashData, setting the table and running the marketing activities. He's our go-to guy for all things marketing and does not hide his love for content marketing and creating helpful content.

How are developers engaging with emerging technologies? Are developers happy in their jobs? Welcome to the second instalment of our State of the Developer Nation report series.  If you missed the first part where we discuss the size of programming language communities and how developers are working with AI models and tools, you can find it here .  The 26th edition of the Developer Nation survey reached more than 10,000 respondents from 135 countries around the world.  The second wave of the 6 free report series is here with 2 more additions:  Software developer happiness at work  Emerging technologies adoption.  Sounds fun? Let’s get into the details.  Quick reminder: All reports are accessible under the freshly launched SlashData Research Space , free to access, view, and download. Developer Research Report: How and why developers engage with emerging technologies While artificial intelligence (AI) is at the centre of every newly-introduced innovation, AI is not the only technology making waves. Blockchain and metaverse technologies continue to promise revolutions in many commercial areas, whilst Wi-Fi sensing, digital twins, and fog/edge have wider industrial and consumer applications. As part of SlashData’s commitment to understanding the landscape of software development, we have tracked developers' engagement with and adoption of many different emerging technologies across 12 surveys over the last six years, adding new technologies as they become relevant and sunsetting others from the list as they become established. From developers’ interest in these technologies, we ascertain the levels of engagement and adoption. We consider a developer to be engaged with a technology if they report being interested in it, learning about it, or working on it. The adoption rate of a technology is the proportion of engaged developers currently working on it. To better understand the engagement and adoption rates for these technologies on a macro level, we have created four quadrants, defined by where each technology sits in the current software landscape, compared to the median adoption and engagement value Has AI taken over the world? Not yet. However, it has achieved to both take over all our discussions about the future and have 59% of developers use AI tools in their development workflows.  Engagement with blockchain technologies has been volatile Four technologies have consistently failed to engage developers: digital twin, haptic feedback, fog/edge computing, and DNA computing/storage, and not all for the same reasons. Digital twin and fog/edge computing both have primarily industrial applications and, therefore, fail to capture the imaginations of many developers, whilst DNA computing is still a long way from maturity. Haptic feedback, on the other hand, currently has limited use cases outside of gaming and accessibility applications. Engagement with blockchain technologies, including cryptocurrencies, NFTs, and other applications, has been very volatile. It’s these technologies that the rest of the report addresses. Access the full free report here . Developer Research Report: How happy are developers with their jobs?  Significant employee turnover can cripple firms. Furthermore, as most of us can attest, applying to jobs is a huge pain and typically not something most professionals aspire to undertake regularly. Hence, it is in the interest of both employees and employers to seek and create an environment where company personnel are happy and satisfied. How happy are developers with their jobs?  While what constitutes satisfaction can be difficult to define, in this report, we examine how satisfied developers are with their jobs using a validated measure of job satisfaction incorporated in the latest edition of our Developer Nation survey. We assess how job satisfaction is associated with future career plans –i.e. changing jobs –and examine how various factors and contexts affect satisfaction. How important each item is will vary based on each individual. However, the fact that roughly a quarter of developers feel they are missing opportunities for promotion, fair compensation, and stimulation in their job, is noteworthy. Going out of its way to provide opportunities for promotion, for example, can distinguish a company from the competition.  To ensure that they can attract and retain talented personnel, most successful companies aim to foster environments where employees feel valued and supported and have a future. To measure this, we used questions from the validated Job Descriptive Index  and asked developers worldwide to respond to these questions to measure their satisfaction with their current role. By and large, we find that developers consider their job worthwhile (79%) and that it gives them a sense of accomplishment (75%). Meanwhile, one in four (26%) developers do not believe they are compensated fairly and a similar proportion don't feel they have opportunities for promotion or feel stimulated. How important each item is will vary based on each individual. However, the fact that roughly a quarter of developers feel they are missing opportunities for promotion, fair compensation, and stimulation in their job, is noteworthy. Going out of its way to provide opportunities for promotion, for example, can distinguish a company from the competition. Those working in AR/VR are the most satisfied professional developers In the full report we also look at: Developers’ overall satisfaction and satisfaction by roles.  Satisfaction and job-seeking Job-seeking and developers’ age You can access the full report at the SlashData Research Space .  We recently hosted a live session with analyst Brayton Noll to discuss the findings and developer happiness at work. More software developer research coming soon This was part 2 of the 6-report series. 2 more reports are already available and the final additions are coming in the next few weeks.  Make sure to subscribe to the SlashData newsletter  to be notified first.  Here are the reports that will be soon available and will complete the State of Developer Nation series:  Sizing programming language communities How developers interact with AI technologies Threats in software supply chain management (August) Profiling of new ML/AI developers (August) If you are looking to address a tailored question or want to take advantage of our expertise in surveying developers, let’s talk . The Developer Nation survey If this is the first time you heard about SlashData, I’m happy to share a few quick words. SlashData is a developer research company. Every quarter, SlashData runs a survey on the globe developer audience, to measure the pulse of the developer ecosystem and how they feel about new technologies, tools, platforms, the support from developer programs and more. Following the closing of the survey, our expert analysts work on identifying key trends and translate raw data into actionable insights that professionals and companies addressing a developer audience can utilise to fine-tune their strategy and address developers’ needs and wants.  Are you a software developer? Take the survey . The State of Developer Nation reports SlashData’s Developer Nation survey is the leading research programme on mobile, desktop, industrial IoT, consumer electronics, embedded, third-party app ecosystems, cloud, web, game, AR/VR and machine learning developers, as well as data scientists, tracking developers’ experiences across platforms, technologies, programming languages, app and API categories, revenue models, segments, and regions. About the author Stathis Georgakopoulos, Product Marketing Manager Always keen to see what’s next in the industry, Stathis is the Product Marketing Manager for SlashData, setting the table and running the marketing activities. He's our go-to guy for all things marketing and does not hide his love for content marketing and creating helpful content.

DevOps as an operational philosophy emphasises collaboration between development and operations teams to automate and optimise production - thereby increasing productivity. Developer teams of all sizes can find useful principles and practices embedded in the DevOps tradition. However, not all practices are equally appropriate for all situations and unselective implementation can have minimal effects and lead to overcomplicated processes. Determining which of these practices is appropriate for a specific team is not a straightforward task. In late 2023 we published a report on developer productivity where we used multiple measurements and metrics to examine what factors were associated with productive software development teams. In this report, we used data from our Developer Nation survey run in Q3, 2023 and found that productivity can be extremely context-dependent. Around this time, Google published its 2023 State of DevOps report that additionally highlighted how the productivity of teams is contingent on several factors. The focus of this blog post is to offer insight as to how select DevOps technologies are associated with productivity across various developer team sizes. Below we first outline how we quantify productivity, and then delve into how contextual factors such as team size, and tool/technology use affect developer productivity. How we measure developer productivity In both aforementioned reports – SlashData’s productivity report and Google’s DevOps report – the DORA metrics were used, among others, as a measure of developer productivity. Specifically, the DORA metrics measure software delivery performance and while the metric should not be used to directly compare two distinct teams, it can act as a useful benchmark to offer insight into how successful teams working in similar contexts are organising their workflow. More information about DORA metrics can be found at the end of this blog post. How developer team size and technology choices affect software delivery performance We select six DevOps technologies that vary in application and popularity and explore how their use in developer teams of different sizes is associated with software delivery performance. We independently model, by team size, how the use of the aforementioned technologies affects the odds (ratio of the probabilities) of a developer having better software delivery performance (compared to those who don't use the technology). To acknowledge varying contexts, we account for different experience levels, geographical locations, and the type of projects developers are involved in within all the models. We segment professional developers involved in at least one DevOps activity and working at companies with at least one other developer into three groups: Small teams (5 or fewer developers) Medium teams (6 - 50 developers) Large teams (more than 50 developers) For several of the DevOps technologies, there is not a significant difference and/or distinct pattern across team sizes and for all but one technology (discussed below) the odds are likely positive or have no tangible effect. Examining the top technology, the use of agile project management tools is significantly associated with increased odds of having superior software delivery performance across teams of all sizes. Likewise, the use of managed CI/CD services and self-hosted CI/CD tools also generally improves the odds of a team being productive. The use of agile project management tools is significantly associated with greater odds of having greater software delivery performance across teams of all sizes. The three remaining technologies – incident management tools, application performance monitoring/observability tools, and collaboration/ knowledge sharing tools – have a greater impact on increased productivity if the team is larger. These improved odds are significantly higher when the team is large and has more than 50 developers. Hence, vendors of incident management tools, application performance monitoring/ observability tools, and collaboration/knowledge-sharing tools should take note of these results and highlight this in their messaging when targeting enterprise-size developer teams. It is in these larger teams where their product will have the greatest impact. Taking incident management tools (applications designed to support developer teams in managing unexpected circumstances) as an example, we see the biggest difference across team sizes. For small teams, according to our analysis, the use of this technology slightly decreases the odds of being as productive in software delivery. This is likely because if a team of five or fewer developers require an incident management tool, they are either tackling very complex projects or have possibly over-complicated their workflow and services. Both of which would necessitate more time for software delivery. Vendors of incident management, application performance monitoring/observability, and collaboration/knowledge-sharing tools, when targeting enterprise-size developer teams should emphasize that their product has significant odds of positively impacting the team's software delivery performance. For larger teams, however, we see the tremendous positive impact that incident management tools have on the odds of being more productive. Larger teams typically work on more extensive and complex projects, resulting in a higher likelihood of encountering incidents. Incident management tools help in handling the increased volume and intricacy of issues by providing a structured and scalable approach. This is clearly shown in our analysis, where the use of this tool significantly increases the odds (by 1.82 times) of developers and their teams having better software delivery performance compared to other large teams that do not use this technology. In this blog post, we examined how the use of various DevOps technologies correlates with software delivery performance based on team size. If you are interested in other tools or technologies or other team differences get in touch with us! We would be happy to delve into the data with you. Extra Information: Consolidated DORA metrics Below are the four DORA metrics and the classification of exceptional, good, intermediate, and poor performers. Using these metrics, a practitioner can be classed, for example, as exceptional in terms of lead times but a poor performer in deployment. Our consolidated classification provides a more general overview by awarding points based on the category that a practitioner falls into for each of the metrics. The maximum score for a practitioner is 16, and the lowest is 4. The following cumulative scores then characterise our high, medium, and low performer categories: Low = 4-7 points; Medium = 8-12 points; High = 13-16 points.

The game developers population forecast We just published a new report that looks into the people at the heart of game development. The Game Developer Population Forecast provides data and insights into trends that allow you to estimate the addressable market for game software development technologies, languages, and target groups. In the report, we estimate the number of game developers globally, how many are professionals, what types of organisations they work for, and where they are located. We additionally investigate the size of the addressable market for specific game platforms, programming languages, and technologies, and segment by experience level and company size. How we count the how many developers are there To count developers, we use an independent, bottom-up methodology. The data we use to arrive at the estimates in this report comes from: Reliably measured numbers of developers or direct indicators of their activity: Github accounts and repositories, Stack Overflow accounts, and employment statistics from the USA and the European Union. Our proprietary Developer Nation survey data on developers from around the world. For this report, we use data from 20,000+ game developers across six consecutive surveys. We then measure the global population of active software developers, including serious hobbyists and students. Within our surveys, we give developers the option to self-identify as "active" in certain software sectors, or as using specific technologies. The growth of game developers by professional status Here's our latest estimate on game developers: In Q1 2024, there are 11.1 million game developers How many of these are professionals? Have professionals and hobbyists grown the same over the past years? You can find all answers to these questions in this graph, taken directly from the full report's pages. Answers covered in the game developer population forecast The full report sheds light to more questions that professionals in developer-first or developer-plus companies engaging game developers have. Some of these questions are: How many game developers are there? How many professional game developers are there across the globe and where are they working? What technologies and programming languages are being used by game developers? How is the level of experience in the game developer community changing? You can see a full preview of the report in our Research Space. Are you engaging game developers? Here is everything we have available on game developers. Do you have any specific questions that you want answered? Let's talk. About the author Stathis Georgakopoulos, Product Marketing Manager Always keen to see what’s next in the industry, Stathis is the Product Marketing Manager for SlashData, setting the table and running the marketing activities. He's our go-to guy for all things marketing and does not hide his love for content marketing and creating helpful content.