Recently, the Linux Foundation announced its intent to form the Developer Relations Foundation to support people in that career.

On the most recent episode of our podcast, we interviewed Stacey Kruczek, director of developer relations at Aerospike and steering committee member of the Developer Relations Foundation, to learn more.

Here is an edited and abridged version of that conversation.

How do you define the role of developer relations?

Developer relations is really the practice of elevating developers and their world. We’re all about helping the developers, helping them solve their problems. But more importantly, part of my role and the importance of it is also to be the voice of the community to the company. So it’s important for us to be able to recognize that the developers are the influencers of much of our technology business today, and so my role as a DevRel lead is to help elevate them and share in their pains, glories and challenges, and help them solve those issues, if they have them.

I always like to sort of describe myself as the PR person for developers, if you will, promoting them, promoting the importance of them, their value to the organization and their value to the community.

Why did the Linux Foundation create the Developer Relations Foundation? Why did they see a need for that?

The importance of developer relations is really to add business value. When you think about the journey of a developer and when they first experience your company, your products, your tools, and solutions, they’re really starting their discovery period. At first, they’re discovering what your tools are, the advantages of them, and as a DevRel leader, it’s my job basically, to help them along that journey. I help them down the path from discovery to engaging with us to sharing their feedback.

So it’s really about the developer being the influencer. And I’ve seen a lot of this personally at Aerospike, and we’re having a lot of conversations with developers and architects about evaluating our tools, our products, providing us feedback, and even coming in and evaluating our community.

And oftentimes, more than not, there’s a misunderstanding of what DevRel is. Each company has their own placement of a DevRel team or practice that really depends on the needs of the company, and that can be customized to them, but from a developer relations standpoint, it’s still all one in the same. 

And the major benefit of forming this foundation is to create some synergy and some common best practices, common terms that we all can share as a wider global community, to elevate the practice and practitioners in DevRel. So the major benefit of forming the foundation, why we did this is that it’s really to promote participatory governance. That means that no single company can monopolize the project or dictate its direction.

So our focus is on that community-driven governance. We’re taking and absorbing all the feedback of all of the DevRel practitioners across the globe. We’re ensuring that all of their contributions are reviewed, they’re all based on their merit and their expertise, and moreover, we’re creating a trusted, credible, and export resource to all of those professionals in the field. It will help promote best practices, what it means for businesses, and how we can add value.

What can DevRels do to elevate the development profession?

So really we have to look first at the challenges that some of this has faced. And I just want to tie in my own personal experience with this. I’ve been in this for over a decade. And when I initially came in, I came in as a technical marketer to a developer relations team, and I had the experience of sitting with five experienced engineers on the Android and Google development platform. And then we actually sat in the sea of engineers. So I always like to attribute my role as being the loan marketer in the sea of engineers, and they kind of kept me afloat. 

The beauty of that relationship, and what it really gave me, personally, was just really inspiration. There was a lot of collaboration. I became their voice to the broader customer partner ISV community, but more importantly to all the developers, I was helping them elevate their expertise. 

I think at that point, DevRel was sort of a newer thing. It had been around for a while, but people really didn’t understand it. I was thankful during my time at Zebra Technologies that we had that experience with them. It ignited my passion for helping developers in the long term in DevRel, and I soon moved into creating the first developer marketing strategy for that company, and then I really wanted to take on more as an individual for that, in terms of helping elevate DevRel as a practice, because dev marketing is just one component of it. 

When we look at it long term, there’s a reason for having a foundation. There’s actually a DevRel survey that just came out, and a large portion of developer advocates who responded to the survey stated that they felt like they needed a professional practice in one space, one community of where they could go to and share their experiences, but also learn from others. Because a lot of what I’ve learned in DevRel, I’ve learned from peers in the industry, and that’s been so important and so crucial for my learning and my development. So it’s not only the engineers, it’s also the other DevRel professionals. And when we were dealing with Covid for so long, I was fortunate to be included in many groups of DevRel advocates and professionals that would hop onto a Slack or a Discord channel, and we’d just start talking about the challenges of DevRel and how we were all dealing with it, especially during that challenging time. 

