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.

When looking at how developers are dealing with updates, more than half the respondents stated they had a smooth migration experience. Thirty-eight percent said the upgrade process was neutral and 8% found it hard. The survey ran after the release of Angular 9, which had the most significant changes to the framework since 2016. Since the survey, the team has released Angular 10 and Angular 11. 

Additionally, most developers reported they were satisfied with the ease of updates from Angular. The most important areas of focus for developers were runtime performance, documentation, initial load performance, tooling and new features. 

To make Angular faster, the team is currently working on adding “more fine-grained control over the innovation of change detection so that developers can trigger it only when required, Minko Gechev, senior developer relations engineer at Google, wrote in a post. More information about the update is on the frameworks’ roadmap under Zoneless Angular. 

“Additionally, we believe that more people would be able to make their apps faster if we provide them the tools to understand their apps’ lifecycle — when and what triggers change detection, how much time Angular spends in user code, etc. A project in this space on the roadmap is Angular DevTools,” Gechev explained.

The survey also asked open ended questions for “promoters and detractors.” The detractors reported wanting to see improvements in documentation and ease of use. The promoters would also like to see improvements in documentation, and performance/load times. 

Angular is currently working on improving developer onboarding, video guides and tutorials to help developers work with the framework. 

“We’re continually striving to make Angular easier and more accessible to everyone. Working on the developer onboarding is going to have a vast impact on this. The removal of View Engine will also let us simplify some public framework APIs,” Gechev wrote. 

The post Report: Angular developers want to see faster runtime and better documentation appeared first on SD Times.

Other improvements include an added V8 crash message and location information to crashReport parameters and improved performance for sending wide objects over the context bridge.

Additional details on all of the changes are available here.

No Code App Generator, CodeBot UX is available to early access users
With CodeBot, users can generate full-stack applications from a domain model, while its newly engineered UX components allow users a smoother and centralized approach towards app generation.

CodeBot UX supports UML models including class diagrams, state machines and wireframes. From these, CodeBot generates a database schema, API documentation, server-side code, client-side code including domain classes, CRUD functions and usage examples.

CodeBot can also automatically host one’s generated web application in the cloud with the click of a button. CodeBot UX initially targets React, but will soon build equivalent user interfaces for React Native, Vue.js and Angular.

Build.security emerges from stealth with $6 million in backing
Build.security aims to dramatically simplify the process of building authorization and cutting down development time with its open policy agent-powered authorization policy management platform.

“build.security’s innovative approach allows developers to focus on developing apps at unprecedented speed without the burden of Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) implementation weighing them down,” said George Kurtz, the CEO and cofounder of CrowdStrike.

The company’s solution offers a unified pane of glass that enables developers to easily author, evaluate, distribute and monitor policies at scale, policy-as-code, which allows developers to express authorization policies with a no-code drag-and-drop policy builder or through a low-code declarative language.

Additional details are available here.

The post SD Times news digest: Electron JS 11.0 released, CodeBot UX is available to early access users, and Build.security emerges from stealth appeared first on SD Times.

The Code Risk Analyzer can be configured to run at the beginning of a developer’s code pipeline and it reviews and analyzes Git repositories for known issues with any open-source code that needs to be managed. It helps provision toolchains, automates builds and tests, and enables users to control quality with analytics, according to the company. 

“The trend toward decentralized cloud-native developer teams creating, modifying, and redeploying their work on a daily, or more frequent basis, has sparked a transformation in security and compliance processes for business applications,” Shripad Nadgowda, senior software engineer at IBM, wrote in a blog post. “As a result, it has become critical to equip developers with a new set of cloud-native capabilities and tools, such. Code Risk Analyzer, that can be easily embedded into existing development workflows.”

While previous solutions focused on running at the beginning of a developer’s code pipeline, the solutions were found to be inefficient because container images have slimmed down to where they contain the minimum payload needed to run an application and images lack the development context of an application. 

“In DevSecOps it’s absolutely essential to design a comprehensive and consistent solution that encompasses security and compliance assessment across all these artifacts. As a result, we embodied them all in the scope for the Code Risk Analyzer solution,” Nadgowda wrote. 

For application artifacts, Code Risk Analyzer aims to provide vulnerability, license management, and CIS checks on deployment configurations, generates a Bill-of-Materials and security lint checks. Terraform files (*.tf) used to provision or configure cloud services like Cloud Object Store and LogDNA are also scanned to identify any security misconfigurations.

The solution also provides a separation of concerns between developers and security experts through a role-based Open Policy Agent (OPA) framework for controlling such policies. The analyzer is also embedded into developer workflows and includes a change request procedure through pr_workflow for a pull request, and a change request approval by commit-to-main-branch in ci_workflow for continuous integration.