What emerged from that was the thought that we really need a foundation. We need an association of some sort that’s inclusive, and it includes our wider developer relations community and allows them a voice to be heard. 

We all bring our own personal expertise into it, but what we also bring is the ability to share with each other and collaborate. And that’s the beauty of DevRel. That’s what I love so much about it.

What is the ultimate goal, beyond bringing the community of DevRel together and having people share and exchange ideas? 

The broader developer relations umbrella as I’ve experienced it, we’re talking about community at the very core. You need to have a community in order to grow your business. And so that’s where it really starts. And then the various branches of that are related to developer experience. What kind of experience are they having? Are your tech docs easy for them to find? From a developer marketing standpoint, are we communicating the right messages? Are they technical? Are they authentic? And then we talk about developer success and education. We want to educate them just as much as they educate us. We want to make sure that we’re providing them the right tools, and we’re setting them up for success. 

And so these various components under the DevRel umbrella become so important. This foundation will essentially help define some of these areas and provide more clarity, but being that it’s open to the community, and it’s a community-driven project, we’re going to get varying viewpoints and opinions and it’s going to create this, this awesome catalog of knowledge. And then, by partnering with the Linux Foundation, they offer global credibility and they offer this robust governance structure that supports long term sustainability. 

Now, we’re an intent to form a DevRel foundation, so we’re still in the area of exploration and learning, and we do have a mission statement that we’ve created in collaboration with the community that we’ve shared. Everything is open and out there. We have a wiki page, we have a GitHub, and we welcome anybody to participate and communicate with us. 

We have weekly community calls across the globe, and many developer relations professionals are joining us on those calls and sharing their experience and their knowledge. We assign topics for the week, we review our proposals of how this will roll out, and the idea is that as a steering committee, we’re there to help guide the ship, we’re guiding the boat through the sea, and we’re going to help them stay on target, if you will. 

The project itself, the foundation, it really is going to rely on contributions from the community, individuals, supporters of the organization, and they’re going to provide expertise, guidance and content.

The post Q&A: Why the Developer Relations Foundation is forming appeared first on SD Times.

According to the project maintainers, there can be difficulty in handing off projects from designers to developers because they are often using different tools and the vision of the project may get lost along the way. 

In Penpot, the interfaces that designers create get expressed as code so that developers can pick up right from where the designers left off, eliminating some of those struggles that are common to the hand off process. 

It features a web-based multiplayer mode that allows for real-time collaboration because multiple people can be working within the same design at once. There is also a whiteboard feature that allows designers and developers to come together to brainstorm, test ideas, and organize workshops. 

Designers can also save their design elements and components so that they can easily be reused, allowing for better consistency between projects. 

Other features include the ability to add custom fonts, unlimited teams and projects, a presentation mode for sharing ideas, and support for over 30 different languages. 

As of August 2024, the project has 31K stars on GitHub and has over 150 developers contributing to it. It is used by companies like Cisco, Mozilla, and NYU. 

It was created by Kaleidos, which was originally a consulting firm, but has since pivoted to fully support the development and growth of Penpot. 

Read about other recent Open-Source Projects of the Week:

• Dioptra
• Semantic Kernel’s Agent Framework
• Hoppscotch

The post Penpot – SD Times Open Source Project of the Week appeared first on SD Times.

According to Gartner, 30 percent of AI projects will be abandoned by the end of 2025 thanks to factors such as poor data quality, escalating costs and a lack of business value. Data scientists are pessimistic, too, expecting just 22 percent of their projects to make it through to deployment.

Much of the debate on turning these poor figures around by delivering better AI has focused on technology but little attention has been paid to improving the relationship between those scientists and engineers responsible for producing AI in the first place.

This is surprising because although both are crucial to AI, their working practices don’t exactly align — in fact they can be downright incompatible. Failing to resolve these differences can scupper project delivery, jeopardize data security and threaten to break machine learning models in production.

Data scientists and software engineers need a better working relationship – but what does that look like and how do we achieve it?

DevOps forgot the data science people

As cloud has burgeoned, much of the industry’s attention has been devoted to bringing together developers and operations to make software delivery and lifecycle management more predictable and improve build quality. 

Data scientists, during this time, have flown under the radar. Drafted into enterprise IT to work on AI projects, they are joining an environment that’s not quite ready for them.

What do I mean? Data scientists have a broad remit, taking a research-driven approach to solving business- and domain-level challenges through data manipulation and analysis. They operate outside the software delivery lifecycle using special tools and test platforms to build models using a subset of languages employed by developers.

Software engineering, while a creative and problem-solving discipline, takes a different approach. Engineers are delivery-focused and tackle jobs in priority order with results delivered in sprints to hit specific goals. Tool chains built on shared workflows are integrated and automated for team-based collaboration and communication.

These differences have bred friction in four notable areas:

1. Process. Data scientists’ longer cycles don’t fit neatly into the process- and priority-driven flow of Agile. Accomplish five tasks in two days or deliver a new release every few hours? Such targets run counter to the nature of data science and failure to accommodate this will soon see the data science and software engineering wheels on an AI running out of sync.
2. Deployment. Automated delivery is a key tenet of Agile that’s eliminated the problems of manual delivery in large and complex cloud-based environments and helps ensure uptime. But a deployment target of, say, 15-30 minutes cannot work for today’s large and data-heavy LLMs. Deployment of one to two hours is more like it — but this is an unacceptable length of time for a service to go offline. Push that and you will break the model.
3. Lifecycle. Data scientists using their own tools and build processes breed machine learning model code that lives outside the shared repo where it would be inspected and understood by the engineering team. It can fly under the radar of Quality Assurance. This is a fast-track to black-box AI, where engineers cannot explain the code to identify and fix problems, nor undertake meaningful updates and lifecycle management downstream.
4. Data Security. There’s a strong chance data scientists in any team will train their models on data that’s commercially sensitive or that identifies individuals, such as customers or patients. If that’s not treated before it hits the DevOps pipeline or production environment, there’s a real chance that information will leak.

No right or wrong answer

We need to find a collaborative path — and we can achieve that by fostering a good working environment that bridges the two disciplines to deliver products. That means data scientists internalizing the pace of software engineering and the latter adopting flexible ways to accommodate the scientists. 

Here’s my top three recommendations for putting this into practice:

1. Establish shared goals. This will help the teams to sync. For example, is the project goal to deliver a finished product such as a chatbot? Or is the goal a feature update, where all users receive the update at the same time? With shared goals in place it’s possible to set and align project and team priorities. For data scientists that will mean finding ways to accelerate aspects of their work to hit engineering sprints, for example by adopting best practices in coding. This is a soft way for data scientists to adopt a more product-oriented mindset to delivery but it also means software engineers can begin to factor research backlogs into the delivery timelines.
2. Create a shared workflow to deliver transparent code and robust AI. Join the different pieces of the AI project team puzzle: make sure the data scientists working on the model are connected to both the back-end production system and front-end while software engineers focus on making sure everything works. That means working through shared tools according to established best practices, following procedures such as common source control, versioning and QA.
3. Appoint a project leader who can step in when needed on product engineering and delivery management. This person should have experience in building a product and understand the basics of the product life cycle so they can identify problems and offer answers for the team. They should have the skills and experience to make tactical decisions such as squaring the circle of software sprints. Ultimately they should be a project polyglot — capable of understanding both scientists and engineers, acting as translator and leading both.