The addition of Smart Updates, tracks changes to all dependencies of an application and classifies those changes through automated update notifications.

Additional details on IBM’s Code Risk Analyzer are available here.

The post IBM releases Code Risk Analyzer to shift security left appeared first on SD Times.

In a webinar sponsored by Devtech Group, innovation consultant Nils Vesk explained 14 of the most common mistakes that can affect a remote team’s performance. Here are some of the highlights:

WEBINAR: Remote working mistakes that could be killing your developers’ innovative output and performance

Failing to understand that leadership means different things to different people. 
To reconcile this, Vesk recommends trying to understand what leadership means to each person by asking them to share a significant leader they had in life. It’s also important for the leaders to share their interpretation of leadership, in addition to adopting some of what the team shared. “By doing that, what it means is we get very clear as to what type of leadership style they’re looking for and they get clear as to what type of leadership style we believe in,” said Vesk. 

Measuring outcomes but not measuring behaviors.
 “Unless we measure the behaviors we execute each and every day, it’s going to be unlikely that we can achieve the outcome,” Vesk said.   

Failing to provide recognition and a sense of progress to individual and team members on a project.
According to Nils, people crave feedback, as well as a sense of movement from point A to B. Solutions to this mistake include using a scoreboard or providing specific feedback that is geared towards progress.

Assuming people have more mental bandwidth than they do.
People have more cognitive load than ever before. There are more decisions to make and more information to process, Vesk said. “Our job as leaders is to look for ways we can simplify this to make it shorter in terms of the amount of information they’ve got to process,” he said. Vesk recommends communicating through pictures when possible because we process pictures much faster than words. For example, use flow charts, pictures, and icons where possible. 

Not allowing humor and fun into the work environment.
According to Vesk, there is a lot of research being done on the impact of fun on things like resilience, mindset, and problem solving in the workplace. “You don’t need to be a Jerry Seinfeld or an Amy Schumer, all you need is to have a couple of games in there from time to time…sometimes it’s about making light of the challenges that are out there, not ignoring them but it just helps us get through those tough times,” said Vesk.  At Devtech, for example, at the beginning of every planning cycle, team leaders will ask their team what can be done to make things more fun.  

For more details on these mistakes and the rest, as well as how to fix them, watch the webinar. 

The post 14 remote working mistakes that your team could be making appeared first on SD Times.

That makes the applications these companies build — and the people who build them — more important than ever. Developers are no longer just the “worker bees” who build out the company’s application infrastructure, but the talent who will spur the company’s next great innovations. Business units and developers are now working together as partners, each equally invested in the other’s success.

Because developers make the world go round, OutSystems wants to bring their voices forward. So we’re launching Decoded, a podcast series for the next generation of developers. On this podcast, we’ll look at how the world of app development is changing, talk to developers about their journeys, and offer guidance to help you prepare for what’s next.

The new status quo
If it seems like massive disruption is happening in the way most companies operate, that’s because it is. With every company becoming a tech company, the insatiable need for developers means that businesses will need to rethink their entire approach to hiring and retaining developer talent.

It’s no secret that the tech industry, like many other industries, has historically struggled to hire a diverse workforce. But the next generation of developer talent won’t look anything like yesterday’s stereotypical developer. Let’s be blunt: we won’t all be a 25-year-old straight white male living in Silicon Valley (ok, ok this is a total stereotype, but you get the point). People of all genders, races, ages, sexual orientations, educational levels, socioeconomic backgrounds, and parts of the world are already bringing their creativity and energy to the development workforce.

It’s up to employers to leverage this new wave of diverse developers to create the next wave of innovative new applications.

In addition to diverse backgrounds, businesses need to look for diverse skill sets. It’s no longer enough to be just a programming whiz. Developers must also have skills in areas like business, communication, branding, and user experience. For many companies, it may actually be more effective to hire people who already have these skills and retrain them with the programming skills they need to contribute. Companies also need to think about what they’re doing to not just hire and train the next generation of developers, but retain them for the long haul. That doesn’t mean offering perks like a ping pong table or free kombucha. It means building a robust, inclusive, and diverse culture.

Perhaps appropriately, technology has a large role to play in empowering the next generation of developers. Agile development processes, collaboration software, and modern application development platforms all help developers focus on the work of development. The right technology can free developers from non-productive tasks, and give them back time to enable the rapid application development and the culture of iteration required to meet the needs of today’s market.

From shifting demographics to higher expectations to new technologies, the only constant for tomorrow’s developers will be change. As we talk to your colleagues throughout the Decoded podcast series, we hope that the conversations with our guests not only help you shape your career, but our entire industry. We look forward to decoding the future of development with you.

The post What tomorrow’s developers need to succeed appeared first on SD Times.