Data scientists and software developers operate differently but they share a common interest in project success — exploiting that is the trick. If data scientists can align with Agile-driven delivery in software engineering and software engineers can accommodate the pace of their data-diving colleagues it will be a win for all concerned. A refined system of collaboration between teams will improve the quality of code, mean faster releases and — ultimately — deliver AI systems that make it through deployment and start delivering on the needs of business.

You may also like…

Generative AI development requires a different approach to testing

The secret to better products? Let engineers drive vision

The post Data scientists and developers need a better working relationship for AI appeared first on SD Times.

It will provide developers access to an AI chat interface in several of its websites where there are developer-facing components, such as Google for Developers, Firebase, and Google Cloud. This will enable them to learn more from documentation pages, including getting explanations of code snippets in them. Developers can also ask questions about Google tools, try Google APIs before using them, generate sample code, and troubleshoot issues. 

Additionally, the developer program will provide participants access to five workspaces in Project IDX, which is a cloud-based workspace for cross-platform development. Normally, developers can only create two different workspaces, so this adds an extra three that they can access. 

Participants will be able to apply to join Google sponsored groups, which are communities of developers working on similar things. In addition, these groups receive access to exclusive events and resources. 

Members can also opt to join the Google Cloud Innovators program to receive lab credits in Google Cloud Skills Boost, which is an interactive learning platform for trying out new cloud skills. These credits are able to be used for any cloud training learning path offered by the company.

The Google Developer Program is free to any developer who wishes to join. If they don’t already have a developer profile, they simply need to create one and include their topics and interests. 

“With a profile, you will also be able to tailor your learning journey to your interests, organize your work, track your progress, earn badges, and share your achievements,” Chris Demeke, senior product manager at Google, wrote in a blog post. 

According to Google, new capabilities and offerings will be added to the program over the next several months. 

The post Google Developer Program launches to provide AI insights, resources for developers appeared first on SD Times.

The company plans to use this new influx of money to expand its platform to tackle more parts of the development life cycle, such as system design, code maintenance, and continuous scanning. It will also invest in growing its engineering and sales teams. 

This funding round was led by Kleiner Perkins, with participation from General Catalyst and Greenoaks, which had previously invested in the company. 

Codeium offers developers a toolkit that is powered by AI to improve efficiency in the software development process. It includes capabilities like autocomplete, chat, and context awareness. Currently it supports over 70 languages and integrates with over 40 IDEs, and is already used by over 300,000 developers. 

“Software engineering is the backbone of innovation yet the process is expensive and inefficient due to imperfect knowledge retrieval, boilerplate tasks, maintenance overhead, and more,” said Varun Mohan, CEO of Codeium. “The fast rise of LLMs is now giving developers the opportunity to overcome these challenges and significantly increase their productivity. This is precisely why we developed Codeium: to let developers focus on creative, high-value tasks—not tedious maintenance work.”

Leigh Marie Braswell, partner at Kleiner Perkins, the lead investor of this Series B round, added: “Codeium has all the elements of a winning AI company: the visionary leadership, the breakthrough technology, and a growing customer roster of enterprise companies. Their AI technology is not just accelerating developer productivity; it’s reshaping the way software is written. We’re thrilled to be on this journey with Varun and his team as they continue to pave the way for the future of software development.”

The post Codeium raises $65 million in Series B funding for AI tools for developers appeared first on SD Times.

The U.S. Department of Labor is estimating that there will be a shortage of 85.2 million developers by 2030, and over a third of respondents to Reveal’s latest survey on development struggles said that they are continuing to struggle with finding developers that have the necessary skills. 

According to Reveal, companies are attempting to overcome the skills challenge by adopting new technologies that will lower demand on developers, such as low-code tools.

Using low-code tools has solved the challenges associated with the developers skills shortage in 76% of organizations, according to the report. 

“This approach is helping alleviate the demand for developers by reducing the need for heavy hand-coding in areas like screen design, UX flows, theming, and branding and can all but eliminate the need for manual HTML & CSS tweaking,” the report states.

The survey found that the hardest roles to fill are DevOps engineer, data analytics developer, and IT security engineer.

The second biggest challenge, cited by another third of respondents, is keeping existing employees safe, and the third biggest challenge is limited resources. 

Development teams plan to improve resource utilization by improving project management (30%), improving designer/developer collaboration (30%), using software that will work for citizen developers (27%), utilizing remote staff (25%), and incorporating a data or analytics catalog (25%).

“Over the past three years, workers have been faced with a series of unexpected challenges — the COVID-19 pandemic, an economic downturn, and a volatile work environment– which is pushing employers to do more to assure workers are protected. Employers that take steps to protect their employees will be more likely to retain them, especially in light of the developer shortage,” according to the report.

Developers themselves are also struggling with a number of issues, including not being able to keep up with developer tool innovation, difficulty with third party integration, struggle to manage workloads, security threats, project management, and client expectations that are too high. 

The post Report: The major challenges for development teams in 2023 appeared first on SD Times.

If the Great Resignation has taught us anything, it’s that developers who are tired of workplace culture don’t stick around. Average tenure at some of the most prominent tech companies in the world is under two years, and when they leave, they often take valuable code, customer contact lists, patent applications and much more with them. For senior developers and team leaders, it’s a high price to pay when employees start sniffing around for other opportunities. 

Fortunately, you can take steps to reduce turnover, many of which aren’t complicated or time consuming. In today’s super competitive environment, one of the best ways to make your company a great place to work—and to keep developers happy—is pretty straightforward. Just back off. Trust them to do their jobs well.

This is key to building a supportive environment where developers feel comfortable voicing their ideas—particularly if those ideas are unpopular. Leaders have a responsibility to establish the kind of environment where values are reinforced, and to hire people who thrive within this framework. Even if that means they’re not always hiring the candidates who seem like an obvious fit.

Even Dumb Ideas Can Be Valuable

I know this because I have lots of dumb ideas. I’m thankful that, over the years, my colleagues have actively encouraged me to share those ideas. It taught me that I can build and foster a company culture where new ideas and new ways of thinking are valued, even if those ideas aren’t immediately well received.

Something that might seem like a dumb idea at the time, can actually evolve into something remarkable. By encouraging people to share their ideas, you can foster a sense of trust and innovation that leads to an explosion in creativity. It also makes your organization stronger by reducing employee stress—stress which ultimately leads to burnout and turnover.

Employees know they’ve long been perceived as replaceable cogs in the corporate structure, and not as unique individuals with valuable skills, and yes, shortcomings. So, fostering a culture that’s truly human and invites vulnerability has to be done with intent and deliberation.

People want to feel authenticity in where and how they work—that’s why it’s valuable to talk about new ideas (even dumb ones) to ultimately improve the company and its products. Fostering a supportive culture will likely lead to disagreements, but there are ways to offer opposing viewpoints without being a jackass. This mutual respect between developers allows your entire team to look at things through a critical lens without stepping on other people’s toes.

Here’s one example: at CodeSee, we do regular product reviews, which oftentimes lead to conversations where our developers say: “I really wish our product would do this instead.” Or “wouldn’t this be a cool feature to add?” This isn’t criticism leveled at anyone in particular, and everyone understands this. It’s a collaborative effort, with the aim of improving how our product works.

Take Steps to Sniff Out the Jerks in Your Applicant Pool

Some companies subscribe to the idea that if you’re a genius, it’s OK to treat people like garbage. We don’t. We’d rather have a decent developer who fits our culture and embodies self-reflection and humility, than a great developer who doesn’t support others. The same things we prioritize in our day-to-day operations are also reflected in hiring. There are easy-to-implement strategies to identify these qualities in potential new hires.

Two of our standard questions are simple and straightforward. We ask candidates to define three strengths and weaknesses. Three is a big enough number so that it requires introspection, and it helps us gauge if developers have already identified strategies for personal growth. The second question we like to ask is: “what will your previous managers say about you when we talk to them?”

These questions are meant to help us gauge whether or not the candidate has a pulse on self-reflection. If candidates can consider what it’s like to be one of their past managers, it shows a high level of self-awareness and empathy. And these are the people who tend to make it through our hiring process. 

Conversely, we’ve seen these questions absolutely sink some applicants. Some of them suddenly feel uncomfortable—I’ve actually been yelled at on more than one occasion. Can you imagine yelling at the person conducting your job interview? Yet it happens, and at that point, it’s game over.

Finding the Right Tools for Success

Providing the right tools is another way companies can foster a positive culture. Consider the responsibilities managed by today’s developers—especially those on teams who’ve implemented DevOps best practices. It’s not surprising that many are seeking tools to help them reduce time in tasks like project onboarding, feature planning, and code review; they’d rather focus on actual development.

Today developers spend over half of their time reading code. But what if we could cut that by just 20 percent? Or even 40 percent? If your software developers could spend 40 percent of their time doing other things, it would be truly transformative for business.

Of course, productivity tools can have drawbacks. Instead of giving more freedom and trust to developers, some organizations use technology to try to squeeze every last scrap of productivity out of them. If that’s the case, the underlying message your employees may hear is, “You’re getting a new, expensive tool because you aren’t being productive enough.” There’s no better way to push talented developers towards the exit.

Ultimately everyone needs developers, and they’ll be well compensated wherever they land. So, while some turnover is inevitable, a lot of it can be avoided if you’re intentional about crafting and maintaining a supportive work environment. And the creative energy you foster will help ignite product innovation.

The post Don’t lose developers to bad culture appeared first on SD Times.

The development profession is full of new developers. Over 50% of respondents indicated that they have been coding for less than 10 years and more than 35% have been coding for less than five years.  

Coders are also starting out younger. The most popular age range for a person to write their first line of code was 11 to 17, with 53% of responses. Fourteen percent of respondents wrote their first line of code between the ages of 5 and 10, and 24% wrote their first line between 18 and 24 years old.  

The survey also indicated that the pandemic has influenced work status for many developers, and a greater percentage of respondents now work part-time or are in school. The percentage of full-time developers has decreased in the past year. 

“This may reflect the effects of the pandemic, which saw workers from all industries stepping back and reevaluating their relationship to a five day work week and in-person employment,” Stack Overflow wrote in a blog post explaining the results of the report. 

JavaScript remained the most commonly used programming language for the ninth year in a row. This year Python surpassed SQL to become the third most popular language. 

React surpassed jQuery as the most commonly used web framework, with 40% of developers using it. JQuery was used by 34%, Express by 23%, Angular by 22%, Vue.js by 18%, and ASP.NET Core by 18%. 

AWS was the dominant platform among Stack Overflow users, with 54% of respondents using it. Following AWS was Google Cloud Platform at 31.05% and Microsoft Azure at 30.77% — nearly tied.

Other popular tools developers used include Git (used by 93%), Docker (48%), Yarn (17%), and Kubernetes (16%).  

Stack Overflow surveyed over 80,000 respondents for the survey. More information is available here. 

The post Report: Videos and blogs are the dominant way young coders learn appeared first on SD Times.

Harness’s new test intelligence feature reduces test cycle time by up to 98% by using AI/ML workflows to prioritize and optimize test execution without compromising quality. The new capabilities shift failed tests earlier into the build cycle so that developers can quickly find out if a fix worked. 

The new feature flag capabilities enable developers to release new features without making them visible to users. It also makes it easier to try capabilities such as A/B testing or software functionality variations like one- or two-step checkout. 

Developers currently use multiple toolsets and pipelines for software delivery, which limits their velocity, productivity and deployment frequency due to context switching, and babysitting configuration and upgrades which introduces toil for developers. The new Unified Pipeline enables them to manage all aspects of software delivery from a single tool, the company explained.

Harness also integrated its acquisition of Lightwing technology into its Cloud Cost Management module to enable engineering teams to auto-stop and restart their non-production environments within seconds. 

“Significant costs and many hours are incurred daily as engineering teams continuously build, test and deploy software,” said Jyoti Bansal, the CEO and cofounder of Harness. “The new Harness platform gives developers the only pipeline they’ll need. Customers can now do it all from one platform—so they can ultimately deliver software at scale quickly, reliably and securely.”

Additional details on the expanded capabilities within Harness’ platform are available here.

The post Harness updates platform with Test Intelligence, Feature Flags, and more appeared first on SD Times.

A question I often hear is, ‘How do you assess a developer’s work, and his/her worth to the organization?’

Some organizations still cling to the metric of lines of code produced by a developer, which — given the extra responsibilities of testing, ensuring security, adhering to policies and regulations, and more — might not be a fair valuation in today’s complex world. 

This method is entrenched in the finger-pointing of the past, which modern development organizations have largely eschewed as they look to create a blameless culture.

Forward-thinking companies will look at the role of the team around development, assembled with software engineers, testers, security experts and people from the business side, and look holistically at how that team performs.

“Line counts is a terrible metric, and I think we all agree on that,” said Chris Downard, vice president of engineering at Gigsmart, a website for hiring gig workers. “There are times … when it could be useful as an additional data point, but not necessarily for information.”

When you’re managing humans, he said, reducing every action to data points is not good. Time must be spent building context, as data can often misrepresent things. At Gigsmart, Downard said they don’t use sprints, instead taking what he called “an ongoing, non-stop kind of combat approach.” But they do use sprint reports, from metrics captured every two weeks, to communicate what happened in that time period.

He pointed out he knew what his team was doing between the sprint reports — they were working hard, pairing up, and he saw the number of merge requests going up. “But one of the normal indicators of productivity is, ‘are we moving things across the line to delivered,’ as points completed,” he said, and that number was going down. But based on their knowledge of the team and of the context of everything else going on, they discounted the number, knowing the team’s productivity was very, very high. “It’s just the way the ticketing shook out, producing a data point that was not necessarily indicative of what was accurate,” he noted.

As an organizational leader, Downard said, you need to think about the things you want the organization to produce, and then think about the measurements that will indicate that you’re having success or struggling. Different teams, of course, have different goals.

“If you’re running a DevOps team, you might care about time to resolution, and if you’re tracking the development portion of an IT department, it might be turnaround time for customizing reports and data stuff. You need to track the things that matter to your organization’s success. So for us, I track merge request counts for a week. And we don’t necessarily do anything with that data. It’s not a carrot-and-stick thing. It’s just, it gives me additional information. Kind of like a doctor would be diagnosing a patient.”

But data points often don’t align with assessing developer productivity because while much programming involves the logical reasoning side of the brain, it also involves the creative side. So for Downard, raw data points are “typically terrible. But what we do get is a lot of soft indicators. You get information out of standup updates of people communicating how they feel about what they’re doing. You get hard data points in the sense that you can see their commit activity, but you have to keep context.” As a leader, he said, you have to advocate for developers and translate what they’re running into, to every other organization around development.

Downard said Gigsmart uses Bushido, the samurai code of conduct that defines the values of how you should act and conduct yourself as an individual, as its organizational ethos. “Jason Waldrip, our CTO and I sat down and crafted it into a set of ideals to drive the organization, and I use that as the core for everything we do. So if I’m going to start tracking something, it has to map to some sort of value from there, because if I try to track things that don’t map well to those values, I can’t advocate for those values with the team. It’s not gonna stick, it’s going to become hollow.”

Data points, he said, are nothing more than signals to go look into something and start asking questions. “And it should always be exploratory, not accusatory. That’s important to us. 

The post Industry Watch: Assessing a developer’s work, and worth appeared first on SD Times.